December 2, 2024約12分で読めます

DBRE

見えないエラーの原因とは？ Amazon Aurora MySQL 2で発生したDatabase Collationによるmysqldumpコマンドがエラーメッセージなしで処理が終了する現象について

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

エラーメッセージが表示されないまま処理が終了する現象が発生しました。 Aurora MySQL 2からデータをエクスポートする際、mysqldumpコマンドを実行すると、エラーメッセージがなく、exit code 2（Internal Error）で終了することがありました。この状態では、何が間違っているかが見えず、データの不完全なエクスポートが危険でした。その原因は、データベースの照合順序（Collation）がutf8mb4_0900_ai_ciになっていました。これはMySQL 5系では存在しない照合順序で、mysqldumpがそれを認識できず、エラーを出さずに処理が終了したことが原因です。この設定は、トリガーに設定されていたため、特に問題が起きる場面でした。調査では、MySQL 8系のmysqldumpを使えば成功することがわかりました。また、--skip-triggersオプションをつけるとエラーが起きなくなり、トリガーが原因であることが確認されました。トリガーの照合順序をutf8mb4_general_ciに変更したところ、正常にダンプが成功しました。解決には2つの方法があります。 1つは、データベースの照合順序をutf8mb4_general_ciに変更して、MySQL 5.7系のmysqldumpで正常に使えるようにする方法です。もう1つは、MySQL 8.0系のmysqldumpを使うことで、照合順序を変更せずエクスポートできる方法です。どちらも実行可能ですが、環境制約により後者を使うのは難しい場合があります。この事例でわかったのは、エラーメッセージが表示されない現象は非常に危険です。データの不完全なバックアップや移行が起きるリスクがあります。そのため、処理終了後にexit codeを確認することが、実際の運用で非常に重要です。 Aurora MySQL 2はすでにEOLになっており、サポートが終了しています。まだ稼働している場合は、移行を検討する際にはこの問題に注意が必要です。

こんにちは。 DBRE チーム所属の @hoshino です

DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。

弊社における DBRE チーム発足の背景やチームの役割については「KTC における DBRE の必要性」というテックブログをご覧ください。

この記事では、Amazon Aurora MySQL 2からAmazon Aurora MySQL 3への移行の際に mysqldump コマンドで発生したエラーメッセージなしで処理が終了する現象についてご紹介します。少しでも参考になれば幸いです。

エラーの原因

まずはエラーの原因について説明します。今回のエラーメッセージなしで処理が終了する現象は、Amazon Aurora MySQL 2のデータベースのトリガーに設定された照合順序が、MySQL 5系では未対応のutf8mb4_0900_ai_ciだったため、mysqldump がそれを認識できなかったことが原因で発生しました。

原因が判明するまでの調査過程と解決方法を、以下で詳しく説明させていただきます。

発生した現象

Aurora MySQL 2からデータをエクスポートするために、mysqldump コマンドを直接実行しました際に、エラーメッセージが表示されないまま終了してしまう現象が発生しました。

コマンドの実行後に exit code を確認したところ、2（Internal Error）が返されました。エラーが発生していることはわかりましたが、具体的な原因を特定できない状況です。

$ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
2

原因調査

問題の原因を特定するために、以下を実施しました。

まず、別バージョンの mysqldump コマンドを実行した場合の挙動を確認しました。

今回、Aurora MySQL 2に対してMySQL 5.7系の mysqldump コマンドを使用しています。

$ mysqldump --version
mysqldump  Ver 10.13 Distrib 5.7.40, for linux-glibc2.12 (x86_64)

試しにMySQL 8系の mysqldump コマンドでエクスポートを試みました。


$ mysqldump80 --version
mysqldump  Ver 8.0.31 for Linux on x86_64 (MySQL Community Server - GPL)

$ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
0

結果は成功でした。このことから、MySQL のバージョン差異がエラーの原因である可能性が浮上しました。

さらに、mysqldump コマンド自体が内部でエラーを起こしている可能性を考え、さまざまなオプションを試してエラーメッセージの有無を確認しました。その結果、--skip-triggers オプションを付与するとエラーが発生しないことが判明しました。

$ mysqldump --defaults-extra-file=/tmp/sample.cnf --skip-triggers > sample.sql
$ echo $?
0

この結果から、トリガーに関連する部分でエラーが起きていると推測されます。そこで、トリガーの設定を確認しました。

mysql> SHOW TRIGGERS FROM sample_database \G
*************************** 1. row ***************************
             Trigger: sample_trigger
               Event: UPDATE
               Table: sample_table
           Statement: BEGIN
  SET NEW.`lock_version` = OLD.`lock_version` + 1;
END
              Timing: BEFORE
             Created: 2024-10-04 01:06:38.17
            sql_mode: STRICT_TRANS_TABLES
             Definer: sample-user@%
character_set_client: utf8mb4
collation_connection: utf8mb4_general_ci
  Database Collation: utf8mb4_0900_ai_ci
*************************** 2. row ***************************
（以下省略）

ここで、データベースの照合順序（Collation）がutf8mb4_0900_ai_ciになっていることに気付きました。これは MySQL 5系では認識されない照合順序です。

エラーが発生していたテーブルのトリガー定義をutf8mb4_general_ciに修正し、再度 mysqldump コマンドを実行しました。

