AWS Database Migration Service（以下DMS）はAWSのなんかいい感じにデータベースのデータを移行できるサービス。
仕事でもプライベートでもデータベースを扱っていると、あるデータベースを別の場所に複製したい場面がある。RDS for MySQLから、別のRDS for MySQLに複製したい場面もきっとあるだろう。
DMSを使うと、これを極力手抜きで行えるのではないか？ そういう期待があった。
Homogeneous database migrations
You create a migration task with connections to the source and target databases, then start the migration with the click of a button. AWS Database Migration Service takes care of the rest.
ユースケースにも「同種のデータベース間で余裕で移行できる」ようなことが書いてある気がする。
手抜きを試したので軽くまとめておく。
- スキーマも含めて移行（Target table preparation mode: Drop tables on target）を試す
- ダメだったのでデータだけ移行（Target table preparation mode: Truncate）を試す
- Target table preparation mode: Truncate での制限事項
- AWS DMSでRDS MySQLのデータベース複製を手抜きできるか？
- そもそも論として手抜きしないなら
スキーマも含めて移行（Target table preparation mode: Drop tables on target）を試す
移行の形態にはいくつかあるのだけれど、今回はある瞬間のDBの状態を複製したいので既存のデータの移行だけを行う。
移行先の前処理としてDROP TABLEを選べば、ゴミを掃除した後CREATE TABLEしてくれそうだ。
実際CREATE TABLEした上でデータを複製してくれた。だがこれは全く使い物にならないので止めた方がいい。
「Drop tables on target」した後に生成されるテーブルには、あらゆる規約やINDEXがない。
これではRDBMSとして使い物にならない。
ダメだったのでデータだけ移行（Target table preparation mode: Truncate）を試す
「Truncate」を試す。
事前に移行元、移行先の間でDBスキーマをそろえておく必要はあるが、こちらは機能した。
AWS DMSでRDS for MySQLのデータベース複製をするならこのアプローチが良さそうだ。
（移行を繰り返さないなら「Do nothing」でも同様になるだろう）
Target table preparation mode: Truncate での制限事項
どうも見た目上と実際でカラム構成が異なるテーブルの移行は失敗する模様。
具体的にはGENERATED Columnで動的にカラムを生やしているテーブルの移行には失敗した。
たまたま移行しなくても大きな問題はないテーブルだったので、移行対象外として処理した。
AWS DMSでRDS MySQLのデータベース複製を手抜きできるか？
Target table preparation mode: Truncate で処理できるならまぁまぁ手抜きできたなと思う。
マネージドな実行環境と、進捗管理はなかなか良い。
Target table preparation mode: Drop tables on target で移行先の下準備なしに処理できれば最高に手抜きできたんだけれどなぁ！ 残念！！
そもそも論として手抜きしないなら
Using a MySQL-compatible database as a source for AWS DMS - AWS Database Migration Service
MySQL to MySQL なら mysqldump 使っとけって書いてある。
手堅くいくならその指示に従うのが良いのだろう。
インスタンスが変わってよいならスナップショット取得とその復元も確実だ。
とは言え、手抜きの手段として制限を分かったうえでDMSを使える場面はあるかと思う。
なにしろ、RDS for MySQLでmysqldumpを使うのは面倒くさいのだ。
VPCに接続できる実行環境を整備するのもひと手間ある。
いい感じに手抜きさせてくれ！
