コラム / データベース / 運用 /
DBの本番マイグレーションで死なない ─ MySQL/PostgreSQL のオンライン ALTER と中断復旧の実務
メンテ枠4時間が9時間に伸びる前に知っておく、本番マイグレーション選択肢の全体図
📖 約10分 / 公開日: 2026/05/21
## 「メンテ時間に一気に流す」が成立しなくなる瞬間
本番DBのスキーマ変更が一夜にして恐ろしくなるラインがあります。経験則として、単一テーブルが10GBを超えた、もしくは行数が5,000万を超えた瞬間です。それまで普通に通っていた `ALTER TABLE ADD COLUMN` が、ある日突然「3時間経っても終わらない、ロックでアプリが落ちる、メンテ枠を延長できない」という地獄を呼びます。
相談を受けた事例でいちばん深刻だったのは、テーブル4億行・容量85GBの注文履歴テーブルに NOT NULL カラムを追加しようとして、メンテ枠の4時間で終わらず、ロールバックも効かず、結局9時間のサービス停止になった案件です。EC事業者で、9時間止まれば被害額は数千万円規模。経営会議に呼び出されてから相談が来ました。
この手の事故は、ツール選定と運用設計を最初の段階で決めておけば、ほぼ100%回避できます。
## MySQL の選択肢 ─ pt-online-schema-change か gh-ost か、それともネイティブ Online DDL か
MySQL 5.6 以降、ネイティブの Online DDL は「ALGORITHM=INPLACE, LOCK=NONE」をサポートしていて、カラム追加・インデックス追加の多くはオンラインで通ります。MySQL 8.0 ではさらに INSTANT ADD COLUMN が入り、テーブル末尾へのカラム追加は瞬時に終わる ── これは本当に瞬時で、4億行のテーブルでも数ミリ秒です。
問題は、INSTANT で通らない変更です。カラム型の変更、NOT NULL 制約の追加、PRIMARY KEY の変更、カラムの順序変更、文字コード変更 ── このあたりは INPLACE でもテーブルを書き換える必要があり、容量と同程度のディスクと、変更中の書き込み負荷を全部吸収するレプリケーションラグが発生します。
ここで pt-online-schema-change（Percona Toolkit）か gh-ost（GitHub 製）の出番です。両者ともシャドウテーブルを作って差分をバイナリログから流し込み、最後に RENAME で切り替える方式ですが、設計思想がはっきり違います。
pt-online-schema-change はトリガーベース。元のテーブルに INSERT/UPDATE/DELETE のトリガーを張って、シャドウテーブルへ自動同期します。シンプルですが、書き込み負荷の高いテーブルだと、トリガーがアプリのレイテンシをまるごと押し上げる事故が起きます。p99レイテンシが80ms→340msに跳ねた事例を、過去2件確認しています。
gh-ost はトリガーを使わず、バイナリログを読みに行く設計。書き込みパスへの影響が小さく、レプリカに対して migration を走らせて完成したらマスターに昇格させる、という運用もできます。GitHub・Shopify・Booking.com などが本番で使い込んでいて、500GB級のテーブルでも安定して通ります。MySQL 系の本番DB ALTER は、2026年時点では gh-ost を第一選択にしてよいと考えます。
## PostgreSQL は事情が違う
PostgreSQL は MySQL とまったく別の世界です。PostgreSQL 11 で `ALTER TABLE ADD COLUMN ... DEFAULT` が「メタデータのみの変更」に最適化されて以来、カラム追加の苦痛は激減しました。NULL 許容のカラム追加は MySQL 8.0 の INSTANT と同様に瞬時。NOT NULL DEFAULT 付きの追加も、PostgreSQL 11 以降では即時です。
それでも詰まる変更があります。型変更、CHECK 制約の追加、UNIQUE 制約の追加、PRIMARY KEY の再設計 ── このあたりは古典的な ACCESS EXCLUSIVE ロックを取ります。10GB のテーブルに UNIQUE 制約を素朴に追加すると、本番のクエリが30分止まる、という事故が起きます。
PostgreSQL での回避の定石は `CREATE INDEX CONCURRENTLY` と `NOT VALID` 制約の活用です。UNIQUE 制約を入れたいなら、まず `CREATE UNIQUE INDEX CONCURRENTLY`、その後 `ALTER TABLE ... ADD CONSTRAINT ... USING INDEX` で制約に昇格させる。CHECK 制約は `NOT VALID` で先に張って、後から `VALIDATE CONSTRAINT` で実データ検証 ── これで本番ロックを最小化できます。
テーブル全体の書き換えが必要なケース（圧縮、PK再構築、TOAST 設定変更）では pg_repack が本命です。pg_repack は VACUUM FULL と違ってオンラインで動き、書き込みを止めずにテーブル再構築できます。500GBのテーブルで20時間かかった事例もありますが、その20時間の間サービスは止まりません。
## Blue/Green デプロイで根本的に解決する選択肢
AWS RDS が2023年に Blue/Green Deployments を出してから、状況がさらに変わりました。本番DB（Blue）のクローン（Green）を作り、Green にだけスキーマ変更を流し、テスト完了後にスイッチオーバーで Green を本番にする ── スイッチオーバーは最短60秒程度で完了します。
2026年現在、AWS RDS MySQL/MariaDB/PostgreSQL、Aurora MySQL/PostgreSQL で利用可能です。料金は Blue 環境と同等の Green を立てる分だけ余計にかかりますが、1〜2日のスキーマ変更案件のためなら数千〜数万円の追加で済みます。経営判断としては圧倒的に正しい投資です。
ただし万能ではありません。論理レプリケーションが裏側で走るため、レプリケーション非対応のテーブル構造（PK なし、特定の型）があると失敗します。事前検証は必須で、ステージング環境で Blue/Green を一度通してから本番に臨むべきです。
AWS 以外でも Google Cloud SQL や Azure Database for PostgreSQL に類似機能が出てきていますが、AWS が一歩進んでいる、というのが実装比較した上での評価です。
## 詰まった時の戻し方を最初に決めておく
本番マイグレーションで最も致命的な失敗は、「途中で詰まった時の戻し方を決めずに走り始める」ことです。冒頭の9時間停止事例も、これが原因でした。
チェックリストとして最低限以下を事前に握っておく必要があります。マイグレーション開始前のフルバックアップ確認とリストア手順、想定所要時間とアラートしきい値（例：90分で50%未進行なら中断判断）、中断時のロールバック手順（gh-ost なら `--throttle` フラグでの一時停止、pg_repack なら SIGINT での中断）、関係者の待機時間とエスカレーション経路、ユーザ向け告知文の事前準備。
特に gh-ost の `--cut-over=default --postpone-cut-over-flag-file=/tmp/ghost.postpone` の組み合わせは、本番切り替えの瞬間だけ人間判断を挟めるので、ピーク帯回避に重宝します。トラフィックが落ち着いた深夜2時に flag file を削除して切り替え、という運用ができます。
## マイグレーション中の監視で見るべき5指標
稼働中の DB に変更を流している間、見るべき指標が決まっています。レプリケーションラグ（MySQL なら Seconds_Behind_Master、PostgreSQL なら pg_stat_replication.replay_lag）、コネクションプール使用率、p95/p99 レイテンシ、ディスク使用量、IO 待ち（iowait）。
Datadog・New Relic・CloudWatch どれを使ってもよいですが、これらをひとつのダッシュボードにまとめて、マイグレーション担当者がフルスクリーンで見続ける運用が必須です。レプリケーションラグが30秒を超えたら throttle を強める、p99が普段の2倍を超えたら一時停止 ── このしきい値を事前に決めておくと、現場の判断が速くなります。
## 失敗からの戻りで一番効くのは事前の選択肢の多さ
本番DBの ALTER で何度も巻き戻し対応をしてきましたが、最終的に効くのは「ツール選択肢の知識量」です。pt-osc / gh-ost / pg_repack / RDS Blue/Green / 論理レプリケーション + カットオーバー ── このメニューを全部理解した上で「今回はこれ」を選べる体制が、安全な本番運用と直結します。
社内DBAが1人もいない、外部ベンダーから「メンテ4時間で流せます」と言われたが不安、過去にマイグレーションで本番を落としたことがある ── このどれかに該当する組織は、相談をいただければ、現状のテーブル規模とインフラ構成に合わせた手順設計と当日支援まで対応します。1テーブルあたりの設計レビューだけなら数日で完了するケースが大半です。
本番DBのスキーマ変更が一夜にして恐ろしくなるラインがあります。経験則として、単一テーブルが10GBを超えた、もしくは行数が5,000万を超えた瞬間です。それまで普通に通っていた `ALTER TABLE ADD COLUMN` が、ある日突然「3時間経っても終わらない、ロックでアプリが落ちる、メンテ枠を延長できない」という地獄を呼びます。
相談を受けた事例でいちばん深刻だったのは、テーブル4億行・容量85GBの注文履歴テーブルに NOT NULL カラムを追加しようとして、メンテ枠の4時間で終わらず、ロールバックも効かず、結局9時間のサービス停止になった案件です。EC事業者で、9時間止まれば被害額は数千万円規模。経営会議に呼び出されてから相談が来ました。
この手の事故は、ツール選定と運用設計を最初の段階で決めておけば、ほぼ100%回避できます。
## MySQL の選択肢 ─ pt-online-schema-change か gh-ost か、それともネイティブ Online DDL か
MySQL 5.6 以降、ネイティブの Online DDL は「ALGORITHM=INPLACE, LOCK=NONE」をサポートしていて、カラム追加・インデックス追加の多くはオンラインで通ります。MySQL 8.0 ではさらに INSTANT ADD COLUMN が入り、テーブル末尾へのカラム追加は瞬時に終わる ── これは本当に瞬時で、4億行のテーブルでも数ミリ秒です。
問題は、INSTANT で通らない変更です。カラム型の変更、NOT NULL 制約の追加、PRIMARY KEY の変更、カラムの順序変更、文字コード変更 ── このあたりは INPLACE でもテーブルを書き換える必要があり、容量と同程度のディスクと、変更中の書き込み負荷を全部吸収するレプリケーションラグが発生します。
ここで pt-online-schema-change（Percona Toolkit）か gh-ost（GitHub 製）の出番です。両者ともシャドウテーブルを作って差分をバイナリログから流し込み、最後に RENAME で切り替える方式ですが、設計思想がはっきり違います。
pt-online-schema-change はトリガーベース。元のテーブルに INSERT/UPDATE/DELETE のトリガーを張って、シャドウテーブルへ自動同期します。シンプルですが、書き込み負荷の高いテーブルだと、トリガーがアプリのレイテンシをまるごと押し上げる事故が起きます。p99レイテンシが80ms→340msに跳ねた事例を、過去2件確認しています。
gh-ost はトリガーを使わず、バイナリログを読みに行く設計。書き込みパスへの影響が小さく、レプリカに対して migration を走らせて完成したらマスターに昇格させる、という運用もできます。GitHub・Shopify・Booking.com などが本番で使い込んでいて、500GB級のテーブルでも安定して通ります。MySQL 系の本番DB ALTER は、2026年時点では gh-ost を第一選択にしてよいと考えます。
## PostgreSQL は事情が違う
PostgreSQL は MySQL とまったく別の世界です。PostgreSQL 11 で `ALTER TABLE ADD COLUMN ... DEFAULT` が「メタデータのみの変更」に最適化されて以来、カラム追加の苦痛は激減しました。NULL 許容のカラム追加は MySQL 8.0 の INSTANT と同様に瞬時。NOT NULL DEFAULT 付きの追加も、PostgreSQL 11 以降では即時です。
それでも詰まる変更があります。型変更、CHECK 制約の追加、UNIQUE 制約の追加、PRIMARY KEY の再設計 ── このあたりは古典的な ACCESS EXCLUSIVE ロックを取ります。10GB のテーブルに UNIQUE 制約を素朴に追加すると、本番のクエリが30分止まる、という事故が起きます。
PostgreSQL での回避の定石は `CREATE INDEX CONCURRENTLY` と `NOT VALID` 制約の活用です。UNIQUE 制約を入れたいなら、まず `CREATE UNIQUE INDEX CONCURRENTLY`、その後 `ALTER TABLE ... ADD CONSTRAINT ... USING INDEX` で制約に昇格させる。CHECK 制約は `NOT VALID` で先に張って、後から `VALIDATE CONSTRAINT` で実データ検証 ── これで本番ロックを最小化できます。
テーブル全体の書き換えが必要なケース（圧縮、PK再構築、TOAST 設定変更）では pg_repack が本命です。pg_repack は VACUUM FULL と違ってオンラインで動き、書き込みを止めずにテーブル再構築できます。500GBのテーブルで20時間かかった事例もありますが、その20時間の間サービスは止まりません。
## Blue/Green デプロイで根本的に解決する選択肢
AWS RDS が2023年に Blue/Green Deployments を出してから、状況がさらに変わりました。本番DB（Blue）のクローン（Green）を作り、Green にだけスキーマ変更を流し、テスト完了後にスイッチオーバーで Green を本番にする ── スイッチオーバーは最短60秒程度で完了します。
2026年現在、AWS RDS MySQL/MariaDB/PostgreSQL、Aurora MySQL/PostgreSQL で利用可能です。料金は Blue 環境と同等の Green を立てる分だけ余計にかかりますが、1〜2日のスキーマ変更案件のためなら数千〜数万円の追加で済みます。経営判断としては圧倒的に正しい投資です。
ただし万能ではありません。論理レプリケーションが裏側で走るため、レプリケーション非対応のテーブル構造（PK なし、特定の型）があると失敗します。事前検証は必須で、ステージング環境で Blue/Green を一度通してから本番に臨むべきです。
AWS 以外でも Google Cloud SQL や Azure Database for PostgreSQL に類似機能が出てきていますが、AWS が一歩進んでいる、というのが実装比較した上での評価です。
## 詰まった時の戻し方を最初に決めておく
本番マイグレーションで最も致命的な失敗は、「途中で詰まった時の戻し方を決めずに走り始める」ことです。冒頭の9時間停止事例も、これが原因でした。
チェックリストとして最低限以下を事前に握っておく必要があります。マイグレーション開始前のフルバックアップ確認とリストア手順、想定所要時間とアラートしきい値（例：90分で50%未進行なら中断判断）、中断時のロールバック手順（gh-ost なら `--throttle` フラグでの一時停止、pg_repack なら SIGINT での中断）、関係者の待機時間とエスカレーション経路、ユーザ向け告知文の事前準備。
特に gh-ost の `--cut-over=default --postpone-cut-over-flag-file=/tmp/ghost.postpone` の組み合わせは、本番切り替えの瞬間だけ人間判断を挟めるので、ピーク帯回避に重宝します。トラフィックが落ち着いた深夜2時に flag file を削除して切り替え、という運用ができます。
## マイグレーション中の監視で見るべき5指標
稼働中の DB に変更を流している間、見るべき指標が決まっています。レプリケーションラグ（MySQL なら Seconds_Behind_Master、PostgreSQL なら pg_stat_replication.replay_lag）、コネクションプール使用率、p95/p99 レイテンシ、ディスク使用量、IO 待ち（iowait）。
Datadog・New Relic・CloudWatch どれを使ってもよいですが、これらをひとつのダッシュボードにまとめて、マイグレーション担当者がフルスクリーンで見続ける運用が必須です。レプリケーションラグが30秒を超えたら throttle を強める、p99が普段の2倍を超えたら一時停止 ── このしきい値を事前に決めておくと、現場の判断が速くなります。
## 失敗からの戻りで一番効くのは事前の選択肢の多さ
本番DBの ALTER で何度も巻き戻し対応をしてきましたが、最終的に効くのは「ツール選択肢の知識量」です。pt-osc / gh-ost / pg_repack / RDS Blue/Green / 論理レプリケーション + カットオーバー ── このメニューを全部理解した上で「今回はこれ」を選べる体制が、安全な本番運用と直結します。
社内DBAが1人もいない、外部ベンダーから「メンテ4時間で流せます」と言われたが不安、過去にマイグレーションで本番を落としたことがある ── このどれかに該当する組織は、相談をいただければ、現状のテーブル規模とインフラ構成に合わせた手順設計と当日支援まで対応します。1テーブルあたりの設計レビューだけなら数日で完了するケースが大半です。