Aurora MySQL の事前チェックの説明リファレンス

事前チェックレベル: Error

mysql スキーマの check table x for upgrade コマンドによって報告された問題

Aurora MySQL バージョン 3 へのアップグレードを開始する前に、check table for upgrade が DB インスタンスの mysql スキーマ内の各テーブルで実行されます。check table for upgrade コマンドは、MySQL の新しいバージョンへのアップグレード中に発生する可能性のある問題がないかテーブルを調べます。アップグレードを試行する前にこのコマンドを実行すると、互換性がない箇所を事前に特定して解決できるため、実際のアップグレードプロセスがよりスムーズになります。

このコマンドは、次のような各テーブルに対してさまざまなチェックを実行します。

詳細については、MySQL ドキュメントの「CHECK TABLE Statement」を参照してください。

出力例:

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

check table for upgrade は複数のチェックを実行するため、この事前チェックの出力は、発生したエラーと発生したタイミングによって異なります。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

事前チェックレベル: Error

テーブルスペースのデータファイルパスの循環ディレクトリ参照

MySQL 8.0.17 以降、CREATE TABLESPACE ... ADD DATAFILE 句は循環ディレクトリ参照を許可しなくなりました。アップグレードの問題を回避するには、Aurora MySQL バージョン 3 にアップグレードする前に、テーブルスペースのデータファイルパスから循環ディレクトリ参照を削除します。

出力例:

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

このエラーが表示された場合は、file-per-table テーブルスペースを使用してテーブルを再構築します。すべてのテーブルスペースとテーブル定義にデフォルトのファイルパスを使用します。

再構築後、事前チェックに合格し、アップグレードを続行できます。

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

デフォルト値を設定できない列

MySQL 8.0.13 より前のバージョンでは、BLOB、TEXT、GEOMETRY、および JSON 列にデフォルト値を含めることはできません。Aurora MySQL バージョン 3 にアップグレードする前に、これらの列のデフォルト句をすべて削除します。これらのデータ型のデフォルト処理の変更についての詳細は、MySQL ドキュメントの「Data Type Default Values」を参照してください。

出力例:

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

test.test_blob_default テーブルの geo_col 列は、デフォルト値が指定された BLOB、TEXT、GEOMETRY、または JSON データ型を使用しているため、事前チェックではエラーが返されます。

テーブル定義を見ると、geo_col 列が geo_col geometry NOT NULL default '' として定義されていることがわかります。

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

このデフォルト句を削除して、事前チェックが合格できるようにします。

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

事前チェックに合格し、アップグレードを再試行できます。

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

定義での非推奨キーワードの使用

MySQL 8.0 では、クエリキャッシュが削除されています。その結果、クエリキャッシュ固有の SQL 構文の一部が削除されました。データベースオブジェクトのいずれかに QUERY CACHE、SQL_CACHE または SQL_NO_CACHE のキーワードが含まれている場合、事前チェックエラーが返されます。この問題を解決するには、これらのオブジェクトを再作成し、前述のキーワードを削除します。

出力例:

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

事前チェックでは、test.no_query_cache_check ストアドプロシージャが、削除されたキーワードのいずれかを使用していることがレポートされます。プロシージャ定義を見ると、SQL_NO_CACHE を使用していることがわかります。

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

キーワードを削除します。

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

キーワードを削除すると、事前チェックは正常に完了します。

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

別のエンジンに属する InnoDB によって認識されるテーブル

schemaInconsistencyCheck と同様、この事前チェックは、アップグレードに進む前に MySQL のテーブルメタデータが一貫していることを確認します。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

出力例:

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "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 removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

事前チェックレベル: Error

255 文字を超える要素を含む ENUM および SET 列定義

テーブルとストアドプロシージャには、255 文字または 1020 バイトを超える ENUM または SET 列要素が存在してはいけません。MySQL 8.0 より前では、合計最大長は 64K でしたが、8.0 では個々の要素が 255 文字または 1020 バイト (マルチバイトをサポート) に制限されています。enumSetElementLengthCheck の事前チェックに失敗した場合は、アップグレードを再試行する前に、これらの新しい制限を超える要素を変更します。

出力例:

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

test.large_set テーブルの s 列に 255 文字を超える SET 要素が含まれているため、事前チェックはエラーを報告します。

この列の SET サイズを小さくすると、事前チェックに合格し、アップグレードを続行できます。

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

64 文字を超える外部キーの制約名

MySQL ドキュメントで説明されているように、MySQL では、識別子の長さは 64 文字に制限されています。外部キーの長さがこの値以上になり、アップグレードに失敗する可能性のある問題が特定されたため、この事前チェックが実装されました。この事前チェックでエラーが発生した場合は、アップグレードを再試行する前に 64 文字未満になるように制約を変更または名前を変更する必要があります。

出力例:

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

データベース内のすべてのトリガー名は一意である必要があります。

データディクショナリの実装が変更されているため、MySQL 8.0 はデータベース内の大文字と小文字を区別するトリガーをサポートしていません。この事前チェックでは、DB クラスターに重複トリガーを含むデータベースが 1 つ以上ないことを検証します。詳細については、MySQL ドキュメントの「Identifier Case Sensitivity」を参照してください。

出力例:

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

事前チェックでは、データベースクラスターに同じ名前のトリガーが 2 つあるものの、異なるケースである test.before_insert_product と test.before_insert_PRODUCT を使用しているというエラーが報告されます。

アップグレードする前に、トリガーの名前を変更するか、新しい名前で削除して再作成します。

test.before_insert_PRODUCT の名前を test.before_insert_product_2 に変更すると、事前チェックは成功します。

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

mysql.event の "definer" 列を null または空白にすることはできません。

DEFINER 属性は、トリガー、ストアドプロシージャ、イベントなど、ストアドオブジェクト定義を所有する MySQL アカウントを指定します。この属性は、保存されたオブジェクトが実行されるセキュリティコンテキストを制御する場合に特に便利です。ストアドオブジェクトを作成するときに、DEFINER が指定されていない場合、デフォルトはオブジェクトを作成したユーザーです。

MySQL 8.0 にアップグレードする場合、MySQL データディクショナリの "definer" が null または空であるオブジェクトを保存することはできません。このようなストアドオブジェクトがある場合、事前チェックエラーが発生します。アップグレードを続行する前に、エラーを修正する必要があります。

エラーの例

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

事前チェックは、"definer" が null であるため、test.get_version イベントのエラーを返します。

これを解決するために、イベント定義を確認できます。以下に示すとおり、"definer" は null または空白です。

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

有効な "definer" を指定してイベントを削除または再作成します。

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

これで、事前チェックに合格です。

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

事前チェックレベル: Error

InnoDB データディクショナリと実際のテーブル定義の間の列定義の不一致

schemaInconsistencyCheck と同様、この事前チェックは、アップグレードに進む前に MySQL のテーブルメタデータが一貫していることを確認します。この場合、事前チェックでは、InnoDB データディクショナリと MySQL テーブル定義が列定義と一致することを確認します。不一致が検出された場合、アップグレードは続行されません。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

