MySQL から Azure Database for MySQL へのデータ移行 - MySQL 整合性スナップショット
MySQL 整合性スナップショットは、進行中の CRUD (作成、読み取り、更新、削除) 操作がある場合でも、ソース側のデータ整合性を失うことなく、ユーザーが MySQL サーバーの整合性スナップショットを作成できる新機能です。 この機能により、ソース サーバーを読み取り専用モードに設定することなく、トランザクションの整合性を実現します。 さらに、読み取りロック付きの整合性スナップショットを有効にする (GA)、ロックなしの整合性スナップショットを有効にする (プレビュー)、ソース サーバーを読み取り専用にする、なしなど、ユーザーに提示される複数のデータ整合性オプションがあります。 'なし' を選択すると、データ整合性を補償するための特別な措置は取られません。 読み取りロックによる一貫性のあるスナップショット (GA) を有効にする場合でも、ロックなしの一貫性のあるスナップショットを有効にする場合でも、どちらのオプションでもオンライン移行の実行がサポートされています。 トランザクションの整合性を維持するために、'ロックなしの整合性スナップショットを有効にする' オプションを選択することを強くお勧めします。
ロックなしの整合性スナップショットを有効にする (プレビュー)
このオプションを有効にすると、最初の読み込み後に調整フェーズが発生します。 これは、ターゲットに書き込まれたデータが、バイナリ ログ内の特定の位置からソース サーバーとトランザクション的に整合性があることを保証するためのものです。
この機能では、サーバーの読み取りロックは行われません。 代わりに、各テーブルの異なる binlog 位置を追跡しながら、異なる時点でテーブルを読み込みます。 これは、整合性スナップショットを取得するためにキャッチアップ モードでレプリケーションを実行し、初期読み込みの終了時にテーブルを調整するのに役立ちます。
ロックなしの整合性スナップショットの主な機能:
- 高負荷のサーバーや長時間のトランザクションを実行するサーバーを、読み取りロックなしでサポートする機能。
- ネットワークやサーバーの一時的な切断による障害が発生し、事前作成済みのすべての接続が失われた場合でも、移行を完了できます。
読み取りロック付きの整合性スナップショットを有効にする (GA)
このオプションを有効にすると、サービスは、ポイントインタイム スナップショットを取得するために、読み取りロックを使ってソース サーバー上のすべてのテーブルをフラッシュします。 このフラッシュが行われるのは、個々のデータベースまたはテーブルをロックするよりも、グローバル ロックの方が信頼性が高いからです。 その結果、サーバー内のすべてのデータベースを移行しない場合でも、移行プロセスの設定の一部としてロックされます。 移行サービスは繰り返し可能な読み取りを開始し、現在のテーブルの状態とスナップショットのやり直しログの内容を組み合わせます。 スナップショットは、サーバー全体のロックを数秒間取得し、移行のためにいくつかの接続を作成した後に生成されます。 移行に使われるすべての接続が作成されると、テーブルのロックが解除されます。
繰り返し可能な読み取りを有効にすると、移行時にやり直しログにアクセスできるようになりますが、接続が長期になるため、ソースで必要なストレージが増えます。 複数のテーブル変更を伴う移行を長時間実行すると、やり直しログの履歴が膨大になり、それを再生する必要がある上に、ソース サーバーのコンピューティング要件と負荷が増大する可能性があります。
ソース サーバーを読み取り専用にする
このオプションを選択すると、移行中にソース サーバー上で書き込みおよび削除操作を実行できないようにすることで、ソースの移行時にターゲット データベースのデータの整合性を維持できます。 移行プロセスの一環としてソース サーバーを読み取り専用にすると、その選択は、移行対象として選択されているかどうかに関らず、ソース サーバーのすべてのデータベースに適用されます。
ソース サーバーを読み取り専用にすると、ユーザーはデータを変更できなくなり、データベースを更新操作に使用できなくなります。 ただし、このオプションを有効にしないと、移行時にデータの更新が発生する可能性があります。 その結果、データベースのスナップショットが異なる時点で読み取られるため、移行されたデータに整合性がなくなる可能性があります。
読み取りロック付きの整合性スナップショットを有効にするための前提条件
読み取りロックを有効にした整合性スナップショットを使用して移行を正常に完了するには、次のことを行う必要があります。
読み取りロックが有効なテーブルをフラッシュしようとしているユーザーが、RELOAD または FLUSH アクセス許可を持っていることを確認します。
mysql クライアント ツールを使用し、log_bin がソース サーバーで有効かどうかを判定します。 バイナリ ログは既定では必ずしも有効ではないため、移行開始前に有効かどうかを確認する必要があります。 log_bin がソース上で有効かどうかを確認するには、mysql クライアント ツールを使い、コマンド SHOW VARIABLES LIKE 'log_bin'; を実行します。
Note
最大 4 TB をサポートする Azure Database for MySQL 単一サーバーでは、log_bin は既定で有効になっていません。 ただし、ソース サーバーの読み取りレプリカを昇格してから読み取りレプリカを削除すると、パラメーターが ON に設定されます。
- ソース サービスで binlog_expire_logs_seconds パラメーターを構成し、レプリカ コミットの変更前に binlog ファイルが消去されないようにします。 カットオーバーが成功したら、この値をリセットできます。
ロックなしの整合性スナップショットを有効にするための既知の問題と制限事項
- 削除時/更新時に Cascade 句または Set Null 句を持つ外部キーを含むテーブルはサポートされていません。
- 初期読み込み中に DDL の変更が行われることはありません。
読み取りロック付きの整合性スナップショットを有効にするための既知の問題と制限事項
整合性バックアップに関連付けられた既知の問題と制限は、大きく分けてロックと再試行という 2 つのカテゴリに分類されます。
Note
移行サービスは、すべてのワーカー スレッドに対して START TRANSACTION WITH CONSISTENT SNAPSHOT クエリを実行してサーバー スナップショットを取得します。 ただし、これは InnoDB でのみサポートされています。 詳細については、こちらを参照してください。
Locks
通常、ロックを取得するのは簡単なプロセスであり、数秒から数分で完了します。 ただし、いくつかのシナリオでは、ソース サーバーのロックを取得する試行が失敗することがあります。
実行時間が長いクエリが存在する場合、DMS はテーブルのサブセットをロックし、最後の数個が使用可能になるまで待つ間にタイムアウトする可能性があるため、不要なダウンタイムが発生する可能性があります。 移行を開始する前に、SHOW PROCESSLIST コマンドを実行して、長時間実行されている操作がないかを確認します。
ロックが要求された時点でソース サーバーに多くの書き込み更新が発生している場合、ロックを簡単に取得できず、ロック待ちのタイムアウト後に失敗する可能性があります。 これはテーブルのバッチ処理タスク時に発生し、進行中の場合はロック要求が拒否される可能性があります。 前述のように、要求されるロックはサーバー全体に対する 1 つのグローバル レベルのロックであるため、1 つのテーブルまたはデータベースが処理中であっても、ロック要求は進行中のタスクが終了するまで待つ必要があります。
もう 1 つの制限は、AWS RDS ソース サーバーからの移行に関連しています。 RDS は読み取りロックが有効なフラッシュ テーブルをサポートしていないため、LOCK TABLE クエリは内部で選ばれたテーブルに対して実行されます。 テーブルは個別にロックされるため、ロック プロセスの信頼性が低くなり、ロックの取得に時間がかかる場合があります。
再試行
移行によって一時的な接続の問題が処理されます。通常、この目的のために追加の接続が事前にプロビジョニングされます。 移行設定、特にソース上の並列読み取り操作数を確認し、係数 (通常 1.5 以下) を適用し、事前にできるだけ多くの接続を作成します。 サービスはこのような方法で、ユーザーが操作を並列して実行し続けられるように確保しています。 どの時点でも接続が失われた場合、またはサービスがロックを取得できない場合、サービスはプロビジョニングされた余剰接続を使用して移行を再試行します。 すべての接続を使い果たし、ポイントインタイム同期が失われた場合、移行を最初からやり直す必要があります。 成功した場合も失敗した場合も、すべてのクリーンアップ アクションはこのオフライン移行サービスによって実行されるため、ユーザーが明示的なクリーンアップ アクションを実行する必要はありません。