リリース間でデータベース変更の互換性を保つ

すべてのリーダーとライターを洗い出す

代表的なサニタイズ済みデータを使い、分離されたスキーマで作業します。現在と次のアプリケーションバージョン、マイグレーションフレームワークの知識、レビュー済みのバックアップ戦略、長時間トランザクションへの可視性が必要です。ワーカー、スケジュールジョブ、レポート、古いアプリケーションインスタンスも含めます。APIが素早く更新されても、長時間実行されるワーカーが依然として古いカラムに書き込んでいる可能性があります。

説明用のレポートサービスはエクスポートラベルを次に保存します label そして次のようにしたい display_name。これは設計例であり、汎用的に実行可能なSQLではありません。マイグレーション構文やロック設定を選ぶ前に、正確なPostgreSQLバージョンとフレームワークを確認してください。

古い表現を廃止せずに拡張する

まず新しいNULL可能なフィールドを導入します。1つのトランザクションで両方の値を書き込み、データが不完全な間は必要なフォールバックで読み取る互換性リリースをデプロイします。バックフィル中に顧客がレコードを編集したときの動作を定義します。リトライによって2つ目の論理エクスポートが作られてはなりません。

PostgreSQL ALTER TABLE の操作はロックを取得し、そのレベルはサブコマンドによって異なります。小さな変更が長時間トランザクションの後ろで待機し、その後ほかの作業を妨げる可能性があります。リハーサル中に特定の操作を確認し、待機を観察してください。追加的とはロックフリーを意味しません。

技術リファレンス: PostgreSQL ALTER TABLE · PostgreSQL 明示的ロック.

互換性の境界を可視化する

欠損値のフォールバックは、非NULLだが古い新しい値を検出できません。リーダーを切り替える前に、古い方のみのライターを廃止し、一貫性を検証してください。リーダー切り替え後に古い方のみのコードへロールバックすると、再び乖離が生じる可能性があります。代わりに互換性リリースをレビュー済みのリカバリ成果物として維持してください。

限定的で再開可能な作業でバックフィルする

新しい顧客編集を上書きせずに、コピーが必要な行を見つけます。安定した順序、並行安全な更新条件、ワークロードに合わせて選んだバッチを使用します。進捗を永続化し、障害時に既知の境界から再開できるようにします。書き込み量、ロック待機、リクエスト遅延、存在する場合はレプリケーションを監視します。

すべてのアプリケーションにとって安全なバッチサイズはありません。リハーサルでは小さなバッチを通常トラフィックと比較し、その後一時停止または停止のルールを選びます。バッチが失敗した場合、リトライ前に何がコミットされたかを確認します。無制限のリトライループは、回復可能な不一致を持続的なデータベース負荷に変える可能性があります。

行が埋まっているかだけでなくセマンティクスを確認する

欠損値、代表的なラベル、新規レコード、既存エクスポートの更新を検証します。非NULL行のカウントは正しく見えても、値が間違ったソースからコピーされている可能性があります。部分的に投入されたデータに対して互換性成果物をテストし、デプロイ前に起動されたワーカーを実行します。

スキーマバージョン、マイグレーションリビジョン、完了基準、互換性のない組み合わせを記録します。どちらかを削除する前に、フォールバックの使用と一貫性を確認します。チェックが失敗した場合、バックフィルまたは昇格を停止し、証拠を保全し、互換性のある成果物またはレビュー済みの前方修復を選びます。アプリケーションのロールバックがコミット済みデータを再構築するとは主張しないでください。

別のレビュー済みリリースで古いフィールドを廃止する

バックフィルと観察期間が基準を満たした後、古い読み取りと書き込みを削除します。対話的ルートだけでなく、頻度の低いジョブも確認します。古いフィールドの削除は、独自のリカバリ判断を伴う後続の変更に属するため、リリース問題によってコード修復とデータ再構築を組み合わせることを強いられません。

廃止後に悪いデータが現れた場合、さらなる損害を止め、リカバリ計画または承認済み修復を使用します。ツールがロールバックボタンを表示しているという理由だけで、破壊的なダウンマイグレーションを適用しないでください。マトリクスを次に添付します リリース記録 そしてリハーサルする データリカバリ 本番環境を変更する前に。有用な結果は明示的な互換性の境界であり、ゼロダウンタイムの保証ではありません。