出力例:

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

事前チェックでは、test.mismatchTable テーブル内の id 列のメタデータの不一致が報告されます。具体的には、MySQL メタデータの列名は iD で、InnoDB の列名は id です。

事前チェックレベル: Error

information_schema.triggers の "definer" 列は、null または空白にすることはできません。

事前チェックでは、データベースに、"definer" が null または空白で定義されたトリガーがないことを確認します。保存されたオブジェクトの "definer" の要件についての詳細は、「getEventsWithNullDefiner」を参照してください。

出力例:

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

test スキーマの example_trigger トリガーの "definer" が null であるため、事前チェックはエラーを返します。この問題を修正するには、有効なユーザーでトリガーを再作成するか、トリガーを削除して、"definer" を修正します。詳細については、「getEventsWithNullDefiner」の例を参照してください。

事前チェックレベル: Error

lower_case_table_names パラメータが 1 に設定されている場合は、すべてのデータベース名とテーブル名を小文字にする必要があります。

MySQL 8.0 より前では、データベース名、テーブル名、およびその他のオブジェクトは、ファイルベースのメタデータ (.frm) などのデータディレクトリ内のファイルに対応していました。lower_case_table_names システム変数を使用すると、サーバーがデータベースオブジェクトの識別子の大文字と小文字の区別を処理する方法と、そのようなメタデータオブジェクトのストレージを制御できます。このパラメータは、再起動後に既に初期化されているサーバーで変更できます。

ただし、MySQL 8.0 では、このパラメータは引き続きサーバーが識別子の大文字と小文字の区別を処理する方法を制御しますが、データディクショナリの初期化後に変更することはできません。MySQL 8.0 データベースをアップグレードまたは作成する場合、MySQL でデータディクショナリが初めて起動するときに lower_case_table_names に設定した値は、そのデータベースの存続期間に使用されます。この制限は、データベースオブジェクトがファイルベースのメタデータから mysql スキーマ内の内部 InnoDB テーブルに移行されるアトミックデータディクショナリ実装の実装の一環として導入されました。

詳細については、MySQL ドキュメントの「Data Dictionary Changes」を参照してください。

ファイルベースのメタデータを新しいアトミックデータディクショナリに更新する際のアップグレード時の問題を回避するため、この事前チェックでは、lower_case_table_names = 1 の場合、すべてのテーブルがディスクに小文字で保存されていることを検証します。小文字で保存されていない場合、事前チェックエラーが返され、アップグレードに進む前にメタデータを修正する必要があります。

出力例:

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

テーブル test.TEST に大文字が含まれているものの、lower_case_table_names が 1 に設定されているため、エラーが返されます。

この問題を解決するために、小文字を使用するようにテーブルの名前を変更するか、アップグレードを開始する前に DB クラスターの lower_case_table_names パラメータを変更することができます。

事前チェックレベル: Error

削除された GROUP BY ASC/DESC 構文の使用

MySQL 8.0.13 以降、GROUP BY 句の非推奨の ASC または DESC 構文は削除されました。GROUP BY ソートに依存するクエリは、異なる結果を生成するようになりました。特定のソート順序を取得するには、ORDER BY 句を代わりに使用します。この構文を使用したオブジェクトがデータベースに存在する場合は、アップグレードを再試行する前に ORDER BY 句を使用してオブジェクトを再作成する必要があります。詳細については、MySQL ドキュメントの「SQL Changes」を参照してください。

出力例:

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

事前チェックレベル: Error

ルーチンで使用される非推奨の .<table> 構文を確認します。

