この章について
アプリケーション修正と並行して実施した、移行作業計画と作業手順書作成、リハーサルを振り返ります。
移行に必要な作業をリストアップ（2022/6）
すでにまとめた情報があったのでその中からピックアップした程度ですが、移行作業（DB のバージョンアップ当日とその前後に行う作業）をリストアップして、大体の流れを決めました。
- 事前に移行先の v3 DB を準備
- v1 スナップショットを v2 で復元、v2 スナップショットを v3 で復元
- 時期はできるだけ移行直前が良い
- レプリケーション差異発生のリスクとコストの観点で
- ただし、準備が間に合わなくならないタイミングで
- 金曜夜から DB のバージョンアップをするなら、その週の火〜水曜日で準備する
- 既存の v1 DB → v3 DB のレプリケーションを設定
- v1 → v3 の binlog レプリケーションは非推奨なので、当初は DMS（CDC）を想定していた
- 結果的に v1 → v2 → v3 の binlog にした（後の章で説明）
- v1 → v3 の binlog レプリケーションは非推奨なので、当初は DMS（CDC）を想定していた
- データ整合確認に
mysqldump・SELECT *スクリプトを使用- DMS で比較する手もあったが、当日の作業時間が限られるため慣れた手法を使う
- その他、過去の AWS アカウント移行作業時の手順書を見て必要作業をピックアップ
- sorry 停止時・再開時の作業
- v1 → v3 DB 切り替えは DB クラスタ名・インスタンス名を変更 or Route 53 Private Zone でのレコード書き換え
- 今回は後者を選択
- 事後作業
- 監視対象の切り替え
- 旧クラスタ停止・スナップショット化
必要作業について準備・テスト（2022/7 〜 8）
データ整合確認用mysqldump・SELECT *スクリプト作成〜テスト実行
今回は深夜にサービスを停止して移行する想定なので特に、サービス停止時間が何時間必要かを事前に導出しておく必要があります。
サービス停止時間は、大まかに
- sorry 遷移および解除作業
- バッチ処理停止・再開
- データ整合確認
- DB 切り替え（v1 → v3）
- サービス再開前の動作確認
の所要時間から導出可能ですが、それなりのデータ容量がある場合はこれらのうちデータ整合確認が最も大きな要素となります。
そのため、まずはmysqldump・SELECT *スクリプトを作成しました。
- MySQL 8.0 のクライアントパッケージにバージョンアップすると MySQL 5.6 のダンプが正常に取れない
- MySQL 5.6 のダンプと MySQL 8.0 のダンプでは一部出力が異なる
という問題に直面しつつ、スクリプトを作成して本番相当のデータ量で所要時間を計測しました。
また、これらの作業に関連して、以下の Zenn 記事を書きました。
DMS（CDC）の試用（2 回目）とテスト
従来の移行では binlog レプリケーションしか使ったことがなかったので、DMS（CDC）レプリケーションを本格的に試しました。
文字コードの問題に直面しつつ、テスト環境のデータでは一旦上手く行った…はずだったのですが、後ほど本番相当のデータで試したときに問題が発生しました（後述）。
こちらの作業についても、Zenn 記事を書きました。
- 移行に必要な作業をリストアップ
- 先にまとめた情報をもとに
- DMS（CDC）をテスト環境で試用
- データ整合確認用の
mysqldumpスクリプト作成 - プレリハーサルを行い、その結果を受けて移行手順書を仮作成
リハーサルと手順書作成（2022/7 〜 9）
プレリハーサル・仮手順書作成
まずは本番データではなくテスト環境のデータを使って、想定した流れに沿って作業を進め、それをもとに仮手順書を作成しました。
ここまでは順調に進みました。
リハーサル 1 回目
仮手順書をもとに、SRE チームメンバーだけ集めてリハーサル 1 回目を実施しました。
ここでは、
- 作業手順に抜け・漏れ・誤りがないか？
- 想定した作業時間は妥当か？
を確認しました。
プレリハーサルどおり順調に進むか…と思いきや、いきなりデータ不整合が発覚。
調査の結果、特定のテーブルでタイムスタンプ値に異常が生じていることがわかりました。
一部手順変更および手順書修正
非推奨ではあるものの binlog レプリケーションを使う方法に切り替えて再試行することに。
v1 → v2 → v3 の多段レプリケーションを構築して本番相当のデータを使って確認したところ特にデータ不整合などの問題は生じなかったため、DMS（CDC）を使わず binlog 多段レプリケーションを使う形に手順を変更しました。
そして、それに合わせて手順書も修正しました。
リハーサル 2 回目
今度は SRE チームメンバー以外も含めて、実際の作業メンバーでリハーサル 2 回目を実施しました。
手順書の修正ミスが数点見つかりましたが、大きな問題もなく無事終了しました。