オンラインスキーママイグレーション稼働したままスキーマ変更を当てる。すべてのエンジンで。

オンラインスキーママイグレーションガイド

順番に読む。

• 01

  MySQL Online DDL から始める

  INSTANT、INPLACE、COPY — それぞれが何を書き換え、何をロックし、MySQL がどんなときにフォールバックするか。

• 02

  COPY のコストが高すぎるなら gh-ost

  10 億行のテーブルでは MySQL の COPY フォールバックは数時間かかり、レプリカも失速する。gh-ost は binlog を読み、シャドーテーブルを構築し、入れ替える。

• 03

  Postgres は仕組みが違う

  ロックモデルが違えばプレイブックも変わる。順序を正しく組み立てれば、ほとんどの ALTER は補助無しでオンラインに走る — もし必要になっても Postgres 版の gh-ost は存在しない。

オンラインスキーママイグレーションに関する質問

よくある質問。

オンラインスキーママイグレーションとは？

スキーマ変更 — カラム追加、新しい索引、型の拡張 — を、データベースが読み書きを処理し続けたままで適用すること。落とし穴は、たいていのエンジンが ALTER のどこかで何かをロックすることです。「オンライン」は「ロックが一切ない」ではなく、「ロックが短く許容できる」を意味します。

MySQL の Online DDL と gh-ost / pt-online-schema-change はどう使い分けるか？

まず Online DDL から始めましょう — 無料で、エンジンに同梱され、INSTANT や INPLACE で大半のケースをカバーします。問題は COPY です。MySQL は他のアルゴリズムでインプレースにできない操作になると静かに COPY に落ち、大きなテーブルでは数時間の再構築とレプリカ遅延を生みます。そこで gh-ost や pt-online-schema-change の出番です。まず gh-ost の制限の記事を読んでください — どちらも外部キー、生成カラム、特定のレプリケーション構成で角があります。

Postgres には gh-ost のような外部ツールが必要か？

通常は不要 — ただしこれはツール側のギャップで、エンジンが優れているからではありません。Postgres には gh-ost や pt-online-schema-change と同等の汎用ツールは成熟していません。pg_repack や pg_squeeze はテーブル再構成をカバーしますが、書き込みを続けたまま任意の ALTER を再生するわけではありません。実際に成り立つのは、ほとんどの Postgres の ALTER が順序を正しく組み立てればネイティブにオンラインで進むからです — NULL 許容のカラム追加、`CREATE INDEX CONCURRENTLY`、互換ステップへの分割など。ネイティブにオンラインにできない変更のフォールバックは、Postgres 版 gh-ost ではなく Blue-Green デプロイです。