MySQL 8.0 では、ルーチンに非推奨の識別子構文 (\".<table>\") を含めることができなくなります。保存されたルーチンまたはトリガーにそのような識別子が含まれている場合、アップグレードは失敗します。例えば、次の .dot_table リファレンスは許可されなくなりました。

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

正しい識別子構文とエスケープを使用するようにルーチンとトリガーを再作成すると、事前チェックに合格し、アップグレードを続行できます。識別子についての詳細は、MySQL ドキュメントの「Schema Object Names」を参照してください。

出力例:

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

非推奨の構文が含まれているため、事前チェックは、test データベース内の incorrect_procedure ルーチンのエラーを返します。

ルーチンを修正すると、事前チェックは成功し、アップグレードを再試行できます。

事前チェックレベル: Error

MySQL の 5.7 を超えるバージョンで機能するには大きすぎるインデックスがないかをチェックする

コンパクトまたは冗長な行形式の場合、プレフィックスが 767 バイトを超えるインデックスを作成することはできません。ただし、MySQL バージョン 5.7.35 より前では、これは可能でした。詳細については、「MySQL 5.7.35 リリースノート」を参照してください。

このバグの影響を受けたインデックスは、MySQL 8.0 にアップグレードするとアクセスできなくなります。この事前チェックでは、アップグレードを進める前に再構築する必要がある問題のあるインデックスを特定します。

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

test.table_with_large_idx テーブルには 767 バイトを超えるコンパクトな行形式または冗長な行形式を使用したテーブル上のインデックスが含まれているため、事前チェックはエラーを返します。これらのテーブルは、MySQL 8.0 にアップグレードするとアクセスできなくなります。アップグレードに進む前に、次のいずれかを実行します。

ここでは、テーブルを再構築して、事前チェックの失敗を解決します。テーブルを再構築する前に、innodb_file_format が Barracuda に設定され、innodb_default_row_format が dynamic に設定されていることを確認します。これらは MySQL 5.7 のデフォルトです。詳細については、MySQL ドキュメントの「InnoDB Row Formats」および「InnoDB File-Format Management」を参照してください。

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

テーブルを再構築すると、事前チェックに合格し、アップグレードを続行できます。

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

MySQL 5.7 で使用されている無効なテーブル名とスキーマ名をチェックする

MySQL 8.0 で新しいデータディクショナリに移行する場合、データベースインスタンスに #mysql50# というプレフィックスが付いたスキーマやテーブルを含めることはできません。このようなオブジェクトが存在する場合、アップグレードは失敗します。この問題を解決するには、返されたスキーマとテーブルに対して mysqlcheck を実行します。

出力例:

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

事前チェックでは、スキーマの名前 #mysql50#fix_db_names が無効であることが報告されます。

スキーマ名を修正すると、事前チェックに合格し、アップグレードを続行できます。

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

5.7 で孤立したルーチンをチェックする

MySQL 8.0 で新しいデータディクショナリに移行する場合、データベースにスキーマが存在しないストアドプロシージャがあると、アップグレードは失敗します。この事前チェックは、DB インスタンスのストアドプロシージャで参照されるすべてのスキーマがまだ存在していることを確認します。アップグレードを続行できるようにするには、これらのストアドプロシージャを削除します。

出力例:

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

事前チェックでは、dropped_db データベース内の get_version ストアドプロシージャが孤立していることが報告されます。

この手順をクリーンアップするには、欠落しているスキーマを再作成します。

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

スキーマが再作成されたら、プロシージャを削除してアップグレードを続行できます。

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

MySQL 8.0 の新しいテーブルと競合する mysql スキーマのテーブル名

MySQL 8.0 で導入された新しいアトミックデータディクショナリは、mysql スキーマ内の内部 InnoDB テーブルのセットにすべてのメタデータを保存します。アップグレード中、新しい内部データディクショナリテーブルが mysql スキーマに作成されます。アップグレードの失敗につながる名前の衝突を避けるため、事前チェックでは mysql スキーマ内のすべてのテーブル名を調べ、新しいテーブル名がまだ使用されていないことを確認します。使用されているとエラーが返され、アップグレードを続行することはできません。

出力例:

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

mysql スキーマに tablespaces という名前のテーブルがあるため、エラーが返されます。これは、MySQL 8.0 の新しい内部データディクショナリテーブル名の 1 つです。アップグレードする前に、RENAME TABLE コマンドを使用して、このようなテーブルの名前を変更または削除する必要があります。

事前チェックレベル: Error

非ネイティブパーティショニングのエンジンを使用したパーティションテーブル

MySQL 8.0 ドキュメントによると、現在、InnoDB と NDB の 2 つのストレージエンジンがネイティブパーティショニングのサポートを提供しています。このうち、Aurora MySQL バージョン 3 では InnoDB のみがサポートされており、MySQL 8.0 と互換性があります。他のストレージエンジンを使用して MySQL 8.0 でパーティションテーブルを作成しようとすると失敗します。この事前チェックでは、非ネイティブパーティショニングを使用している DB クラスター内のテーブルを検索します。もし何かが返された場合は、パーティショニングを削除するか、ストレージエンジンを InnoDB に変換する必要があります。

出力例:

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

ここでは、MyISAM テーブルでパーティショニングが使用されているため、アップグレードを続行する前にアクションが必要です。

事前チェックレベル: Error

旧日時型の使用

"旧日時" とは、MySQL バージョン 5.5 以下で作成された日時型の列 (TIMESTAMP や DATETIME など) を指します。MySQL 8.0 では、これらの旧日時データ型のサポートは廃止されます。つまり、データベースにこれらの旧日時型が含まれている場合、MySQL 5.7 から 8.0 へのインプレースアップグレードは不可能です。これを修正するには、アップグレードに進む前に、このような旧日時データ型を含むテーブルを再構築する必要があります。

MySQL 5.7 での旧日時データ型の廃止の詳細については、このブログを参照してください。MySQL 8.0 での旧日時データ型の廃止の詳細については、このブログを参照してください。

出力例:

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

テーブル test.55_temporal_table の timestamp_column 列にエラーが報告されます。これは、サポートされなくなった旧日時ディスクストレージ形式を使用しているためです。

この問題を解決してアップグレードを続行できるようにするには、テーブルを再構築して、旧日時ディスクストレージ形式を MySQL 5.6 で導入された新しい形式に変換します。変換の詳細および前提条件については、MySQL ドキュメントの「Converting Between 3-Byte and 4-Byte Unicode Character Sets」を参照してください。

次のコマンドを実行して、この事前チェックで説明されているテーブルを再構築すると、旧日時型が小数秒の精度で新しい形式に変換されます。

ALTER TABLE ... ENGINE=InnoDB;

テーブルの再構築についての詳細は、MySQL ドキュメントの「ALTER TABLE Statement」を参照してください。

問題のテーブルを再構築し、アップグレードを再開すると、互換性チェックに合格し、アップグレードを続行できます。

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

共有テーブルスペースでのパーティションテーブルの使用

MySQL 8.0.13 以降、共有テーブルスペースにテーブルパーティションを配置するサポートは廃止されます。アップグレードする前に、そのようなテーブルを共有テーブルスペースから file-per-table テーブルスペースに移動します。

出力例:

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

テーブル test.partInnoDBTable のパーティション p1 がシステムテーブルスペースにあるため、事前チェックに失敗します。

この問題を解決するには、test.partInnodbTable テーブルを再構築し、問題のあるパーティションを file-per-table テーブルスペースの p1 に配置します。

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

そうすると、事前チェックに合格します。

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

最新の MySQL バージョンから削除された関数の使用

MySQL 8.0 では、いくつかの組み込み関数が削除されました。この事前チェックでは、これらの関数を使用する可能性のあるオブジェクトについてデータベースを調べます。見つかった場合は、エラーが返されます。アップグレードを再試行する前に、問題を解決する必要があります。

削除された関数の大部分は空間関数であり、同等の ST_* 関数に置き換えられました。このような場合は、新しいプロシージャ命名を使用するようにデータベースオブジェクトを変更します。詳細については、MySQL ドキュメントの「MySQL 8.0 で削除された機能」を参照してください。

出力例:

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

事前チェックでは、test.GetLocationsInPolygon ストアドプロシージャが POLYGONFROMTEXT と POINTFROMTEXT の 2 つの削除された関数を使用していることが報告されます。また、新しい ST_POLYGONFROMTEXT と ST_POINTFROMTEXT を代替として使用することが提案されます。提案を使用してプロシージャを再作成すると、事前チェックは正常に完了します。

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

ルーチンのようなオブジェクトの MySQL 構文チェック

MySQL 8.0 では、以前に予約されていなかった予約キーワードがあります。アップグレード事前チェッカーは、データベースオブジェクトの名前およびその定義と本文で、予約キーワードの使用を評価します。ストアドプロシージャ、関数、イベント、トリガーなどのデータベースオブジェクトで予約キーワードが使用されていることが検出されると、アップグレードは失敗し、エラーが upgrade-prechecks.log ファイルに発行されます。この問題を解決するには、アップグレード前にこれらのオブジェクト定義を更新し、そのような参照を一重引用符 (') で囲む必要があります。MySQL の予約語のエスケープについての詳細は、MySQL ドキュメントの「String Literals」を参照してください。

または、名前を別の名前に変更することもできます。そのため、アプリケーションの変更が必要になる場合があります。

出力例:

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
         "level": "Error",
         "dbObject": "test.select_res_word",
         "description": "at line 2,18: unexpected token 'except'",
         "dbObjectType": "Routine"
      }
  ]
}

この問題を修正するには、ルーチン定義を確認します。

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

プロシージャは、MySQL 8.0 の新しいキーワードである except という名前のテーブルを使用します。文字列リテラルをエスケープして、プロシージャを再作成します。

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

これで、事前チェックに合格です。

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

ファイルの削除または破損によるスキーマの不一致

前述したように、MySQL 8.0 は、mysql スキーマ内の内部 InnoDB テーブルのセットにすべてのメタデータを保存するアトミックデータディクショナリを導入しました。この新しいアーキテクチャは、古いファイルベースのアプローチから "アトミック DDL" 問題を解決し、データベースメタデータを管理するトランザクションの ACID 準拠の方法を提供します。MySQL 8.0 より前では、DDL オペレーションが予期せず中断した場合、スキーマオブジェクトが孤立する可能性がありました。アップグレード中にファイルベースのメタデータを新しいアトミックデータディクショナリテーブルに移行すると、DB インスタンスにこのような孤立したスキーマオブジェクトがないことが保証されます。孤立したオブジェクトが発生した場合、アップグレードは失敗します。