mysql> SHOW TRIGGERS FROM kinto_terms_tool \G
*************************** 1. row ***************************
             Trigger: sample_trigger
               Event: UPDATE
               Table: sample_table
           Statement: BEGIN
  SET NEW.`lock_version` = OLD.`lock_version` + 1;
END
              Timing: BEFORE
             Created: 2024-10-04 01:06:38.17
            sql_mode: STRICT_TRANS_TABLES
             Definer: sample-user@%
character_set_client: utf8mb4
collation_connection: utf8mb4_general_ci
  Database Collation: utf8mb4_general_ci
*************************** 2. row ***************************
（以下省略）

$ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
0

mysqldump が成功しました。MySQL 8系のコマンドで成功していた理由も、この照合順序の違いで説明できます。

この調査により、トリガーに設定されていたデータベースの照合順序が MySQL 5系では存在しないutf8mb4_0900_ai_ciだったため、mysqldump が失敗していたことが判明しました。

Amazon Aurora MySQL 2 と MySQL 5.7 の関係について

Amazon Aurora MySQL 2は MySQL 5.7 をベースに構築されていますが、完全に同一というわけではありません。AWS は Aurora に独自の拡張機能を実装しており、その中には MySQL 8.0 の一部機能（今回問題となった utf8mb4_0900_ai_ci 照合順序など）も含まれています。

MySQL 5.7 にてutf8mb4_0900_ai_ciを照合順序に指定しようとすると、以下のエラーが発生します。

mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'

一方、Aurora MySQL 2では同じコマンドが正常に実行されます。

mysql> ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
Query OK, 1 row affected (0.03 sec)

mysql> SHOW CREATE DATABASE sample_database;
+------------------+---------------------------------------------------------------------------------------------------------+
| Database         | Create Database                                                                                         |
+------------------+---------------------------------------------------------------------------------------------------------+
| sample_database  | CREATE DATABASE `sample_database` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ |
+------------------+---------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

追加の調査

エラーの原因がトリガーのみなのか検証するために、他の MySQL のオブジェクトも調査します。

Aurora MySQL 2の環境でビュー（VIEW）の照合順序（Collation）をutf8mb4_0900_ai_ciで作成し、そのダンプ時の挙動を確認しました。

CREATE VIEW customer_view AS
SELECT
    customer_name COLLATE utf8mb4_0900_ai_ci AS sorted_name,
    address
FROM
    customers;

mysqldump コマンドを実行すると、エラーなく成功します。

$ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
0

次に、Aurora MySQL 2の環境でストアドプロシージャ（PROCEDURE）の場合も同様に確認しました。

DELIMITER //

CREATE PROCEDURE sample_procedure()
BEGIN
    DECLARE customer_name VARCHAR(255);

    -- 照合順序を指定した文字列操作
    SET customer_name = (SELECT name COLLATE utf8mb4_0900_ai_ci FROM customers WHERE id = 1);
    
    -- 照合順序を使用した比較
    IF customer_name COLLATE utf8mb4_0900_ai_ci = 'sample' THEN
        SELECT 'Match found!';
    ELSE
        SELECT 'No match.';
    END IF;
END //

DELIMITER ;

こちらも問題なくダンプが成功します。

$ mysqldump --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
0

Aurora MySQL 2では、MySQL 5系には存在しない照合順序（Collation）utf8mb4_0900_ai_ciを使用できます。
しかし、mysqldump コマンドが MySQL 5系ベースの場合、この照合順序を認識できず、特にトリガーに関連する部分でエラーが発生することがわかりました。

ビューやストアドプロシージャでは問題が生じないことから、トリガーにおける照合順序の扱いが原因であると推測されます。

解決方法

今回の問題は、トリガーに設定されていたデータベースの照合順序がMySQL 5系では未対応のutf8mb4_0900_ai_ciであったために発生していました。

エラーへの対応としてはデータベースの照合順序（Collation）をutf8mb4_general_ciに変更し、トリガーを再設定しました。これにより、MySQL 5.7系の mysqldump コマンドでも照合順序を正しく認識できるようになり、エクスポートが正常に行えるようになりました。

ALTER DATABASE sample_database CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
-- 必要に応じてトリガーを再作成

別の解決策として、MySQL 8.0系の mysqldump コマンドを使用する方法もあります。MySQL 8.0 系のクライアントはutf8mb4_0900_ai_ciを認識できるため、データベースの照合順序を変更せずにエクスポートが可能です。

$ mysqldump80 --defaults-extra-file=/tmp/sample.cnf > sample.sql
$ echo $?
0

環境や他の依存関係の制約からクライアントのバージョンを簡単に変更できない場合もあります。

おわりに

今回の事例では、mysqldump コマンドがエラーメッセージを表示しないまま終了し、exit code を確認することで初めてエラーが発生していることに気付きました。このようなエラーメッセージなしで処理が終了する現象は、気付かないまま不完全なデータをエクスポート・インポートしてしまうリスクがあります。そのため、データベースのバックアップや移行をする際には、exit code を確認するなど、処理結果をチェックすることが重要です。

Aurora MySQL 2系はすでに EOL（End of Life）を迎えており、サポートが終了しています。まだ稼働している環境があり、移行を検討していることがあればお気をつけください。

KINTOテクノロジーズの最新情報をSNSで発信中！イベント・テックブログ更新情報もお届けします。