Aurora から Cloud SQL for MySQL へ移行する前の重要な考慮事項
Amazon AWS と Google Cloud はどちらも、クラウドベースのフルマネージド MySQL データベース サービスです。どちらのクラウド サービス プロバイダも、独自の機能とそれぞれのデフォルトの構成には違いがあります。これらの違いにより、あるプロバイダから別のプロバイダに移行した後に、予期しないパフォーマンスや運用の問題が発生する可能性があります。この記事では、このような移行中に発生する可能性のある問題と、推奨される解決策の概要を示します。特に、MySQL データベース サービスの Aurora MySQL から Cloud SQL for MySQL への移行に焦点を当てます。
移行に関する考慮事項
文字セット: パフォーマンスの問題
Aurora は、デフォルトの文字セットサーバー latin1（MySQL v 5.7 まで）を使用します。これは、データベース、テーブル、ストアド プロシージャ、関数の Cloud SQL for MySQL のデフォルト構成とは異なります。デフォルトの構成では、移行時にデフォルトの文字セットとして utf8 で作成されます。その結果、パフォーマンスの問題が発生する可能性があります。
たとえば、ユーザーは latin1 文字セットでテーブルを作成し、ストアド プロシージャや関数を Cloud SQL のデフォルト utf8 文字セットで作成する状況になることがあります。この場合、ストアド プロシージャや関数が変数を utf8 パラメータとして受け取り、その変数を latin1 文字セット内の列値と比較すると、2 つの異なる文字セットの比較と照合順序によってパフォーマンスの問題が発生します。
ルーティンの文字セットは、次のコマンドを使用して確認できます。
|
mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES; |
Aurora（v 5.7 まで）でデフォルトの文字セット（latin1）を使用していた場合は、データをインポートする前に Cloud SQL でデフォルトの文字セットを utf8 から latin1 に変更する必要があります。
別の解決策としては、すべてを utf8 に変更することもできます。ただし、この場合ユーザーは、完全なアプリケーションとデータセットをテストする必要があります。文字セットを変更すると予期しないデータ表現が生じる可能性があるためです。
ユーザーは、以下に示すように、Cloud SQL インスタンスのフラグ セクションでこの設定を編集できます。
文字セット: 互換性の問題
Aurora MySQL 5.7 には、現在 Cloud SQL for MySQL 8.0 でのみ利用可能な多くの照合順序（文字セット utf8mb4 の utf8mb4_0900_ai_ci など）があります。このような照合順序を使用して、Cloud SQL for MySQL 5.7 でデータをインポートすると、「Error '文字セット '#255' はコンパイルされた文字セットではありません」のようなエラー メッセージが表示されます。
この問題を解決するには、これらの照合順序を MySQL バージョン 5.7 で利用可能な照合順序に変更します。
ストレージ エンジン: すべてのテーブルが InnoDB に存在する必要がある
Aurora とは異なり、Cloud SQL for MySQL は MyISAM エンジンをサポートしていません。Aurora から Cloud SQL への移行を開始する前に、すべてのテーブルを InnoDB に変換することをおすすめします。
InnoDB 以外のエンジンにテーブルが存在する場合、ユーザーは「ALTER」コマンドを使用してテーブルのエンジンを変更できます。
|
mysql> alter table table_1 engine='Innodb' ; Query OK, 0 rows affected (2.89 sec) Records: 0 Duplicates: 0 Warnings: 0 |
注: クエリ時間はテーブルサイズによって異なり、同じテーブルに対する他のオペレーションがロックされる場合があります。pt-online-schema-change や gh-ost などのオンライン スキーマ変更ツールを使用して、他のオペレーションをブロックせずにテーブルを変更することもできます。
読み取り接続のエンドポイント
Aurora では、1 つのエンドポイントの背後に複数のリーダーを設定できますが、Cloud SQL for MySQL ユーザーはこの機能をすぐには使用できません。Cloud SQL for MySQL のすべてのリードレプリカには独自の IP があり、ユーザーは ProxySQL などを使用してトラフィックを複数のリードレプリカ インスタンスに分割する必要があります。
Aurora には変更バッファがない
変更バッファは、セカンダリ インデックス ページがバッファプールにないときにそれらのページをキャッシュし、後で他の読み取りオペレーションによってそれらのページがバッファプールに読み込まれたときにマージされる特別なデータ構造です。詳細は、バッファの変更をご覧ください。
セカンダリ インデックスを持つテーブルへの書き込みがワークロードで頻繁に行われているユースケースでは、デフォルトの InnoDB 変更バッファ機能を使用して更新を後のステージへ遅らせるため、Aurora は Cloud SQL for MySQL よりも動作が遅くなる可能性があります。ユーザーは、アプリケーション ワークロードに従ってパフォーマンスのベンチマークを行う必要があります。
クエリのキャッシュはパフォーマンスに影響する可能性がある
クエリ キャッシュは、select コマンドとその結果を中間ストレージ レイヤに保存します。後で同じステートメントを受け取った場合、サーバーはそのコマンドを再度実行するのではなく、クエリ キャッシュから結果を確認して取得します。クエリ キャッシュはセッションをまたいで共有されるため、すべてのセッションは、他のセッションから実行済みのステートメントでキャッシュに保存された結果を利用できます。クエリ キャッシュの詳細を確認する。
Aurora はデフォルトでクエリ キャッシュを有効にしますが、MySQL コミュニティは 5.7 バージョンでクエリ キャッシュを無効にし、8.0 バージョンでは完全に削除しました。Cloud SQL MySQL も同様の変更が適用されています。Aurora のクエリ キャッシュ機能に依存するクエリでは、Cloud SQL MySQL のパフォーマンスが異なる場合があります。実行時間を Aurora と比較し、Cloud SQL MySQL でクエリのパフォーマンスをテストすることをおすすめします。
レプリケーション メカニズムがパフォーマンスに影響する可能性がある
リージョン内のリードレプリカの場合、Aurora は、そのリージョン内の 3 つのアベイラビリティ ゾーンにデータのコピーを持つ、クラスタ ボリュームの概念を使用します。同じデータベース クラスタ内のプライマリとレプリカのすべてがクラスタ ボリュームのデータを単一の論理ボリュームとして認識するため、Aurora のレプリケーション ラグは通常 100 ミリ秒未満です。さらに、クロスリージョン リードレプリカの場合、Aurora はバイナリログベースのレプリケーションではなく、リージョンをまたぐディスクベースのデータ同期を使用します。
つまり、レプリケーションは Aurora のストレージ レイヤによって処理されますが、Cloud SQL for MySQL では、バイナリログをレプリカ インスタンスに転送して MySQL インスタンスが使用されているレプリカでリプレイする標準のレプリケーション メカニズムです。Cloud SQL で並列レプリケーションを構成することで、レプリケーションのパフォーマンスを向上させることができます。並列レプリケーションの設定の詳細をご覧ください。
レプリケーション ラグは、プライマリ インスタンスとレプリカ インスタンスの間のアプリケーションとネットワークの変更データ量によって異なりますが、ほとんどのアプリケーションは Aurora と Cloud SQL for MySQL の両方で、著しく遅れることなく機能します。ただし、書き込み負荷が高く、アプリケーションがレプリカから読み取る場合は、移行前に AWS Aurora と CloudSQL MySQL でレプリケーション ラグのベンチマークを行うことをおすすめします。
グローバル トランザクション識別子（GTID）ベースのレプリケーション
Cloud SQL for MySQL では、ディスクベースのデータ同期を使用する AWS Aurora とは異なり、GTID レプリケーションを使用します。移行前に、以下の GTID の制限事項を確認し、アプリ ワークフローが以下の機能のいずれかに依存している場合は、アプリに必要な変更を加えてください。
- GTID ベースのレプリケーションを使用する場合、CREATE TABLE ... SELECT ステートメントは使用できません。
- CREATE TEMPORARY TABLE と DROP TEMPORARY TABLE ステートメントは、トランザクション、プロシージャ、関数、トリガーではサポートされていません。GTID を有効にしてこれらのステートメントを使用することは可能ですが、トランザクションの外部でのみ、かつ autocommit=1 の場合に限ります。
GTID ベースの制限の詳細については、GTID の制限事項をご覧ください。
関連プロダクトとサービス
Google Cloud は、オンプレミスのデータセンターの廃止から SaaS アプリケーションの実行、基幹業務システムの移行まで、お客様のビジネスニーズに合わせて構築されたマネージド MySQL データベースを提供します。