アップグレードを開始する前にこれらの孤立したオブジェクトを検出しやすくするため、schemaInconsistencyCheck 事前チェックが実行されて、すべてのデータディクショナリメタデータオブジェクトが同期されていることを確認します。孤立したメタデータオブジェクトが検出されると、アップグレードは続行されません。アップグレードを続行するには、これらの孤立したメタデータオブジェクトをクリーンアップします。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

出力例:

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

事前チェックでは、test.schemaInconsistencyCheck_failure テーブルに一貫性のないメタデータがあることが報告されます。この場合、テーブルは InnoDB ストレージエンジンメタデータ (information_schema.INNODB_SYS_TABLES) に存在しますが、MySQL メタデータ (information_schema.TABLES) には存在しません。

事前チェックレベル: Error

Aurora DDL リカバリ機能に関連するアーティファクトをチェックする

Aurora MySQL でのデータ定義言語 (DDL) リカバリ実装の一環として、実行中の DDL ステートメントのメタデータは mysql スキーマの ddl_log_md_table および ddl_log_table テーブルに保持されます。Aurora の DDL リカバリの実装は、MySQL 8.0 の新しいアトミックデータディクショナリ実装の一部であるため、バージョン 3 以降ではサポートされていません。互換性チェック中に DDL ステートメントが実行されている場合、この事前チェックが失敗する可能性があります。DDL ステートメントが実行されていない間は、アップグレードを試すことをお勧めします。

この事前チェックが実行中の DDL ステートメントなしで失敗する場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

DDL ステートメントが実行されている場合、事前チェック出力は次のメッセージを出力します。

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

出力例:

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

事前チェックは、互換性チェックと同時に実行中の DDL が原因でエラーを返しました。DDL を実行せずにアップグレードを再試行することをお勧めします。

事前チェックレベル: Error

mysql.rds_upgrade_prechecks テーブルの存在を確認する

これは、RDS サービスによって実行される内部のみの事前チェックです。エラーはアップグレード時に自動的に処理されます。これらのエラーは無視して問題ありません。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

Aurora 高速 DDL 機能に関連するアーティファクトをチェックする

高速 DDL 最適化は、一部の DDL オペレーションの効率を向上させるために、Aurora MySQL バージョン 2 のラボモードで導入されました。Aurora MySQL バージョン 3 では、ラボモードが削除され、高速 DDL 実装は、Instant DDL と呼ばれる MySQL 8.0 機能に置き換えられました。

Aurora MySQL バージョン 3 にアップグレードする前に、ラボモードで高速 DDL を使用するテーブルは、Aurora MySQL バージョン 3 との互換性を確保するために OPTIMIZE TABLE または ALTER TABLE ... ENGINE=InnoDB コマンドを実行して再構築する必要があります。

この事前チェックは、このようなテーブルのリストを返します。返されたテーブルが再構築されたら、アップグレードを再試行できます。

出力例:

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

事前チェックでは、テーブル test.test に保留中の高速 DDL オペレーションがあることが報告されます。

アップグレードを続行できるようにするには、テーブルを再構築し、アップグレードを再試行します。

mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)

テーブルを再構築すると、事前チェックに成功します。

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

ダングリング FULLTEXT インデックス参照を含むテーブル

MySQL 5.6.26 より前では、全文検索インデックスを削除すると、非表示の FTS_DOC_ID 列と FTS_DOC_ID_INDEX 列が孤立する可能性があります。詳細については、「バグ #76012」を参照してください。

これが発生した MySQL の以前のバージョンでテーブルが作成されている場合、Aurora MySQL バージョン 3 へのアップグレードが失敗する可能性があります。この事前チェックでは、MySQL 8.0 にアップグレードする前に、このような孤立した、または "ダングリング" FULLTEXT インデックスが DB クラスターに存在しないことを確認します。この事前チェックが失敗した場合は、そのようなダングリング FULLTEXT インデックスを含むテーブルを再構築します。

出力例:

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_fts_index",
        "description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
      }
  ]
},

test.table_with_fts_index テーブルにダングリング FULLTEXT インデックスが含まれているため、エラーが事前チェックによってレポートされます。アップグレードを続行できるようにするには、FULLTEXT インデックスの補助テーブルをクリーンアップするようにテーブルを再構築します。OPTIMIZE TABLE test.table_with_fts_index または ALTER TABLE test.table_with_fts_index, ENGINE=INNODB を使用します。

テーブルを再構築すると、事前チェックに合格します。

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

ibd ファイルパスに関連する不整合をチェックする

この事前チェックは、Aurora MySQL バージョン 3.03.0 以前にのみ適用されます。この事前チェックでエラーが発生した場合は、Aurora MySQL バージョン 3.04 以降にアップグレードします。

出力例:

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

スペース ID がゼロの FULLTEXT インデックスをチェックする

MySQL では、InnoDB テーブルに FULLTEXT インデックスを追加すると、多数の補助インデックステーブルスペースが作成されます。バージョン 5.6.20 で修正された以前のバージョンの MySQL のバグにより、これらの補助インデックステーブルが、独自の InnoDB テーブルスペースではなく、システムテーブルスペースに作成された可能性があります。

このような補助テーブルスペースが存在する場合、アップグレードは失敗します。事前チェックエラーに記載されている FULLTEXT インデックスを再作成し、アップグレードを再試行します。

出力例:

{
  "id": "auroraUpgradeCheckForFtsSpaceIdZero",
  "title": "Check for fulltext index with space id as zero",
  "status": "OK",
  "description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.fts_space_zero_check",
        "description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
      }
  ]
},

システムテーブルスペースに補助全文検索 (FTS) テーブルがあるため、この事前チェックは test.fts_space_zero_check テーブルのエラーを報告します。

このテーブルに関連付けられた FTS インデックスを削除して再作成すると、事前チェックは成功します。

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

事前チェックレベル: Error

準備済み状態の XA トランザクションをチェックする

メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスをクリーンシャットダウンする必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。トランザクションのロールバックが必要なため、データベースに準備済み状態の XA トランザクションがある場合、クリーンシャットダウンの進行をブロックできます。このため、準備済みの XA トランザクションが検出されると、コミットまたはロールバックするアクションを実行するまでアップグレードを続行できなくなります。

XA RECOVER を使用して準備された状態で XA トランザクションを検索する方法の詳細については、MySQL ドキュメントの「XA Transaction SQL Statements」を参照してください。XA トランザクションの状態の詳細については、MySQL ドキュメントの「XA Transaction States」を参照してください。

出力例:

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
      }
  ]
}

