第17章: OzOSC - ゼロダウンタイム スキーマ変更
概要: この章では、OzOSC（Online Schema Change）のアーキテクチャと安全境界について説明します。MySQL および MariaDB において、本番稼働中の大規模テーブルに対する安全なゼロダウンタイム DDL 実行とリカバリ機構を提供します。
本章の内容:
17.1 概要と課題
高トラフィックな本番環境で標準の ALTER TABLE を実行すると、以下の深刻なリスクが発生します。
- テーブルロック: データベースエンジンがテーブルへの読み書きをブロック。
- サービス停止（ダウンタイム）: アプリケーションのリクエストがタイムアウトし、システム障害に発展。
- レプリケーション遅延: スレーブ/レプリカノードでの遅延が急増し、データ不整合を招く。
OzOSC は、読み取り専用の事前検証（メタデータ整合性、主キーの存在、サーバーアイデンティティ）を実施。検証済みバックアップを作成し、シャドウテーブルを構築、行データを小さなチャンク単位でコピーした上で、最終的なアトミックスワップを安全に完了させます。
17.2 現在のサポート状況
OzOSC は現在、検証済みの主キーを持つ MySQL および MariaDB のテーブルをネイティブでサポートしています。SQLite や PostgreSQL ではこのネイティブ OSC パスは使用されません。トリガーが既に定義されているテーブルや、非互換の生成列を含むテーブルは検証段階で安全のため除外されます。
17.3 計画された実行プロセス
[ 本番稼働テーブル: orders ] --(トリガーによる差分同期)--> [ シャドウテーブル: _orders_sqloz_osc ]
(読み書きは一切中断せず継続) (ALTER TABLE を高速適用)
|
(アトミックスワップ − 1ミリ秒)
v
[ 新しい本番テーブル: orders ]保護された実行フェーズ：
- シャドウテーブルの作成: 対象テーブルと同一構造の空のシャドウテーブルを生成。
- スキーマ変更の適用: 空のシャドウテーブルに対して
ALTER TABLEを実行（一瞬で完了）。 - トリガーによる差分ミラーリング: コピー中に本番テーブルへ発生した
INSERT,UPDATE,DELETEをリアルタイムでシャドウへ反映。 - チャンク単位のデータ移行: サーバー負荷とレプリケーション遅延を監視しながら、既存データを安全なバッチサイズで順次コピー。
- アトミックスワップ: コピー完了後、テーブル名をアトミックに切り替え（ミリ秒単位）。古いテーブルは検証が完了するまで保持されます。
異常終了した場合は、OzOSC パネルの Refresh Recovery を利用します。
- Complete cleanup: スワップ完了後の残留一時オブジェクトを安全に削除。
- Resume copy: チェックポイント情報からデータコピーを安全に再開。
- Abort preparation: スワップ前の安全な状態において、シャドウテーブルとトリガーのみを破棄し、本番テーブルを完全に保護。
警告: MySQL/MariaDB の DDL はトランザクションロールバックに対応していません。OzOSC は不整合の兆候を検知した場合、即座に fail-closed で処理を停止し、安全を最優先します。
17.4 リアルタイム進行状況の追跡
- コピー速度 (Rows/sec): 毎秒の転送レコード数。
- 完了予定時間 (ETA): 現在のスループットに基づく予測残り時間。
- 安全なキャンセル: キャンセル要求時は適切なロールバック/後処理が明示的に実行されます。