TiDBからAurora MySQLへ移行するときの互換性と注意点
どちらもMySQLのプロトコルを話しますが、内部構造は別物です。「MySQL互換だから移せる」という前提のまま進めると、移行後に性能とロックの問題が表面化します。
このページは、分散データベースであるTiDBから、MySQL互換のクラウドデータベースであるAmazon Aurora MySQLへの移行を検討している方に向けたものです。GIIPは約3TB規模のTiDB環境をAurora MySQLへ移行した経験があります。
互換性をどこまで信じていいか分からない
MySQL互換と書かれていても、どのレベルまで同じ挙動をするのかが判断できません。
分散前提の設計をどう扱うか決まらない
TiDB向けに設計したテーブル分割やアクセスパターンを、単一クラスタでもそのまま使っていいのかが分かりません。
移行後に遅くなるのが怖い
実行計画が変わることで、これまで問題にならなかったクエリが重くなる可能性を評価できません。
スケールの考え方が違う
TiDBはデータを複数ノードに分散し、Aurora MySQLはストレージ層を共有する単一クラスタです。同じSQLでもスループット特性の前提が変わります。
実行計画は移行先で作り直される
オプティマイザが異なるため、同じクエリが同じ計画になるとは限りません。インデックス設計の見直しが必要になる場合があります。
トランザクションとロックの前提が異なる
分離レベルとロック挙動の違いは、同時実行が多い処理ほど影響が出ます。
互換性を「動くかどうか」ではなく「同じ結果と同じ性能特性になるか」で確認します。
スキーマとデータ型の突合
主キー、自動採番、インデックス設計、データ型、文字コード、照合順序の差異を洗い出します。
クエリとバッチの評価
実行計画が変わることで重くなるクエリを事前に特定し、大量更新・削除バッチの負荷特性を確認します。
移行後のAurora運用
Aurora固有のメトリクスを含む監視項目を再定義し、移行後の性能監視を継続します。
ご自身で先に確認できること
- データ容量と、テーブルごとの偏り
- 同時接続数のピークと、コネクションプールの設定
- 大量更新・大量削除を行うバッチの有無
- 長時間トランザクションの有無
- TiDB固有の機能を使っている箇所
- 現在スロークエリとして把握しているもの
- 業務上、何時間まで停止できるか
実績で示せること
移行に要した時間、停止時間、移行後の性能変化、コスト変化は測定値として確認されていないため記載していません。
よくあるご質問
MySQL互換なら、そのまま接続先を変えるだけで移行できますか。
プロトコル互換であることと、同じ挙動をすることは別です。スキーマ、データ型、実行計画、トランザクション、バッチ処理、運用手順のそれぞれを確認する必要があります。
移行すると性能は上がりますか。
上がるとは記載していません。性能はワークロードとクエリの性質に依存します。GIIPが経験した事例でも、移行後の性能変化は測定値として確認されていないため公開していません。
3TB規模でも移行できますか。
GIIPは約3TB規模のTiDB環境をAmazon Aurora MySQLへ移行した経験があります。より大きな規模については現行構成を確認したうえでお答えします。
移行後のAurora運用も任せられますか。
可能です。GIIPは現在も複数のAmazon Aurora MySQLを含むクラウドデータベースを継続的に監視・運用しています。
分散データベースからの移行可否を確認する
データ規模、バッチ処理の有無、停止許容範囲をお知らせください。検証すべき論点を整理してご回答します。