この事前チェックでは、コミットまたはロールバックする必要がある準備済み状態のトランザクションがあるため、エラーが報告されます。

データベースにログインしたら、information_schema.innodb_trx テーブルと XA RECOVER 出力で詳細を確認できます。

mysql> select trx_started,
    trx_mysql_thread_id,
    trx_id,trx_state,
    trx_operation_state,
    trx_rows_modified,
    trx_rows_locked 
from 
    information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started         | trx_mysql_thread_id | trx_id  | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 |                   0 | 2849470 | RUNNING   | NULL                |                 1 |               0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)

mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        1 |            6 |            0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)

この場合、準備済みのトランザクションをロールバックします。

mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)

XA トランザクションがロールバックされると、事前チェックは成功します。

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

現在のインスタンスクラスでアップグレードがサポートされているかどうかを確認する

ライター DB インスタンスクラスが db.r6i.32xlarge である Aurora MySQL バージョン 2.12.0 または 2.12.1 からのインプレースアップグレードの実行は現在サポートされていません。この場合、事前チェックはエラーを返します。アップグレードを続行できるようにするには、DB インスタンスクラスを db.r6i.24xlarge 以下に変更します。または、Aurora MySQL バージョン 2.12.2 以降にアップグレードできます。Aurora MySQL バージョン 3 へのインプレースアップグレードは db.r6i.32xlarge でサポートされています。

出力例:

{
  "id": "auroraUpgradeCheckForInstanceLimit",
  "title": "Checks if upgrade is supported on the current instance class",
  "status": "OK",
  "description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
      }
  ]
},

ライター DB インスタンスが db.r6i.32xlarge インスタンスクラスを使用し、Aurora MySQL バージョン 2.12.1 で実行されているため、事前チェックはエラーを返します。

事前チェックレベル: Error

8.0 の内部ユーザーをチェックする

この事前チェックは、Aurora MySQL バージョン 3.03.0 以前にのみ適用されます。この事前チェックでエラーが発生した場合は、Aurora MySQL バージョン 3.04 以降にアップグレードします。

出力例:

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

RDS マスターユーザーが存在するかどうかを確認する

MySQL 8 は、権限管理をより簡単かつきめ細かなものにするために、ロールと動的権限をサポートする新しい権限モデルを追加しました。この変更の一環として、Aurora MySQL は新しい rds_superuser_role を導入しました。これは、Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード時にデータベースのマスターユーザーに自動的に付与されます。

Aurora MySQL のマスターユーザーに割り当てられたロールと権限の詳細については、「マスターユーザーアカウント権限」を参照してください。Aurora MySQL バージョン 3 のロールベースの特権モデルの詳細については、「ロールベースの特権モデル」を参照してください。

この事前チェックは、マスターユーザーがデータベースに存在することを確認します。マスターユーザーが存在しない場合、事前チェックに失敗します。アップグレードを続行できるようにするには、マスターユーザーのパスワードをリセットするか、ユーザーを手動で作成して、マスターユーザーを再作成します。次に、アップグレードを再試行します。マスターユーザーのパスワードのリセットについての詳細は、「データベースマスターユーザーのパスワードの変更」を参照してください。

出力例:

{
  "id": "auroraUpgradeCheckForMasterUser",
  "title": "Check if master user exists",
  "status": "OK",
  "description": "Throws error if master user has been dropped!",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
      }
  ]
}

マスターユーザーのパスワードをリセットすると、事前チェックに合格し、アップグレードを再試行できます。

次の例では、AWS CLI を使用してパスワードをリセットします。パスワードの変更は即時適用されます。

aws rds modify-db-cluster \
    --db-cluster-identifier my-db-cluster \
    --master-user-password my-new-password

その後、事前チェックは成功します。

{
  "id": "auroraUpgradeCheckForMasterUser",
  title": "Check if master user exists",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

プレフィックスインデックスのジオメトリ列をチェックする

MySQL 8.0.12 以降、GEOMETRY データ型を使用して列にプレフィックス付きインデックスを作成することはできなくなります。詳細については、WL#11808 を参照してください。

このようなインデックスが存在する場合、アップグレードは失敗します。問題を解決するには、事前チェックの失敗で言及されたテーブルのプレフィックス付き GEOMETRY インデックスを削除します。

出力例:

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.geom_index_prefix",
        "description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
      }
  ]
}

test.geom_index_prefix テーブルの GEOMETRY 列にプレフィックスが付いたインデックスが含まれているため、事前チェックはエラーを報告します。

このインデックスを削除すると、事前チェックは成功します。

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

ストアドプロシージャの特殊文字に関連する不整合をチェックする

MySQL 8.0 より前では、データベース名、テーブル名、およびその他のオブジェクトは、データディレクトリ内のファイル、つまりファイルベースのメタデータに対応していました。MySQL 8.0 へのアップグレードの一環として、すべてのデータベースオブジェクトは、mysql スキーマに保存されている新しい内部データディクショナリテーブルに移行され、新しく実装されたアトミックデータディクショナリをサポートします。ストアドプロシージャの移行の一環として、各プロシージャのプロシージャ定義と本文は、新しいデータディクショナリに取り込まれるときに検証されます。

MySQL 8 より前では、場合によっては、保存されたルーチンを作成したり、特殊文字を含むプロシージャを mysql.proc テーブルに直接挿入したりできました。例えば、非準拠の改行なしスペース文字 \xa0 を含むコメントが含まれたストアドプロシージャを作成できます。このようなプロシージャが検出されると、アップグレードは失敗します。

この事前チェックは、ストアドプロシージャの本文と定義にそのような文字が含まれていないことを検証します。アップグレードを続行できるようにするには、これらのストアドプロシージャを非表示文字または特殊文字なしで再作成します。

出力例:

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "description": "Following procedure(s) has special characters inconsistency.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "information_schema.routines",
        "description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
      }
  ]
}

事前チェックでは、DB クラスターに、プロシージャ本文に特殊文字を含む test データベース内の get_version_proc というプロシージャが含まれていることが報告されます。

ストアドプロシージャを削除して再作成すると、事前チェックが成功し、アップグレードを続行できます。

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "detectedProblems": []
},

事前チェックレベル: Error

sys スキーマのオブジェクトタイプの不一致を確認する

sys スキーマは、ユーザーが DB インスタンスのトラブルシューティング、最適化、モニタリングを行うのに役立つ MySQL データベース内のオブジェクトとビューのセットです。Aurora MySQL バージョン 2 からバージョン 3 へのメジャーバージョンアップグレードを実行すると、sys スキーマビューが再作成され、新しい Aurora MySQL バージョン 3 定義に更新されます。

アップグレードの一環として、sys スキーマ内のオブジェクトがビューではなくストレージエンジン (INFORMATION_SCHEMA.TABLES の sys_config/BASE TABLE) を使用して定義されている場合、アップグレードは失敗します。このようなテーブルは、information_schema.tables テーブルにあります。これは予想される動作ではありませんが、ユーザーエラーが原因で発生する場合があります。

