止めずに移行　メルカリの40TB超・50台MySQLからTiDB Cloudへ

信頼性を重視　メルカリ流「TiDB」移行の8ステップ

　TiDB Cloudへの移行において、いかにダウンタイムを最小限に抑えながら、データの整合性を担保できるのか。メルカリでは、工夫を凝らした移行プロセスを8ステップで実行している。

　まず、移行の事前準備では、「Latency Injection（レイテンシの注入）」が行われた。分散データベースという特性上、MySQLと比較するとユーザーのクエリ送信からシステムが処理結果を返すまで、一定の遅延（レイテンシの増加）が発生してしまう懸念があるからだ。

　そこで、MySQLおよび派生DB用のSQLプロキシである「ProxySQL」をマイクロサービスとMySQLの間に配置し、「＋10ミリ秒／＋20ミリ秒／＋40ミリ秒」と段階的にレイテンシを付与することで、APIレイテンシやエラー、モバイルアプリのレスポンス体験といった観点から影響を評価している。問題が確認されたときには、アプリケーションの修正を実施した。

　また、TiDBへの同期用レプリカ（Relayサーバー）と、TiDBからMySQLへ切り戻す場合のマスタとなるレプリカ（Fallbackサーバー）の2台を用意。PingCAPが提供するダンプツール「Dumpling」を用い、RelayサーバーからTiDB Cloudへ初期データの同期を行い、実行結果に含まれるGTID（静止点）をメモする。その後、MySQL互換データベースからTiDBへのデータ複製ツールである「Data Migration（DM）」を用い、初期同期時にメモしたGTIDを参照してRelayサーバーからTiDBへ差分データ同期を実施した。

　続いて、Fallbackサーバーの付け替えとレプリケーションの停止を実施。Relayサーバー、TiDB、Fallbackサーバーの状態をそろえるため、レプリケーション経路をマスタからRelayサーバーを経由してFallbackサーバーへと変更し、その後マスタからRelayサーバーへのレプリケーションを停止。この時点でRelayサーバー、TiDB、Fallbackサーバーはすべて同じ状態となる。

　さらに、TiDBから別のデータベースへ差分データを同期する「TiCDC」を作成し、TiDBからFallbackサーバーにデータを同期する経路を確立。これによりフォールバック時、MySQLへのデータ同期が可能となった。そして、データの信頼性を確保するため、MySQLプロトコルに対応したDB間の差分比較ツール「sync-diff-inspector」を実行し、RelayサーバーのデータとTiDBを経由したFallbackサーバーのデータを比較することで、データの整合性が取れていることを確認する。整合性を確認した後、マスタからRelayサーバーへのレプリケーションを再開した。

　加えて、切り替え前の重要な評価として、「クエリリプレイ」を実施。メルカリではTiDBのクエリ負荷やリソース使用量を確認するため、eBPFベースのライブラリを用いた軽量なパケット処理を実現できる独自のクエリリプレイツールを開発している。リプレイ対象のクエリは、参照系であるSELECTクエリのみに絞り、本番環境のアクセスパターンを再現したTiDB環境で負荷を評価した。

　その後、いよいよ本番環境への切り替えを行う。ダウンタイムを最小限に抑えるため、メルカリでは以降の手順を自動化するスクリプトを作成。まずはProxySQLを配置し、DNSで宛先をProxySQLに変更することで、アプリケーションから透過的にTiDBへと切り替える準備をした上で、READトラフィックをTiDBへ切り替えた。

　ここからダウンタイムが発生する作業となり、マスタを読み取り専用モードに変更。DMがオンメモリに持っている同期状態、たとえばGTIDをディスク（テーブル）に書き込ませるため、マスタに「`ALTER TABLE t COMMENT ‘trigger’`」のような空のDDLを発行する。

　その後、すべてのトランザクションがTiDBで実行されているかを確認するため、2つの方法で厳格な整合性チェックを実施した。一つはマスタのGTIDとFallbackのDMメタデータベースに保存されたGTIDの値を比較する方法。もう一つはTiCDCの「`checkpointTS`」の値とマスタが読み取り専用になった直後のタイムスタンプを比較する方法だ。

　整合性を確認できれば、ProxySQLの宛先をMySQLからTiDBに変更し、WRITEトラフィックもTiDBへ向ける。最後に、元のMySQLとFallbackサーバー間でGTIDが異なっているためリセットし、レプリカ群をFallbackサーバーに付け替えることで切り戻し経路を確保し、切り替えを完了した。

　こうした一連のメルカリ流のTiDB移行の特徴は、Latency Injectionや独自ツールを使ったクエリリプレイによる評価、ProxySQLを使った透過的な切り替え、そしてGTIDやCheckpointTSによる厳格な整合性チェックにあると小山氏は説明する。