MySQL からカットオーバーを実行する

このガイドでは、Datastream と Dataflow を使用して、MySQL ソース インスタンスから Spanner データベースへのライブ データベース移行のカットオーバーを実行する方法について説明します。

始める前に

カットオーバーを実行する前に、ライブデータ移行の一環として次のタスクが完了していることを確認します。

  1. スキーマの移行: スキーマを Spanner にデプロイします。詳細については、MySQL からスキーマを移行するをご覧ください。
  2. バックフィル移行: バックフィル移行 Dataflow ジョブを使用して、初期データ移行を完了します。詳細については、バックフィルの移行を実行するをご覧ください。
  3. アクティブな CDC レプリケーション: 継続的な変更データ キャプチャ（CDC）レプリケーションがアクティブで正常であることを確認します。
    • Datastream ストリームは、ソース MySQL データベースから変更イベントをアクティブに読み取り、Cloud Storage バケットに書き込んでいます。
    • Cloud Storage バケット通知は、オブジェクト作成イベントを Pub/Sub トピックにパブリッシュします。
    • ストリーミング Dataflow ジョブ（Cloud_Datastream_to_Spanner）は、Pub/Sub サブスクリプションを消費し、1 秒未満または無視できるレプリケーション ラグで Spanner に変更を書き込みます。詳細については、MySQL データを移行するをご覧ください。
  4. 初期データ検証: データ検証チェックを実行して、ソース MySQL インスタンスと Spanner ターゲット間のデータ整合性を検証します。詳細については、データ移行を検証するをご覧ください。
  5. クリーンなデッドレター キュー（DLQ）の状態: Cloud Storage の転送レプリケーションの重大な DLQ ディレクトリ（gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ など）が完全に空であることを確認します。重大なエラーが存在する場合は、根本的な問題を解決し、カットオーバーを開始する前に retryDLQ バッチジョブを使用して、失敗したすべての変更イベントを再生します。詳細については、CDC DLQ エラーをモニタリングして解決するをご覧ください。
  6. リバース レプリケーションの設定（フォールバックの準備）: 予備のフォールバック パスが必要な場合は、Spanner からソースの MySQL データベースにアクティブなリバース レプリケーション パイプラインを設定します。詳細については、MySQL へのフォールバックを構成するをご覧ください。

必要なロール

カットオーバーを実行する

以降のセクションでは、アプリケーションの書き込みを切り替える前に、書き込みパイプラインをドレインし、すべてのソース変更が Spanner に複製されていることを確認する方法について説明します。

パイプラインの健全性と DLQ の状態を確認する

アプリケーションの書き込みトラフィックを一時停止したり、ダウンタイムを開始したりする前に、転送レプリケーション パイプラインの DLQ に未処理の変更イベントがないことを確認します。

  1. Google Cloud コンソールで、ストリーミング Dataflow パイプラインの [ジョブの詳細] ページに移動します。
  2. [カスタム指標] タブで、Total permanent errors カスタム カウンタを調べます。

  3. このカウンタが 0 より大きい場合は、Cloud Storage の重大な DLQ ディレクトリ（gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ など）を確認し、ディレクトリが空であることを確認します。

アプリケーションの書き込みを一時停止する

  1. アプリケーションのすべてのデータベース書き込みトラフィックを一時停止します。
  2. 移行元の MySQL プライマリ インスタンスでアクティブなトランザクションが完全に commit され、ドレインされるようにします。

Datastream を追跡して一時停止する

  1. Google Cloud コンソールで、ストリームの [ストリームの詳細] ページに移動します。
  2. [モニタリング] タブで、[データの更新速度] グラフ（Cloud Monitoring の指標タイプ: datastream.googleapis.com/stream/freshness）を確認します。指標の値が 0 に減少するまで待ちます。これは、書き込みが一時停止されるまで、Datastream がソース データベースのすべての変更をキャプチャして処理したことを示します。詳細については、ストリームをモニタリングするをご覧ください。

  3. レプリケーション イベントがストリームを通過していないことを確認します。[モニタリング] タブで、[スループット] グラフ（モニタリング指標タイプ: datastream.googleapis.com/stream/event_count）を調べて、イベント率が 0 であることを確認します。

    または、Metrics Explorer を使用してプログラムで確認するには、Monitoring Query Language（MQL）を使用してイベント数をクエリします。

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     STREAM_ID は、ストリームの ID に置き換えます。

    この指標が少なくとも 2 つの連続する集計期間で 0 を報告していることを確認します。

  4. Google Cloud コンソールまたは API を使用して Datastream ストリームを一時停止し、ストリームのステータスが PAUSED に変わるまで待ちます。