この事前チェックでは、すべての sys スキーマオブジェクトを検証して、ユーザーが正しいテーブル定義を使用し、ビューが誤って InnoDB または MyISAM テーブルとして定義されていないことを確認します。問題を解決するには、返されたオブジェクトの名前を変更または削除して手動で修正します。次に、アップグレードを再試行します。

出力例:

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "description": "Database contains objects with type mismatch for sys schema.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "sys.waits_global_by_latency",
        "description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
      }
  ]
}

事前チェックでは、sys スキーマの sys.waits_global_by_latency ビューに、アップグレードの進行を妨げているタイプの不一致があることが報告されます。

DB インスタンスにログインすると、このオブジェクトがビューになるタイミングで InnoDB テーブルとして定義されていることがわかります。

mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
       Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
  `events` varchar(128) DEFAULT NULL,
  `total` bigint(20) unsigned DEFAULT NULL,
  `total_latency` text,
  `avg_latency` text,
  `max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

この問題を解決するには、正しい定義でビューを削除して再作成するか、名前を変更します。アップグレードプロセス中に、ビューは正しいテーブル定義で自動的に作成されます。

mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)

これを行うと、事前チェックに合格します。

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

ビュー内の列名の上限を確認する

MySQL の列名の最大許容長は 64 文字です。MySQL 8.0 より前では、場合によっては 64 文字を超える列名でビューを作成できました。このようなビューがデータベースインスタンスに存在する場合、事前チェックエラーが返され、アップグレードは失敗します。アップグレードを続行できるようにするには、問題のビューを再作成し、列の長さが 64 文字未満であることを確認する必要があります。次に、アップグレードを再試行します。

出力例:

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "description": "Following view(s) has column(s) with length greater than 64.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
        "description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
      }
  ]
}

事前チェックでは、test.colname_view_test ビューに最大許容列長である 64 文字を超える列 col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad が含まれていることが報告されます。

ビュー定義を見ると、問題のある列が表示されます。

mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field                                                            | Type        | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1                                                             | varchar(20) | YES  |     | NULL    |       |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11)     | YES  |     | NULL    |       |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

アップグレードを続行できるようにするには、列の長さが 64 文字を超えないようにして、ビューを再作成します。

mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)

mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)

mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1       | varchar(20) | YES  |     | NULL    |       |
| col2_nopad | int(11)     | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

これを行うと、事前チェックは成功します。

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

小さな列でプレフィックスの長さが 255 バイトを超えるインデックスが定義されているテーブルをチェックする

MySQL でバイナリデータ型を使用して列にインデックスを作成する場合は、インデックス定義にプレフィックスの長さを追加する必要があります。MySQL 8.0 より前では、場合によっては、このようなデータ型の最大許容サイズを超えるプレフィックス長を指定できました。例として TINYTEXT 列と TINYBLOB 列があります。最大許容データサイズは 255 バイトですが、これより大きいインデックスプレフィックスが許可されていました。詳細については、MySQL ドキュメントの「InnoDB Limits」を参照してください。

この事前チェックが失敗した場合は、問題のあるインデックスを削除するか、TINYTEXT 列と TINYBLOB 列のインデックスのプレフィックス長を 255 バイト未満に減らします。次に、アップグレードを再試行します。

出力例:

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.tintxt_prefixed_index.col1",
        "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
      }
  ]
}

TINYTEXT 列または TINYBLOB 列に 255 バイトを超えるプレフィックス PRIMARY を持つインデックスがあるため、このプレチェックは test.tintxt_prefixed_index テーブルのエラーを報告します。

このテーブルの定義を見ると、プライマリキーの TINYTEXT 列 col1 のプレフィックスが 65 であることがわかります。テーブルは、1 文字あたり 4 バイトを格納する utf8mb4 文字セットを使用して定義されるため、プレフィックスは 255 バイトの制限を超えています。

mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
       Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
  `col1` tinytext NOT NULL,
  `col2` tinytext,
  `col_id` tinytext,
  PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)

utf8mb4 文字セットの使用中にインデックスプレフィックスを 63 に変更すると、アップグレードを続行できます。

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD  PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

これを行うと、事前チェックは成功します。

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Error

mysql.host テーブルに欠落している InnoDB メタデータの不整合を確認する

これは、RDS サービスによって実行される内部のみの事前チェックです。エラーはアップグレード時に自動的に処理されます。これらのエラーは無視して問題ありません。

この事前チェックでエラーが発生した場合は、AWS サポートでケースを開き、メタデータの不整合の解決をリクエストします。または、論理ダンプを実行してから新しい Aurora MySQL バージョン 3 DB クラスターに復元することで、アップグレードを再試行することもできます。

事前チェックレベル: Error

無効な utf8mb3 列コメントをチェックする

この事前チェックでは、無効な utf8mb3 文字エンコーディングの列コメントを含むテーブルを特定します。MySQL 8.0 では、列コメントを含むメタデータの文字エンコーディングに、より厳格な検証が適用されます。列コメントに含まれている文字が utf8mb3 文字セットの有効な文字でない場合、アップグレードは失敗します。

この問題の最も一般的な原因は、列コメントに BMP (基本多言語面) 以外の文字が存在することです。BMP 以外の文字には 4 バイトの UTF-8 エンコード (utf8mb4) が必要ですが、utf8mb3 は 3 バイトのシーケンスのみをサポートしており、これらの文字を表すことはできません。

この問題を解決するには、アップグレードを試みる前に、列コメントを変更して BMP 以外の文字を削除または置換する必要があります。列コメントを更新するには、ALTER TABLE ステートメントを使用できます。

出力例:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.t2",
        "description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
      }
  ]
}

事前チェックでは、1 つ以上の列コメントに無効な utf8mb3 文字 (特に BMP 以外の文字) が test.t2 テーブルに含まれていることがレポートされます。

この問題を解決するには、問題のある列を特定し、コメントを更新できます。まず、テーブル構造を調べて、コメントのある列を特定します。

mysql> SHOW CREATE TABLE test.t2\G

問題のあるコメントを含む列を特定したら、ALTER TABLE ステートメントを使用して更新します。例:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';

または、コメントを完全に削除することもできます。

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';

問題のある列コメントをすべて更新すると、事前チェックに合格し、アップグレードを続行できます。

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Warning

デフォルトの認証プラグインに関する新しい考慮事項

MySQL 8.0 では、caching_sha2_password 認証プラグインが導入され、廃止された mysql_native_password プラグインよりもパスワード暗号化の安全性とパフォーマンスが向上しました。Aurora MySQL バージョン 3 の場合、データベースユーザーに使用されるデフォルトの認証プラグインは mysql_native_password プラグインです。

この事前チェックは、このプラグインが削除され、将来のメジャーバージョンリリースでデフォルトが変更されることを警告します。この変更の前に、アプリケーションクライアントとユーザーの互換性を評価することを検討してください。

詳細については、MySQL ドキュメントの「caching_sha2_password Compatibility Issues and Solutions」を参照してください。

出力例:

{
  "id": "defaultAuthenticationPlugin",
  "title": "New default authentication plugin considerations",
  "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},

事前チェックレベル: Warning

廃止された MAXDB sql_mode フラグの使用

MySQL 8.0 では、非推奨の sql_mode システム変数オプションがいくつか削除されました。そのうちの 1 つは MAXDB です。この事前チェックでは、現在接続されているすべてのセッションをルーチンおよびトリガーとともに調べ、MAXDB を含む任意の組み合わせに sql_mode が設定されていないことを確認します。

出力例:

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.maxdb_stored_routine",
        "description": "PROCEDURE uses obsolete MAXDB sql_mode",
        "dbObjectType": "Routine"
      }
  ]
}

事前チェックでは、test.maxdb_stored_routine ルーチンにサポートされていない sql_mode オプションが含まれていることが報告されます。

データベースにログインすると、sql_mode に MAXDB が含まれるルーチン定義が表示されます。

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

問題を解決するには、クライアントで正しい sql_mode を設定した後にプロシージャを再作成します。

サポートされていない sql_mode なしでプロシージャを再作成します。

mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
    -> SQL SECURITY DEFINER
    -> BEGIN
    ->     SELECT * FROM test;
    -> END$$
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

事前チェックは成功しました。

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "detectedProblems": []
}

事前チェックレベル: Warning

オブジェクト名に非推奨の単一のドル記号が使用されているかどうかをチェックする

MySQL 8.0.32 以降、引用符で囲まれていない識別子の最初の文字としてドル記号 ($) の使用が廃止されます。$ を最初の文字として含むスキーマ、テーブル、ビュー、列、またはルーチンがある場合、この事前チェックは警告を返します。この警告はアップグレードの進行を妨げませんが、すぐに対応して解決することをお勧めします。MySQL 8.4 以降、このような識別子は警告ではなく構文エラーを返します。

出力例:

{
  "id": "mysqlDollarSignNameCheck",
  "title": "Check for deprecated usage of single dollar signs in object names",
  "status": "OK",
  "description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.$deprecated_syntx",
        "description": " name starts with $ sign."
      }
  ]
},

test スキーマの $deprecated_syntx テーブルに最初の文字として $ が含まれているため、事前チェックは警告を報告します。

事前チェックレベル: Warning

新しい予約キーワードと競合する名前を持つデータベースオブジェクトの使用

このチェックは、新しい予約キーワードと競合する名前を持つデータベースオブジェクトの使用を確認する点で、routineSyntaxCheck に似ています。アップグレードはブロックされませんが、警告を慎重に評価する必要があります。

出力例:

except という名前のテーブルで前の例を使用すると、事前チェックは警告を返します。

{
  "id": "reservedKeywordsCheck",
  "title": "Usage of db objects with names conflicting with new reserved keywords",
  "status": "OK",
  "description": "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.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.except",
        "description": "Table name",
        "dbObjectType": "Table"
      }
  ]
}

この警告は、確認すべきアプリケーションクエリが存在する可能性があることを知らせます。アプリケーションクエリが文字列リテラルから正しくエスケープされていない場合、MySQL 8.0 にアップグレードした後にエラーが発生する可能性があります。アプリケーションを確認するために、バージョン 3 で実行されている Aurora MySQL DB クラスターのクローンまたはスナップショットに対してテストを実行します。

アップグレード後に失敗するエスケープされていないアプリケーションクエリの例:

SELECT * FROM escape;

アップグレード後に成功する、正しくエスケープされたアプリケーションクエリの例:

SELECT * FROM 'escape';

事前チェックレベル: Warning

utf8mb3 文字セットの使用

MySQL 8.0 では、utf8mb3 文字セットは廃止され、今後の MySQL メジャーバージョンで削除されます。この事前チェックは、この文字セットを使用するデータベースオブジェクトが検出された場合に警告を生成するために実装されます。これによりアップグレードの進行が妨げられることはありませんが、MySQL 8.0 のデフォルトである utf8mb4 文字セットにテーブルを移行することを検討するよう強くお勧めします。utf8mb3 と utf8mb4 の詳細については、MySQL ドキュメントの「Converting Between 3-Byte and 4-Byte Unicode Character Sets」を参照してください。

出力例:

{
  "id": "utf8mb3",
  "title": "Usage of utf8mb3 charset",
  "status": "OK",
  "description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.t1.col1",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      },
      {
        "level": "Warning",
        "dbObject": "test.t1.col2",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      }
  ]
}

この問題を解決するには、参照されているオブジェクトとテーブルを再構築します。変換の詳細および前提条件については、MySQL ドキュメントの「Converting Between 3-Byte and 4-Byte Unicode Character Sets」を参照してください。

事前チェックレベル: Warning

DATE、DATETIME、および TIMESTAMP のゼロ値

MySQL では、DATE、DATETIME、および TIMESTAMP の列でゼロ値の使用に関するより厳格なルールが適用されるようになりました。NO_ZERO_IN_DATE および NO_ZERO_DATE SQL モードは、今後の MySQL リリースで strict モードとマージされるため、strict モードと組み合わせて使用することをお勧めします。

事前チェックの実行時に、データベース接続の sql_mode 設定にこれらのモードが含まれていない場合、事前チェックで警告が発生します。ユーザーは、ゼロ値を含む DATE、DATETIME、および TIMESTAMP 値を挿入できる場合があります。ただし、ゼロ値は、将来動作が変化し、正しく機能しない可能性があるため、有効な値に置き換えることを強くお勧めします。これは警告であるため、アップグレードはブロックされませんが、アクションを実行する計画を開始することをお勧めします。

出力例:

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
  ]
}

事前チェックレベル: Warning

クラスターのロールバックセグメント履歴リストの長さが長いかどうかを確認する

auroraUpgradeCheckForIncompleteXATransactions で説明されているように、メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスをクリーンシャットダウンする必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。

DB クラスターのロールバックセグメント履歴リストの長さ (HLL) が長い場合、InnoDB が undo ログレコードの消去を完了するのにかかる時間が長くなり、メジャーバージョンのアップグレードプロセス中にダウンタイムが長くなる可能性があります。事前チェックで DB クラスターの HLL が高いことが検出されると、警告を発生します。これによりアップグレードの進行が妨げられることはありませんが、DB クラスターの HLL を注意深くモニタリングすることをお勧めします。低いレベルに保つと、メジャーバージョンのアップグレードに必要なダウンタイムが短縮されます。HLL のモニタリングの詳細については、「InnoDB 履歴リストの長さが大幅に増加しました」を参照してください。

出力例:

{
  "id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
  "title": "Checks if the rollback segment history length for the cluster is high",
  "status": "OK",
  "description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_metrics",
        "description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
      }
  ]
}

事前チェックでは、データベースクラスターの InnoDB undo HLL が長い (82989114) ことが検出されたため、警告が返されます。アップグレードは続行されますが、パージする undo の量によっては、アップグレードプロセスに必要なダウンタイムが延長される可能性があります。

本番環境でアップグレードを実行する前に、DB クラスターのオープントランザクションを調査し、HLL が管理可能なサイズに保たれていることを確認することをお勧めします。

事前チェックレベル: Warning

コミットされていない行の変更が多数あるかどうかを確認する

auroraUpgradeCheckForIncompleteXATransactions で説明されているように、メジャーバージョンアップグレードプロセスの実行中に、Aurora MySQL バージョン 2 DB インスタンスをクリーンシャットダウンする必要があります。これにより、すべてのトランザクションがコミットまたはロールバックされ、InnoDB がすべての undo ログレコードを消去します。

DB クラスターに多数の行を変更したトランザクションがある場合、クリーンシャットダウンプロセスの一環として、InnoDB がこのトランザクションのロールバックを完了するのにかかる時間を延長できます。事前チェックで、DB クラスターに多数の行が変更された実行時間が長いトランザクションが見つかった場合、警告が発生します。これによりアップグレードの進行が妨げられるわけではありませんが、DB クラスター上のアクティブなトランザクションのサイズを注意深くモニタリングすることをお勧めします。低いレベルに保つと、メジャーバージョンのアップグレードに必要なダウンタイムが短縮されます。

出力例:

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_trx",
        "description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
      }
  ]
},

事前チェックでは、DB クラスターに、クリーンシャットダウンプロセス中にロールバックする必要がある、コミットされていない行の変更が 11,000,000 件あるトランザクションが含まれていることが報告されます。アップグレードは続行されますが、アップグレードプロセス中のダウンタイムを減らすため、本番稼働用クラスターでアップグレードを実行する前に、これをモニタリングして調査することをお勧めします。

ライター DB インスタンスでアクティブなトランザクションを表示するには、information_schema.innodb_trx テーブルを使用します。ライター DB インスタンスの以下のクエリは、DB クラスターの現在のトランザクション、実行時間、状態、変更された行を示しています。

# Example of uncommitted transaction
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 |                         1592 |                          20041 | 52866130 | RUNNING   |      11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)

# Example of transaction rolling back
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state    | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 |                         1719 |                          20041 | 52866130 | ROLLING BACK |      10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)

トランザクションがコミットまたはロールバックされると、事前チェックは警告を返さなくなります。大規模なトランザクションをロールバックする前に、MySQL ドキュメントとアプリケーションチームに相談してください。トランザクションのサイズによっては、ロールバックの完了までに時間がかかる場合があります。

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "detectedProblems": []
},

InnoDB トランザクション管理の最適化、および MySQL データベースインスタンスで大規模なトランザクションを実行およびロールバックした場合の潜在的な影響の詳細については、MySQL ドキュメントの「Optimizing InnoDB Transaction Management」を参照してください。

事前チェックレベル: Notice

廃止された sql_mode フラグの使用

MAXDB に加えて、次のその他の sql_mode オプションが削除されました: DB2、MSSQL、MYSQL323、MYSQL40、ORACLE、POSTGRESQL、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_TABLE_OPTIONS。MySQL 8.0 以降、これらの値を sql_mode システム変数に割り当てることはできません。この事前チェックでこれらの sql_mode 設定を使用して開いているセッションが見つかった場合は、DB インスタンスと DB クラスターのパラメータグループ、およびクライアントアプリケーションと設定が無効にするよう更新されていることを確認してください。– 詳細については、「MySQL ドキュメント」を参照してください。

出力例:

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

これらの事前チェックの失敗を解決するには、「maxdbFlagCheck」を参照してください。

事前チェックレベル: Error、Warning、または Notice

check table x for upgrade コマンドによって報告された問題

Aurora MySQL バージョン 3 へのアップグレードを開始する前に、check table for upgrade は DB クラスター内のユーザースキーマの各テーブルで実行されます。この事前チェックは checkTableMysqlSchema とは異なります。

check table for upgrade コマンドは、MySQL の新しいバージョンへのアップグレード中に発生する可能性のある問題がないかテーブルを調べます。アップグレードを試行する前にこのコマンドを実行すると、互換性がない箇所を事前に特定して解決できるため、実際のアップグレードプロセスがよりスムーズになります。

このコマンドは、次のような各テーブルに対してさまざまなチェックを実行します。

他の事前チェックとは異なり、check table の出力に応じてエラー、警告、または通知を返すことがあります。この事前チェックでテーブルが返された場合は、アップグレードを開始する前に、それらをリターンコードとメッセージとともに慎重に確認してください。詳細については、MySQL ドキュメントの「CHECK TABLE Statement」を参照してください。

ここでは、エラーの例と警告の例を示します。

エラーの例:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.parent",
        "description": "Table 'test.parent' doesn't exist"
      }
  ]
},

事前チェックでは、test.parent テーブルが存在しないというエラーが報告されます。

ライター DB インスタンスの mysql-error.log ファイルには、外部キーエラーがあることを示しています。

2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

ライター DB インスタンスにログインし、show engine innodb status\G を実行して、外部キーエラーに関する詳細情報を取得します。

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.

LATEST FOREIGN KEY ERROR メッセージは、test.parent テーブルを参照する test.child テーブル内の fk_pname 外部キー制約にインデックスの欠落またはデータ型の不一致があることを示します。MySQL ドキュメントの「FOREIGN KEY Constraints」によると、外部キーで参照される列には関連付けられたインデックスが必要であり、親/子列は同じデータ型を使用する必要があります。

これがインデックスの欠落またはデータ型の不一致に関連しているかどうかを確認するには、データベースにログインし、セッション変数 foreign_key_checks を一時的に無効にしてテーブル定義を確認します。そうすると、問題の子制約 (fk_pname) が p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL を使用して親テーブル name varchar(20) NOT NULL を参照していることがわかります。親テーブルは DEFAULT CHARSET=utf8 を使用しますが、子テーブルの p_name 列は latin1 を使用するため、データ型の不一致エラーがスローされます。

mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)

mysql> show create table parent\G
*************************** 1. row ***************************
       Table: parent
Create Table: CREATE TABLE `parent` (
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

この問題を解決するには、親と同じ文字セットを使用するように子テーブルを変更するか、子テーブルと同じ文字セットを使用するように親を変更します。ここでは、子テーブルが p_name 列定義で明示的に latin1 を使用するため、ALTER TABLE を実行して文字セットを utf8 に変更します。

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)

そうすると、事前チェックに合格し、アップグレードを続行できます。

警告の例:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.orders",
        "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
      }
  ]
}

test.orders テーブルの delete_audit_trigg トリガーに CREATED 属性がないため、事前チェックは警告を報告します。MySQL ドキュメントの「Checking Version Compatibility」によると、このメッセージは情報であり、MySQL 5.7.2 より前に作成されたトリガーに対して印刷されます。

これは警告であるため、アップグレードの進行は妨げられません。ただし、問題を解決する場合は、問題のトリガーを再作成できます。事前チェックは警告なしで成功します。

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},