AWS Database Migration Service（DMS）を使ったデータ移行

既存で利用していた MySQL 5.7（Community 版および Aurora MySQL 版）がサポート切れとなり、コスト削減と運用負荷の軽減を目的に、独立して稼働していた MySQL Community の DB を Aurora MySQL クラスターに統合することにした。

当初は mysqldump での移行を検討していたが、mysqldump では移行中の書き込みを反映できず整合性が担保できないため、長いダウンタイムが必要になり、サービス影響が大きくなる懸念があった。

そこで、いかにダウンタイムを最小限に抑えながらデータ移行を行える方法を探していた。

ツール導入前の課題

・mysqldump はスナップショットのみで、更新分を反映できない。

・そのため DB 切り替え時に長時間のダウンタイムが必要となり、ユーザー影響を抑えることが難しい。

どのような状態を目指していたか

・切り替え時のダウンタイムを最小限に抑えること。

・移行中に発生した書き込みについても整合性を維持できる状態。

・移行進捗を可視化できること。

特になし。

・レプリケーション機能が使える。

・データ移行の状態がコンソール上で確認できる。

・移行用インフラを自前で準備する必要がなく、AWS のマネージドサービスとして利用できる点も評価された。

改善したかった課題はどれくらい解決されたか

・CDC（Change Data Capture：ソース DB の変更を継続的に同期する機能）を利用するには binlog_format=ROW の設定が必要で、Aurora MySQL 環境ではクラスター再起動を伴うため断念した。

・そのため継続レプリケーションはできなかったが、Full Load Onlyでも移行中の変更が反映され、最終的な切り替え時のダウンタイムは最小限に抑えられ、サービス影響を軽減できた。

どのような成果が得られたか

・dumpでは得られなかった「移行状況をGUIで確認できる」という安心感を得られた。

・移行タスクを自動化できたことで、手動 dump/import よりもヒューマンエラーのリスクを減らせた。

・一方で、セカンダリインデックスが引き継がれないことが分かり、テーブル定義を事前に準備する必要があると学べた。

・Aurora MySQLではCDCを使うために binlog_format=ROW が必要である、という制約面の知見も得られた。

・DMS を使ってデータ移行をする際に、移行先の DB にテーブル定義も作ってくれるが、その際にインデックスの情報は引き継がれないので、事前にテーブル定義を移行先のDBに準備しておく必要がある。

・バイナリログのフォーマットがROWでないと継続的なレプリケーションは行えないので、事前に確認しておく必要がある。