Running DDL safely#

地域分散クラスターでのDDL操作は、書き込みリーダー全体でロックを取得し、ステートメントの間保持されます。 DDLトランザクションを小さくし、DMLとの混合を避け、トラフィックの少ない時間帯にスケジュールして、アプリケーションのスループットへの影響を最小限に抑えます。

ロックの取得時間は、書き込みリーダー間の往復レイテンシーに比例するため、ローカルクラスターでミリ秒を要するDDLは、マルチリージョンセットアップでは数秒かかる場合があります。これらのプラクティスを適用して、影響を最小限に抑えます。

追加的な変更を行う 列の追加、インデックスの追加、または新しいテーブルの作成は低リスクです。列の削除、列の名前の変更、およびデータ型の変更は、スキーマ変更をまだ受け取っていないノードで実行中のアプリケーションコードを中断する可能性があるため、より注意が必要です。ローリング展開では、古いスキーマに依存するすべてのアプリケーションバージョンがリタイアするまで、下位互換性を維持します。
最初にNullable列を追加します 新しい列にNOT NULL 制約がある場合、クラスター全体の既存の行は、制約を適用する前にデフォルト値またはバックフィルが必要です。最初に列をNullableとして追加し、データをバックフィルして、後続の移行に制約を追加します。
アプリケーションコードの前にスキーマ変更を展開します 最初に追加的なスキーマ変更をロールアウトし、次にそれらを使用するアプリケーションコードを展開します。スキーマは、ノードがそれに依存するクエリの送信を開始する前に、すべてのノードに配置されます。
DDLを分離したままにする 各DDLステートメントは、クラスター全体のDDLロックを保持し、他の同時実行DDLを防ぎます。 DDLステートメントを単一のトランザクションで組み合わせるのではなく、個別に実行し、 DDLとDMLを決して混合しないでください。スキーマの変更とデータ操作を組み合わせると、ロックの期間が延長されてトランザクション全体をカバーします。
DDLを実行する前に長時間実行トランザクションを解決します 長時間実行トランザクションは、 DDLがクラスター全体のロックを取得することをブロックします。 DDLを実行する前に、長時間実行されているクエリまたはトランザクションを確認および解決します。
ロールバック計画を立ててください すべてのDDLをコミット後にロールバックできるわけではありません。 DROP TABLE やDROP COLUMN のような破壊的な変更の場合、本番で変更を実行する前に、テストされたロールバックプロシージャを作成します。