セルフホスト型データベースのアップグレードガイド：ダンプ、スナップショット、移行、ロールバック
安全なアプローチとは、ネイティブダンプ、ストレージスナップショット、分離したリストアリハーサル、明確に定めたロールバックポイントを使った段階的なアップグレードを、単一のコマンドではなく、観測可能なゲートの連続として扱うことです。
ホームサーバー上のコンテナ化されたPostgreSQLまたはMariaDBデータベースでは、実際のリスクは、論理オブジェクトや実行可能なロールバック経路を失わずに、セルフホスト型データベースをバージョンアップする必要があることです。現在の識別情報と復旧ポイントを記録し、最も侵襲性の低い判別から始め、別の変数を変更する前に合否の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが露出するものしか残っていない場合は停止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーション境界に達するまで完了しません。
バックアップ前に互換性とロールバックを定義する
データベースエンジンと正確な移行元バージョン、移行先バージョン、アプリケーションのバージョン、拡張機能またはプラグイン、文字セット、認証ルール、スケジュールされたジョブ、許容できる停止時間を記録します。アプリケーションのアップグレードノートだけでなく、データベースの移行経路も確認してください。アプリケーションのマイグレーションによって、古いバイナリが新しいスキーマと互換性を失う可能性があるためです。
メジャーアップグレードでは、多くの場合、古いデータディレクトリを新しいイメージにマウントするのではなく、論理ダンプとリストア、またはサポートされている移行ツールが必要です。独立したComposeデータベースのメジャーアップグレード手順では、ComposeベースのPostgreSQLメジャーアップグレードを詳しく説明し、古いコンテナとボリュームを移行先のものから分離しておく必要性を示しています。
ロールバックの期限とトリガーを今のうちに書き出します。対象には、整合性チェックの失敗、ロールや拡張機能の欠落、アプリケーションエラー、許容できないパフォーマンスなどが含まれます。ロールバックが有効なのは、移行先で本番書き込みを開始するまでです。ただし、逆方向のデータ移行計画をテスト済みの場合は除きます。
独立した復旧ポイントを2つ作成する
該当する場合はグローバルオブジェクトを含めて、データベースエンジン固有の論理バックアップを実行し、コマンド、バージョン、終了ステータス、マニフェスト、チェックサムを保存します。1つのデータベースダンプにすべてのサーバーレベルの依存関係が含まれると決めつけず、ユーザー、権限、拡張機能、スキーマ、スケジュールされたジョブ、大規模オブジェクトが含まれていることを確認します。
データベースがサポートされる状態にあることを確認したうえで、データベースボリュームの整合性のあるスナップショット、または停止後のコピーを取得します。論理ダンプは可搬性とオブジェクト単位の検査を提供し、ストレージコピーは旧バージョンへ正確にロールバックできるポイントを保持します。どちらか一方で他方を上書きしてはいけません。
ZimaSpaceの検証チェックリストを使って、データベースバックアップ完全性チェックリストを確認します。バックアップゲートを通過するのは、ダンプが読み取り可能で、ストレージ復旧ポイントが特定され、両方がアップグレード対象のボリューム外に保存されている場合だけです。
分離した移行先で移行をリハーサルする
別のボリュームとポートで移行先データベースを起動し、必要な拡張機能をインストールして論理バックアップをリストアし、すべての警告を保存します。Perconaの論理ダンプとリストアによるアップグレード経路の解説では、ダンプとリストアの手順、および想定するPostgreSQLアップグレード経路に適合したツールを使用する必要性が強調されています。
使い捨てのアプリケーションインスタンスをリストア済みデータベースに接続します。ログイン、読み取り、書き込み、バックグラウンドジョブ、検索、添付ファイル、タイムゾーン、再起動をテストします。リストアの終了コードが成功したことだけに頼らず、行数と重要な集計値を比較します。
拡張機能を利用できない場合、照合順序の変更が解決されていない場合、マイグレーションに失敗した場合、またはリストア時間がメンテナンス時間を超える場合は進めないでください。リハーサルを修正して新しいダンプを作成します。移行先バージョンとの互換性を発見する場所は本番環境ではありません。
書き込みを切り替え、ロールバックをクリーンに保つ
メンテナンスモードに入り、アプリケーションの書き込み処理とジョブを停止し、アクティブな接続が解消されたことを確認してから、最終ダンプまたはサポートされている差分を作成します。クリーンな移行先にリストアし、整合性チェックとオブジェクトチェックを実行し、アプリケーションの接続先を更新して、依存関係の順序に従ってサービスを起動します。
エラー率、ロック、ジョブの実行、バックアップ、実際のアプリケーションのトランザクションを監視します。元のボリュームとイメージダイジェストを保持したまま、古いデータベースを停止して読み取り専用にします。同じアプリケーションIDで、両方のデータベースが独立した書き込みを受け付ける状態にしてはいけません。
アプリケーション、ネイティブバックアップジョブ、再起動、新バージョンからのテストリストアがすべて成功して初めて、成功と宣言します。書き込み境界に達する前にロールバックトリガーが発火した場合は、アプリケーションを保持している古いインスタンスへ戻します。新しい書き込みの後は、単純な再起動でデータが元に戻るかのように扱わず、停止して文書化された調整計画を使用してください。
おすすめ商品
サポートとヒント
もっと読む
名前を変更したデータセットと安定したファイルハンドルのためのNFS移行チェックリスト
ストレージの識別情報が変わるとファイルハンドルも変わる可能性があることを前提としてください。クライアントを停止し、エクスポートを意図的に切り替え、再マウントして、開いているファイルと新規ファイルを検証してください。
Windows、macOS、Linux向けSMBクライアントのトラブルシューティングガイド
各クライアントで同じサーバー、アカウント、共有、ファイル操作を使用し、検出、認証情報、ポリシー、ストレージの障害が混在しないようにします。
アプリ、データベース、バックアップ向けホームサーバーのシークレットローテーションチェックリスト
ローテーションは依存関係の移行として扱い、すべての利用箇所を洗い出し、可能な場合は認証情報を重複配置し、新しい値を検証してから、古い値を無効化し、復旧をテストします。
