スキーマ変更のオンライン化(online DDL)の内部

なぜ ALTER はテーブルを止めるのか

ALTER TABLE でカラムを足したり索引を張ったりする操作は、素朴に実装するとテーブル全体を作り直すことに等しくなります。新しい行レイアウトの一時テーブルへ全行をコピーし、索引を構築し、入れ替える――この間、元テーブルへの書き込みを許すと整合が崩れるため、伝統的な実装はテーブルロックを取り、書き込み（しばしば読み取りも）をブロックします。数億行のテーブルでは、このコピーが数分から数時間に及び、その間サービスが止まります。

MySQL/InnoDB にはネイティブの online DDL（ALGORITHM=INPLACE/INSTANT）もあり、メタデータだけ書き換える INSTANT 操作や、DML を許しながら索引を構築する INPLACE 操作で多くのケースを無停止化できます。しかしネイティブ online DDL にも制約があります。操作によっては結局テーブル再構築が必要で、その間 WAL（先行書き込みログ） と undo が膨らみ、長時間トランザクションがレプリカ遅延を生み、途中で中断もできません。

そこで生まれたのが、DBMS の外側で同じ効果を作り出す外部 online DDL ツールです。代表が Percona の pt-online-schema-change（pt-osc） と GitHub の gh-ost で、両者とも次の四段構えで動きます。

四段構えの全体像

肝は「コピー中も元テーブルは生きている」点です。バックフィルには時間がかかるので、その間に来る新しい変更を捕捉して影テーブルへ転写し続けなければ、コピー完了時点で両者がずれてしまいます。この変更捕捉の実装方式こそが、pt-osc と gh-ost を分ける最大の分岐点です。

pt-osc: トリガーで同期捕捉する

pt-osc は元テーブルに AFTER INSERT / AFTER UPDATE / AFTER DELETE のトリガーを仕掛けます。アプリが元テーブルへ書き込むと、その同じトランザクション内でトリガーが発火し、対応する変更を影テーブルへ即座に反映します。捕捉が同期的（書き込みと同一トランザクション）なので、原理的に取りこぼしがありません。

-- 概念図: pt-osc が張るトリガー（簡略）
CREATE TRIGGER pt_osc_ins AFTER INSERT ON tbl
  FOR EACH ROW
  REPLACE INTO _tbl_ghost (id, col_a, col_new) VALUES (NEW.id, NEW.col_a, ...);
-- UPDATE/DELETE 用も同様に張る

この方式は実装が素直な反面、いくつかの代償を伴います。

pt-osc は既存行のコピーをチャンク（主キー範囲で区切った小さなバッチ）に分け、各チャンクを INSERT ... SELECT で影テーブルへ流します。トリガーが同時進行の変更を、チャンクコピーが過去の行を担当し、両者で全データをカバーします。重複は影テーブル側の REPLACE/INSERT IGNORE による冪等適用で吸収します。

gh-ost: binlog で非同期捕捉する

gh-ost の発想は「元テーブルにいっさいトリガーを張らない」ことです。代わりに、自身をレプリカに見せかけて MySQL の binlog（行ベース、ROW フォーマット）を購読します。元テーブルへの変更はコミット後に binlog へ流れるので、gh-ost はそれを読み、対応する変更を影テーブルへ非同期に適用します（この binlog ベースの変更ストリームは 論理レプリケーションと CDC と同じ原理です）。

トリガーを外したことの利点は大きく、本番の書き込み経路にコードを差し込まないため、書き込みレイテンシを増やさず、負荷が上がれば binlog 適用をスロットリング（一時停止）できます。さらに gh-ost は binlog の読み取り元をレプリカに向けることができ、プライマリのバイナリログ読み取り負荷を逃がせます（ただしバックフィルと binlog 適用の書き込み先、すなわち影テーブルはプライマリ上にあり、最後のリネームもそこで行われます）。代償は、binlog 適用が非同期ゆえに影テーブルが元テーブルから常にわずかに遅れること、そして binlog（ROW フォーマット）が有効であることが前提になる点です。

バックフィルの負荷制御

四段のうち最も時間がかかるのがバックフィルです。数億行を一気にコピーすればロックとレプリカ遅延を引き起こすので、両ツールともチャンク化と動的スロットリングで負荷を平準化します。

チャンクは B+Tree インデックス 上の主キー範囲（例 id BETWEEN 1000 AND 2000）で区切り、範囲スキャンで効率よく読みます。各チャンク間にはレプリカ遅延や負荷指標を見て待機を挟みます。gh-ost は**レプリカの遅延（seconds_behind）**やカスタムしきい値を監視し、超えたら自動で適用を止め、回復したら再開します。これにより「レプリケーション を遅延させない範囲で、空いた I/O を使ってじわじわ移す」制御が成立します。

バックフィルのループ（概念）
  for 主キー範囲チャンク in テーブル:
      if レプリカ遅延 > しきい値 or 負荷高い:
          待機（スロットリング）
      影テーブルへ INSERT ... SELECT（冪等）
      進捗を記録

カットオーバー: 唯一の短いブロッキング点

全行のバックフィルが終わり、変更捕捉が追いついて影テーブルと元テーブルがほぼ一致したら、最後のカットオーバー（切り替え）を行います。ここだけは原子的なリネームが必要で、online DDL 全体で唯一の短いブロッキング点になります。

理想は、元テーブルと影テーブルを RENAME TABLE tbl TO _tbl_old, _tbl_ghost TO tbl; のように一回の原子的リネームで入れ替えることです。MySQL の RENAME TABLE は複数テーブルをアトミックに入れ替えられるため、その瞬間にテーブル名 tbl が指す実体だけが切り替わり、外から見える不整合の窓がありません。

適用できる前提条件

外部 online DDL は万能ではありません。次の前提が崩れると安全に動きません。

とくに外部キーは厄介です。元テーブルをリネームで退避すると、それを参照する子テーブルの外部キーが古いテーブルを指し続けたり、新テーブルへ張り替える必要が生じたりします。どちらのツールも外部キーは特別なオプション扱いで、既定では安全側に倒して拒否することが多く、設計段階での確認が不可欠です。

まとめ

巨大テーブルへの ALTER は、素朴には全行コピーとテーブルロックを伴い長時間サービスを止めます。外部 online DDL ツール（pt-osc / gh-ost）は、新スキーマの影テーブルを作り、コピー中の更新を捕捉し、既存行をチャンク単位でバックフィルし、最後に原子的リネームでカットオーバーするという四段構えで、停止時間をリネームの一瞬まで圧縮します。両者の本質的な違いは捕捉方式にあり、pt-osc はトリガーで同期捕捉する代わりに本番書き込みへ負荷を乗せ、gh-ost は binlog を読んで非同期捕捉することで書き込み経路を無負荷に保ちスロットリングを効かせます。どちらも一意主キーの存在を前提とし、外部キーや既存トリガーが安全性の境界を決めます。原子的なカットオーバーの一点を除けば、巨大テーブルのスキーマ進化を実質無停止で行える――それがオンライン化の正体です。