このページでは、Cloud SQL for MySQL 5.7 から Cloud SQL for MySQL 8.0 へのメジャー バージョン アップグレードを実行する際に発生する可能性がある既知の問題と非互換性について説明します。
メジャー バージョンのアップグレードの詳細については、データベースのメジャー バージョンをインプレースでアップグレードするとエラーログを表示するをご覧ください。
互換性のない SQL の変更
このセクションでは、事前チェック ユーティリティの実行時とアップグレード時に発生する可能性がある Cloud SQL 5.7 と Cloud SQL 8.0 の SQL の非互換性について説明します。
予約済みキーワード
エラー メッセージの例を次に示します。
Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.
GROUPS、LEAD、RANK などの一部のキーワードは、MySQL バージョン 8.0 で予約語として分類されるようになりました。つまり、以前は識別子として使用されていた一部の単語が、現在は違法と見なされる可能性があります。影響を受けるステートメントを修正するには、識別子の引用符を使用するか、識別子の名前を変更します。
キーワードの完全なリストについては、キーワードと予約済みの単語をご覧ください。
GROUP BY 句で ASC/DESC を削除しました
エラー メッセージの例を次に示します。
[ERROR] [MY-013235] [Server] Error in parsing Routine db_name.routine_name during upgrade. You may have an error in your SQL syntax; check the manual that corresponding to your MySQL server version for the right syntax to use near 'some_text'
別のエラー メッセージの例を次に示します。
[ERROR] [MY-013235] [Server] Unknown trigger has an error in its body: 'You have an error in you SQL syntax; [ERROR] [MY-010198] [Server] Error in parsing Triggers from trigger_name.TRG file.
以前に GROUP BY ソートに依存していたクエリでは、以前の MySQL バージョンとは異なる結果が生成される可能性があります。特定の並べ替え順序を保持するには、ORDER BY 句を指定します。
ストアド プロシージャ、トリガー、イベント定義に GROUP BY 句で ASC または DESC を使用するクエリが含まれている場合、そのオブジェクトのクエリには ORDER BY 句が必要です。
詳細については、GROUP BY ASC と DESC の構文を削除するをご覧ください。
キーとして空間データと他の型を組み合わせる
エラー メッセージの例を次に示します。
[ERROR] [MY-013140] [Server] Incorrect prefix key; the used key part isn't a string, the used length is longer than the key part, or the storage engine doesn't support unique prefix keys [ERROR] [MY-013140] [Server] Too many key parts specified; max 1 parts allowed
MySQL バージョン 8.0 以降では、インデックスに空間データ型と他のデータ型を混在させることはできません。鍵を削除して、MySQL バージョン 8.0 以降でサポートされている新しい鍵を作成する必要があります。詳細については、空間インデックスをご覧ください。空間データ インデックスを特定するには、次のようなクエリを使用します。
SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME, s.COLUMN_NAME, s.INDEX_TYPE, c.DATA_TYPE FROM information_schema.STATISTICS s JOIN information_schema.COLUMNS c ON s.TABLE_SCHEMA = c.TABLE_SCHEMA AND s.TABLE_NAME = c.TABLE_NAME AND s.COLUMN_NAME = c.COLUMN_NAME WHERE c.DATA_TYPE IN ( 'geometry', 'point', 'linestring', 'polygon', 'multipoint', 'multilinestring', 'multipolygon', 'geometrycollection' ) AND s.INDEX_TYPE = 'BTREE';
無効な UTF8 文字
エラー メッセージの例を次に示します。
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
テーブル定義に無効な UTF8 文字が含まれている場合、テーブル定義をデータ ディクショナリに変換できないことがあります。この問題を解決するには、無効な文字を対応する UTF8 文字に置き換えるか、完全に削除します。
無効な文字を特定して対処するには、次のようなクエリを使用します。
SHOW CREATE TABLE table_name; ALTER TABLE table_name MODIFY COLUMN column_name data_type comment=''; // removing invalid utf8 character from comment
コミットされていない XA トランザクション
エラー メッセージの例を次に示します。
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
未コミットの XA トランザクションがある場合、メジャー バージョンのインプレース アップグレードは失敗します。この問題に対処するには、アップグレードを完了する前に XA RECOVER ステートメントを実行します。このステートメントは、未コミットの XA トランザクションを確認します。レスポンスが返された場合は、XA COMMIT を発行して XA トランザクションを commit するか、XA ROLLBACK ステートメントを発行して XA トランザクションをロールバックします。既存の XA トランザクションを確認するには、次のようなコマンドを実行します。
mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+-------------------------- | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-------------------------- | 787611 | 9 | 9 | 0x787887111212345678812676152F12345678 | +----------+--------------+--------------+-------------------------- 1 row in set (0.00 sec)
この例では、gtrid と bqual の値が 16 進数形式で指定されていますが、誤って連結されています。この問題を解決するには、次のフィールドを使用してこれらの値を手動で作成する必要があります。
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
これらの XA トランザクションを commit または rollback するには、次のようなコマンドを使用して、この情報から xid を作成します。
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
最大キー長を超過
エラー メッセージの例を次に示します。
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
この問題は、sql_mode 構成が原因で発生する可能性があります。MySQL バージョン 5.7 では、厳密モードがないため、接頭辞またはインデックスの長さに制限を付けてインデックスを作成できました。
ただし、MySQL バージョン 8.0 では、STRICT_ALL_TABLES や STRICT_TRANS_TABLES などの厳格モードが導入され、インデックスの長さに厳しいルールが適用されるため、このエラーが発生します。
この問題を解決するには、エラー メッセージに示されている最大バイト数以内の長さにインデックスの接頭辞の長さを更新します。デフォルトのプロトコルである UTFMB4 では、各文字が最大 4 バイトを占有します。つまり、最大文字数は最大バイト数を 4 で割ることで決定できます。
メタデータ情報が一致しない
エラー メッセージの例を次に示します。
[ERROR] [MY-012084] [InnoDB] Num of Indexes in InnoDB doesn't match with Indexes from server [ERROR] [MY-012069] [InnoDB] table: TABLE_NAME has xx columns but InnoDB dictionary has yy columns
別のエラー メッセージの例を次に示します。
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
frm ファイルと InnoDB ディクショナリの間でメタデータが一致しないテーブルをアップグレードしようとすると、アップグレードは失敗します。この場合、frm ファイルが破損している可能性があります。この問題に対処するには、アップグレードを試みる前に、影響を受けるテーブルをダンプして復元する必要があります。
詳細については、メタデータが一致しないテーブルのアップグレードを試みるをご覧ください。
影響を受けたテーブルをダンプして復元するには、次のようなコマンドを実行します。
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
外部キー名が 64 文字を超えている
エラー メッセージの例を次に示します。
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
このエラーは、テーブルの外部キー制約名が 64 文字を超える場合に発生します。制約名が長すぎるテーブルを特定するには、次のようなコマンドを使用します。
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
テーブルに 64 文字を超える制約名が含まれている場合は、ALTER TABLE コマンドを使用して、この文字数制限内で制約の名前を変更します。
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
テーブル名の大文字と小文字が一致しない
エラー メッセージの例を次に示します。
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
MySQL バージョン 5.7 のインスタンスで小文字のテーブル名（lower_case_table_names=1）が必要な場合は、MySQL バージョン 8.0 にアップグレードする前に、すべてのテーブル名を小文字に変換する必要があります。
または、要件（lower_case_table_names=0）を無効にしてから、インスタンスをアップグレードすることもできます。lower_case_table_names フィールドの値を 1 から 0 に変更すると、MySQL バージョン 8.0 で値を元に戻すことはできません。
別のエンジンに属する InnoDB で認識されるテーブル
エラー メッセージの例を次に示します。
Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removed InnoDB files manually from the disk and creates a table with same name by using different engine.
InnoDB エンジンが認識するが SQL レイヤが認識しないテーブルがデータベースにある場合、アップグレードは失敗します。
InnoDB ストレージ エンジンを使用していないデータベース内のすべてのテーブルを検索します。
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'
特定されたテーブルごとに、ALTER TABLE コマンドを実行して、ストレージ エンジンを InnoDB に変更します。
ALTER TABLE db_name.table_name ENGINE='INNODB';
不明なストレージ エンジン パーティション
エラー メッセージの例を次に示します。
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
MySQL バージョン 8.0 では、InnoDB と ndbcluster 以外のエンジンでパーティションを使用できません。パーティションがあり、エンジンが InnoDB ではないテーブルを確認する必要があります。これらのテーブルを特定するには、次のクエリを実行します。
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
クエリで報告されたテーブルは、InnoDB を使用するように更新するか、パーティション分割されないように構成する必要があります。テーブルのストレージ エンジンを InnoDB に変更するには、次のステートメントを実行します。
ALTER TABLE db_name.table_name ENGINE = INNODB;
MVU オペレーションの実行時間が長い
メジャー バージョンのアップグレードには、次の 2 つの基盤となるタスクが関連付けられています。
- 事前チェック オペレーション: 3 時間以内に完了しない場合は、タイムアウト エラーを返します。
- アップグレード オペレーション: 6 時間以内に完了しない場合は、タイムアウト エラーを返します。
インスタンスで MAJOR_VERSION_UPGRADE オペレーションが予想よりも長く実行されている場合は、MySQL エラーログを調べて、メタデータのアップグレードでブロックされているか、事前チェックのステップで停止しているかを確認できます。この問題の最も一般的な原因は次のとおりです。
- テーブル、ビュー、インデックスの数が非常に多い
- CPU やメモリなどのリソースの不足
- アップグレード プロセスを開始するためにデータベースのシャットダウンをブロックしている主要なトランザクション。 Trusted Cloud by S3NS コンソールを使用して、現在のプロセスを確認できます。
システムで開いているファイルが多すぎる
エラー メッセージの例を次に示します。
[ERROR] [MY-012592] [InnoDB] Operating system error number 23 in a file operation [ERROR] [MY-012596] [InnoDB] Error number 23 means 'Too many open files in system'
インスタンスに 200 万個を超えるテーブルが含まれている場合は、「システムで開いているファイルが多すぎます」というエラーが表示されることがあります。アップグレードする前に、テーブルの数を 200 万未満に減らす必要がある場合があります。
メモリ不足エラー
MySQL 5.7 から 8.0 にアップグレードする場合は、古いメタデータを新しいデータ ディクショナリに変換するため、追加のメモリが必要になります。メジャー バージョンのアップグレード中に「メモリ不足」エラーが発生しないように、Cloud SQL ではテーブルごとに少なくとも 100 KB のメモリを用意することをおすすめします。
テーブルの数を確認するには、次のクエリを使用します。
SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables
この問題を解決するには、アップグレードを開始する前に、マシンタイプを変更してメモリを一時的に増やすことができます。
共有コア インスタンス（db-f1-micro、db-g1-small、HA db-f1-micro、HA db-g1-small などのマイクロまたはスモール コア）の場合は、アップグレード オペレーション中に専用コア インスタンスにアップグレードして、リソース関連の問題を回避します。アップグレード オペレーションが完了したら、ダウングレードできます。
MySQL のシャットダウン エラー
エラー メッセージの例を次に示します。
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
Cloud SQL は、メジャー バージョンのアップグレードの前にクリーン シャットダウンを実行します。ワークロードが大きいインスタンスやトランザクションの実行時間が長いインスタンスでは、シャットダウン プロセスが長くなる可能性があり、タイムアウトが発生してアップグレードが失敗する可能性があります。アップグレードを確実に成功させるには、長時間実行されるトランザクションがなく、トラフィックが少ない時間帯にアップグレードを計画します。