【ITニュース解説】Lessons from a MySQL Migration: What We Learned and How to Do It Better Next Time

データベースの移行は、システムを大きく刷新する重要な作業だが、一見うまくいったように見えても、後から予期せぬ問題が発生することがある。例えば、新しいデータベースのサイズが、古いデータベースとまったく同じデータ量であるにもかかわらず、なぜか異なっていたという経験から、私たちはデータベース移行の真の難しさを痛感した。この「小さな」不一致がきっかけとなり、私たちはデータが完全に等しいことを証明し、関係者が信頼できる記録を残すための、より確実な移行手順、いわゆる「プレイブック」を構築することになった。

この教訓をもとに、次に同じような移行を行う際に、より良い方法で作業を進めるための手順を解説する。

まず、データそのものを移動する前に、データベースの「骨格」となる構造と、データを操作するロジックを正確に把握しておく必要がある。テーブルの構造定義だけではなく、データの整合性を保つためのトリガーや、特定の処理を実行するストアドプロシージャ、イベントといったものも、新しいデータベースに正確に再現されなければならない。これらを事前に抽出しておかないと、データは移行できても、それに付随するビジネスロジックが欠落し、サイレントにシステムが誤作動する原因となるため、大変重要だ。抽出したスキーマ情報やルーチン情報は、バージョン管理システムで管理することで、変更履歴を追跡しやすくなる利点もある。

次に、実際のデータを新しいデータベースに安全かつ予測可能な形で移行する。この際、システムが稼働中の場合は、データベース全体にロックをかけてしまうとアプリケーションが停止してしまうため、ロックをかけずに一貫性のあるデータスナップショットを取得する方法を用いる。具体的には、MySQLの特定のオプションを使うことで、トランザクションを利用して整合性を保ちつつ、メモリを大量に消費せずにデータをストリーミングでダンプする。ダンプされたデータは、新しいデータベースにリストアされる。この段階で、新しいデータベースに古いデータベースと同じテーブルが存在するか、そして特に重要なテーブルの行数が大まかに一致するかをざっと確認しておく。

データが移行された直後は、見た目のサイズが古いデータベースと異なることに気づくかもしれない。これは、一括でデータを挿入した後のInnoDBの特性によるもので、データページが断片化されていたり、インデックスの統計情報が古くなっていることが原因である。この段階で慌ててデータ不一致と判断するのは早計だ。まずは現在のディスク上のフットプリント（占有サイズ）を正確に測定し、次にその原因に対処する必要がある。

このサイズ不一致を解消し、データベースの性能を最適化するために、「ANALYZE TABLE」と「OPTIMIZE TABLE」という二つの重要な操作を行う。ANALYZE TABLEは、テーブルのインデックス統計情報を最新の状態に更新する。この統計情報は、データベースがクエリを実行する際に、どのインデックスを使い、どのような順序でテーブルを結合するかといった「実行計画」を立てる上で非常に重要だ。統計情報が古いと、データベースは最適な計画を立てられず、パフォーマンスが低下する可能性がある。特にMySQL 8からはヒストグラム機能も利用でき、インデックスがないカラムのデータ分布も考慮して、より精度の高い実行計画を立てることが可能になる。

一方、OPTIMIZE TABLEは、InnoDBの場合、実質的にテーブルとそのインデックスを再構築する操作である。これにより、ディスク上のデータが整理され、断片化が解消される。結果として、ファイルサイズが圧縮され、物理的にきれいに並んだデータとインデックスは、より効率的なアクセスを可能にする。これらの操作は、特にデータ量が多いテーブルでは時間がかかり、一時的に負荷が高まる可能性があるため、システムの利用が少ない時間帯を選ぶなど、計画的に実行することが重要である。ANALYZEとOPTIMIZEを実行した後、テーブルのサイズやインデックスのカーディナリティ（データの多様性を示す指標）を再度確認すると、古いデータベースと新しいデータベースの数値がより一致していることに気づくだろう。

サイズが揃っても、データが完全に等しいことを確実にするには、さらに厳密な検証が必要だ。そこで役立つのが「Percona Toolkit」という、データベース管理のための強力なツール群である。中でも「pt-table-checksum」は、テーブル内のデータを小さな塊（チャンク）に分割し、それぞれのチャンクのチェックサム（データのハッシュ値）を計算して比較することで、行レベルでのデータ差異を検出する。このツールを使えば、膨大なデータを持つテーブルでも効率的に比較し、不一致があれば正確に特定できる。もし差異が見つかった場合は、「pt-table-sync」を使って、最小限のSQL文でデータを修正し、同期を取ることも可能だ。Percona Toolkitには他にも、遅いクエリを特定する「pt-query-digest」や、不要なインデックスを見つける「pt-duplicate-key-checker」など、移行前後で役立つ多くのツールが含まれている。

データの一致が証明された後も、目に見えないが重要な「データベースオブジェクト」の確認を怠ってはならない。トリガー、ストアドプロシージャ、ストアドファンクション、外部キー制約、そしてデータベース全体の文字セットや照合順序といった要素は、データの挙動やアプリケーションの動作に深く関わっている。例えば、トリガーが一つ欠落しているだけで、在庫数の自動更新や監査ログの記録といったビジネスロジックがサイレントに破綻する可能性がある。これらが古いデータベースと新しいデータベースで完全に一致しているか、一つ一つ確認していく必要がある。

技術的な検証が完了したら、その結果を非技術系の関係者にも分かりやすく報告することが重要だ。生ログやコマンドの出力だけでは理解が難しいため、行数、インデックス数、データベースサイズ、チェックサムの結果、トリガーやプロシージャの有無、文字セットといった主要な項目について、古いデータベースと新しいデータベースの値を比較し、「合格/不合格」のステータスと、許容範囲内の差異がある場合はその説明を添えたサマリー表を作成する。これにより、関係者は移行の成功度合いを明確に理解し、安心感を得られるだろう。

最後に、移行はデータの移動と検証が終わった時点ではまだ完全ではない。新しいデータベースが本稼働した後も、システムが安定して動作しているか監視を続ける必要がある。特に、ANALYZE TABLEによる統計情報の更新は、クエリの実行計画を変更する可能性があるため、移行後に予期せぬパフォーマンスの低下や遅いクエリが発生していないか、スロークエリログを有効にして注意深く監視することが大切だ。数週間程度の監視期間を設けることで、潜在的な問題を早期に発見し、対処することが可能になる。

これらの経験から、次回のデータベース移行では、以下の点を必ず実行することを学んだ。インデックス統計を修正し、良い実行計画を保証するためにANALYZE TABLE（必要に応じてヒストグラムも）を実行する。データサイズを整え、断片化を解消するために、特に大きなテーブルでOPTIMIZE TABLEを実行する。データの真実性を証明するためにPercona Toolkitのpt-table-checksumを使用し、差異があればpt-table-syncで修正する。トリガー、プロシージャ、外部キー、文字セットといった「見えない」要素も確実に検証する。サイズ差が5%以内などの閾値を設けて、分かりやすい形で結果を報告する。そして、移行後1〜2週間はスロークエリログを監視し、実行計画の回帰を早期に検知する。これらの手順を踏むことで、より安全で信頼性の高いデータベース移行を実現できるだろう。