MySQL へのフォールバックを実行する

このガイドでは、Spanner からソース MySQL インスタンスへのフォールバックと障害復旧のロールバックを行う方法について説明します。

Spanner に切り替えた後に、予期しないパフォーマンスの低下、回復不能なアプリケーション エラー、重大な機能ブロックが発生した場合は、次のセクションの手順を使用して MySQL プライマリ インスタンスにロールバックします。

始める前に

フォールバック手順を開始する前に、次の前提条件を確認してください。

1. アクティブな逆レプリケーション: 逆レプリケーション Dataflow パイプライン（Spanner_to_SourceDb）が実行され、forward_migration フィルタリング モードで Spanner 変更ストリームをアクティブに消費していることを確認します。詳細については、MySQL へのフォールバックを構成するをご覧ください。
2. ソース MySQL の可用性: ソース MySQL データベースがオンラインで、Dataflow からアクセス可能で、書き込み接続を受け入れることができることを確認します。
3. メンテナンスの時間枠: Spanner の書き込みが一時停止され、逆方向のレプリケーションがドレインされる間に、計画されたダウンタイムの時間枠が必要であることを関係者に通知します。

必要なロール

• MySQL へのフォールバックに必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

  • Cloud Spanner データベース ユーザー （roles/spanner.databaseUser）
  • Dataflow 管理者 （roles/dataflow.admin）
  • Datastream 管理者 （roles/datastream.admin）
  • ストレージ管理者 （roles/storage.admin）
  • モニタリング閲覧者 （roles/monitoring.viewer）
  • 閲覧者 （roles/viewer）

Spanner の書き込みを一時停止する

警告: この手順でアプリケーションのダウンタイムが始まります。

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

逆レプリケーションでドレインを許可する

以降のセクションでは、アプリケーションの書き込みを切り替える前に、カットオーバー後に Spanner に書き込まれたすべての変更が MySQL にレプリケートされることを確認する方法について説明します。

レプリケーション ラグをモニタリングする

レプリケーション ラグを追跡して、進行中のすべての変更が MySQL に書き込まれていることを確認します。

1. Google Cloud コンソールで、リバース レプリケーション Dataflow ジョブの [ジョブの詳細] ページに移動します。
2. [カスタム指標] タブで、replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX ユーザー カウンタを確認します。詳細については、MySQL への代替を構成するをご覧ください。
3. カウンタ値が 0 に達するまで待ちます。

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

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
    

次のように置き換えます。 * JOB_ID: 逆レプリケーション Dataflow ジョブの ID。* LOGICAL_SHARD_NAME: ソース データベースに構成されている論理シャード名。

MySQL の書き込みアクティビティを確認する

ソース データベースでリバース レプリケーションの書き込みオペレーションが完了していることを確認します。

1. ソース MySQL プライマリ データベースで、アクティブなクエリとデータベース接続の指標を調べます。
2. リバース レプリケーション パイプラインからの書き込みトラフィックが停止していることを確認します。

DLQ のクリーンな状態を確認する

デッドレター キュー（DLQ）を調べて、リバース レプリケーション中に未処理のエラーが発生していないことを確認します。

1. Google Cloud コンソールで、逆レプリケーション Dataflow ジョブの [ジョブの詳細] ページに移動します。[カスタム指標] タブで、severe_error_count ユーザー カウンタを調べます。

2. Cloud Storage で、重大なリバース レプリケーション DLQ ディレクトリと再試行リバース レプリケーション DLQ ディレクトリの両方を検査します（例: gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/、gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/）。

   gcloud CLI を使用して、重大な DLQ ディレクトリの内容を一覧表示できます。

   gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/
   

   次のように置き換えます。

   • MIGRATION_BUCKET: Cloud Storage バケットの名前。
   • ENV: デプロイ環境の名前（例: prod）。
   • SERVICE: アプリケーションまたはサービスの名前。
   • DB_SCHEMA: データベース スキーマ名。

3. DLQ ディレクトリが完全に空であることを確認します。

4. エラーファイルが存在する場合は、続行する前に、根本的な問題を解決し、失敗したレコードを再生します。詳細については、逆レプリケーション エラーをモニタリングして解決するをご覧ください。

フォワード CDC ストリーミングを再開する

今後 Spanner への前方移行を再開する予定がある場合は、前方 Datastream ストリームを再開します。

1. Google Cloud コンソールで、ストリームの [ストリームの詳細] ページに移動します。
2. [再開] をクリックし、ストリームのステータスが RUNNING に変わるまで待ちます。詳細については、MySQL データを移行するをご覧ください。

または、gcloud CLI を使用してストリームを再開するには、gcloud datastream streams resume コマンドを実行します。

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

次のように置き換えます。

• STREAM_ID: Datastream ストリームの ID。
• LOCATION: ストリームが配置されている Google Cloud リージョン。

書き込みを MySQL に再ルーティングする

注: アプリケーションのダウンタイムはこのステップで終了します。

1. 移行元 MySQL プライマリ データベース インスタンスをターゲットとするように、アプリケーション構成とデータベース接続文字列を更新します。
2. アプリケーション サービスを開始し、MySQL に対するライブ読み取り / 書き込みトラフィックを再開します。
3. アプリケーションの読み取り / 書き込みオペレーションが MySQL データベースに対して正常に実行されることを確認します。

次のステップ

• MySQL からカットオーバーを実行する
• MySQL への代替を構成する
• MySQL から Spanner に移行する