大規模な MySQL のスキーマ変更を無停止で実行する

オンラインスキーマ移行は、データベースが読み書きを提供し続けたまま、スキーマ変更（カラム追加、新しいインデックス、型の拡張）を実行します。ただし、ほとんどのエンジンは ALTER の一部で何かをロックします。「オンライン」とは、ロックがまったく発生しないという意味ではなく、ロックが短く許容範囲に収まるという意味です。

まず Online DDL から始めます。無料でエンジンに組み込まれており、INSTANT または INPLACE でほとんどのケースをカバーします。問題は COPY です。他のアルゴリズムがインプレースで実行できない操作で、MySQL は黙って COPY にフォールバックし、大きなテーブルでは数時間の再構築とレプリカ遅延を招きます。そこで gh-ost や pt-online-schema-change の出番です。Bytebase は、テーブルサイズとポリシーに基づいてこの選択を代わりに行います。

Bytebase は gh-ost をエンドツーエンドで動かします。binlog からシャドウテーブルを構築し、レプリカ遅延に応じてスロットリングし、アトミックなカットオーバーを実行します。これらはすべて、SQL レビューと承認の背後で、変更ワークフローの中で行われます。本番マシンで設定・スロットリング・見守りをする別の gh-ost ランナーは不要です。

Bytebase のオンラインマイグレーションのツールは gh-ost であり、これは MySQL 固有です。Postgres には成熟した汎用の同等品がありません。実際には、操作を正しく順序付ければ（NULL 許容カラムの追加、CONCURRENTLY でのインデックス作成、変換を互換性のあるステップに分割する、など）、ほとんどの Postgres の ALTER はネイティブにオンラインで実行でき、Bytebase の SQL レビューがロックを伴うものを検出します。ネイティブにオンライン化できない変更のフォールバックは、Postgres 側の gh-ost ではなくブルーグリーンデプロイです。gh-ost のような駆動ツールがなくても、Bytebase はすべての Postgres 変更を統制します（レビュー、シーケンス、ロールバック、監査）。

はい。マイグレーションは GitHub、GitLab、Bitbucket に組み込まれ、プルリクエストで自動 SQL レビューを通過し、アプリケーションと同じパイプラインでデプロイされます。別途マイグレーションランナーを構築・保守する必要はありません。

はい。Bytebase は 1 つの Docker イメージとして自社インフラで実行され、データとデータベース認証情報がネットワークの外に出ることはありません。オープンソースです。