Aurora から 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 で利用可能な照合順序に変更します。

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 では、ユーザーは単一のエンドポイントの背後で複数のリーダーを設定できますが、Cloud SQL for MySQL ユーザーはこの機能をすぐに使用することはできません。Cloud SQL for MySQL の各リードレプリカには独自の IP があり、ユーザーは ProxySQL などを使用して複数のリードレプリカ インスタンス間でトラフィックを分割する必要があります。

ProxySQL を使用して複数のリードレプリカ間でトラフィックを転送する方法を示すガイドをご覧ください。

変更バッファは、セカンダリ インデックス ページがバッファプールにない場合に変更をキャッシュに保存する特別なデータ構造で、後でそれらのページが他の読み取りオペレーションによってバッファプールに読み込まれたときにマージされます。詳細は、バッファの変更をご覧ください。

セカンダリ インデックスを持つテーブルへの書き込みがワークロードで頻繁に行われているユースケースでは、デフォルトの InnoDB 変更バッファ機能を使用して更新を後のステージへ遅らせるため、Aurora は Cloud SQL for MySQL よりも動作が遅くなる可能性があります。ユーザーは、アプリケーションのワークロードに応じてパフォーマンスをベンチマークする必要があります。

クエリ キャッシュは、選択コマンドとその結果を中間ストレージ レイヤに保存します。後で同じステートメントを受け取った場合、サーバーはコマンドを再実行するのではなく、クエリ キャッシュから結果を確認して取得します。クエリ キャッシュはセッションをまたいで共有されるため、すべてのセッションは、他のセッションからの実行済みのステートメントでキャッシュに保存された結果を利用できます。クエリ キャッシュの詳細を確認する。

Aurora はデフォルトでクエリ キャッシュを有効にしますが、MySQL Community は 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 の両方でレプリケーション ラグのベンチマークを行うことをおすすめします。

Cloud SQL for MySQL は、ディスクベースのデータ同期を使用する AWS Aurora とは異なり、GTID レプリケーションを使用します。移行前に、GTID に関する以下の制限事項をユーザー自身で確認し、アプリケーション ワークフローがこれらの機能のいずれかに依存している場合は、アプリケーションに必要な変更を行う必要があります。

• GTID ベースのレプリケーションを使用する場合、CREATE TABLE ... SELECT ステートメントは使用できません。
• CREATE TEMPORARY TABLE ステートメントと DROP TEMPORARY TABLE ステートメントは、トランザクション、プロシージャ、関数、トリガー内ではサポートされていません。GTID を有効にしてこれらのステートメントを使用することは可能ですが、トランザクションの外部でのみ、かつ autocommit=1 の場合に限ります。

GTID ベースの制限の詳細については、GTID の制限事項をご覧ください。