データベース移行のウラガワ − 円滑なリリースのために取り組んだLT に参加しました。オンライン参加。簡単に所感をまとめます。
所感
やはり、まずはサービス停止が必要かどうかを最初に検討するのが重要そう。あとは、移行前後のデータ不整合リスクをいかに排除するか。
移行作業を2段階に分けたり、書き込みだけ止めて読み込みは生かすことで、サービスの全停止を避ける工夫をしてたのはなるほどでした。
DB移行に限った話ではないけど、他社事例をそのまま参考にするとかは基本的にはできなくて、自社のシステムや業務を正確に把握して自分たちにとって最適な移行計画を立てられるかが重要だと思いました。どういう事業をやっているか次第なところもあるし。
以下、メモから抜粋。(資料公開されたら追記する。あと、最後の方が聴けなかったので録画が公開されたら観る。)
データベースをMySQL8.0へ移行を実行する上で考えてたこと
- 移行前後の仕様変更
- SQL構文
- 組み込み関数
- パフォーマンス
- サービス停止
- 許容されるダウンタイム
- 未コミットのデータがあるとバージョンアップに時間がかかる
- バージョンアップ前にバッチ処理を止める
- 旧新バージョンで実行クエリを記録/再生
データベースの移行方式を検討した話
- 基幹DBリプレイス
- SQL Server
- フロント
- バックエンド
- レポート
- バッチ
- readonly
- dms
- サービス停止有無
- オンライン移行
- 接続切り替えが瞬時にできるか
- データロスト/不整合がないか
- ダブルライト
- アクセス箇所が膨大で断念
- サービス停止時間
- 新旧でデータを一致させる時間 (データ同期)
- export/import
- 時間がかかる
- バックアップ/リストア
- リストア後にレプリケーション再作成が必要
- レプリケーションによるリアルタイム同期
- 旧レプリケーションもあるのでシステム負荷懸念
- 数日前からフルリストア開始
- トランザクションログを細かく適用して差分を埋める
- 2段階リリース
- 2グループずつリプレイス
- サービス停止時間短縮
Aurora MySQL v1からv3へ一段飛ばしのバージョンアップをした話
- サービス停止
- データ不整合リスクを避ける
- 暗黙のソート順が不定に
- DMS レプリケーション
- MySQL Connector/J
- DBの使い方次第でハマるポイントは変わる
- 暗黙のソート順
- デフォルト Collation
- TempTable エンジン
- 接続ライブラリ
- レプリケーショントラブル
- 性能/サイジング
- 他社事例は参考程度に
サービスへの影響を抑えてデータベースの移行を実施したはなし
- Aurora → Cloud SQL
- Cloud SQL
- BigQuery 連携
- マルチリージョン
- AWS VPC → VPN → Google CLoud VPC
- データ整合性
- Cloud SQL にレプリカ構築 (reader)
- 切り替え中は書き込み停止
- 読み込みはそのまま
- 全サービス切り替え完了するまで書き込みさせない
- 読み取り/書き込みそれぞれにドメインを割り当てる
- DNSで書き換え
- コネクションプールの生存期間に注意