転送中の変更データが排出されるのを待つ

  1. Google Cloud コンソールで、ストリームの [ストリームの詳細] ページに移動します。
  2. [モニタリング] タブで、[システム レイテンシ] グラフ（モニタリング指標タイプ: datastream.googleapis.com/stream/system_latencies）を確認します。
  3. 99 パーセンタイル（P99）レイテンシ値をメモし、ストリームを一時停止してから、P99 システム レイテンシの 2 倍に 30 秒を加えた時間以上待ちます。この待機期間により、一時停止前に生成されたすべての変更データファイルが Cloud Storage に安全に書き込まれ、オブジェクト作成イベントが Pub/Sub に公開されます。
  4. ストリーミング Dataflow ジョブが、保留中のすべての変更イベントを処理したことを確認します。 Google Cloud コンソールで、Pub/Sub の [サブスクリプション] ページに移動し、CDC 移行の設定時に作成したサブスクリプションを選択します。
  5. [モニタリング] タブで、[未確認メッセージ数] グラフ（モニタリング指標タイプ: pubsub.googleapis.com/subscription/num_undelivered_messages）を調べて、数が 0 であることを確認します。

レプリケーションが完了したことを確認する

  1. ストリーミング Dataflow パイプラインが、複製されたすべての変更の書き込みを完了したことを確認します。ストリーミング ジョブの [ジョブの詳細] ページで、[カスタム指標] タブを選択し、Replication lag total latency_MAX ユーザー カウンタを調べます。カウンタ値が 0 に達するまで待ちます。

    または、Metrics Explorer で MQL を使用してユーザー カウンタをクエリします。

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     JOB_ID は、Dataflow ジョブの ID に置き換えます。

  2. 移行先の Spanner データベースで書き込みアクティビティが停止したことを確認します。ターゲット データベースの [データベースの詳細] ページで、[モニタリング] タブを選択し、[書き込みスループット] グラフ（モニタリング指標タイプ: spanner.googleapis.com/transaction_stat/total/bytes_written_count）を確認します。書き込みスループットが 2 回連続して 1 分間の集計期間で 0 であることを確認します。

  3. フォワード レプリケーション DLQ の最終チェックを行います。Cloud Storage の重大な DLQ ディレクトリと再試行 DLQ ディレクトリ（gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/、gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/ など）を調べて、空のままであることを確認します。

  4. ストリーミング Dataflow ジョブをドレインします。

    1. Google Cloud コンソールで、ストリーミング ジョブの [ジョブの詳細] ページに移動します。
    2. [ジョブの停止] をクリックし、[ドレイン] を選択して、[ジョブの停止] をクリックします。
    3. ジョブのステータスが Drained に変わるまで待ちます。詳細については、実行中のパイプラインを停止するをご覧ください。

  5. ドレイン後の DLQ 検証を実行する: ジョブのステータスが Drained に変わったら、Cloud Storage の重大な DLQ ディレクトリと再試行 DLQ ディレクトリを最後に 1 回確認します。処理中のデータがドレインされている間に、新しいエラーファイルが表示されていないことを確認します。ファイルが存在する場合は、解決して再生します。詳細については、CDC DLQ エラーのモニタリングと解決をご覧ください。

アプリケーションのカットオーバーを実行する

アプリケーション データベース接続を Spanner に切り替え、ライブの読み取り / 書き込みトラフィックを再開します。

  1. Spanner データベースをターゲットとするように、アプリケーション構成またはデータベース接続文字列を更新します。
  2. アプリケーション サービスを開始し、ライブの読み取り / 書き込みトラフィックが Spanner に対して正常に実行されることを確認します。
  3. 逆レプリケーション パイプラインでエラーが発生していないかモニタリングします。Spanner の書き込みが MySQL にレプリケートされない場合、Dataflow は失敗したレコードを Cloud Storage の DLQ ディレクトリ（gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ など）に保存します。このパスを定期的に確認して、空のままであることを確認します。失敗したレコードが表示された場合は、リバース レプリケーション エラーをモニタリングして解決するをご覧ください。

次のステップ