データベースのインプレース メジャー バージョン アップグレードの概要

このドキュメントでは、AlloyDB for PostgreSQL データベースのインプレース メジャー バージョン アップグレードについて説明します。これにより、データを移行したり、既存のインスタンスを置き換えたりすることなく、データベースを新しいバージョンにアップグレードできます。

PostgreSQL コミュニティは、新機能、パフォーマンス改善、セキュリティ強化を含む新しいメジャー バージョンを定期的にリリースしています。PostgreSQL が新しいメジャー バージョンをリリースすると、AlloyDB は互換性のあるバージョンのサポートを追加します。データベースを最新の状態に保つには、メジャー バージョンをアップグレードして AlloyDB クラスタをアップグレードします。クラスタをアップグレードするには、このインプレース アップグレード機能を使用するか、新しい AlloyDB クラスタにデータを移行します。

詳細については、データベースのバージョン ポリシーをご覧ください。

インプレース メジャー バージョン アップグレードは、次の理由から、クラスタのメジャー バージョンをアップグレードする効率的な方法です。

  • AlloyDB は、アップグレード後にクラスタとインスタンスの詳細と、インスタンス名、IP アドレス、データベース フラグなどのデータベース設定を保持します。
  • アプリケーション接続文字列を変更する必要はありません。
  • すべてのクラスタ インスタンス(プライマリ プールとリードプール)が同じオペレーションの一部としてアップグレードされます。

メジャー バージョンのインプレース アップグレード ワークフロー

クラスタのアップグレードを開始すると、AlloyDB は次のアクションを実行します。

  1. アップグレード前のチェックを実行して、アップグレードに影響する可能性のある互換性の問題を探します。
  2. メジャー バージョン アップグレードの準備を行います。これには、クラスタの内部クローンの作成が含まれます。
  3. プライマリ インスタンスを使用不可にします。休息時間の開始。読み取りは読み取りプールから引き続き行うことができます。
  4. アップグレード前のバックアップを開始します。
  5. プライマリ インスタンスをアップグレードします。
  6. 読み取りプール インスタンスを使用不可にします。
  7. プライマリ インスタンスを使用可能にします。休息時間の終了。
  8. アップグレード後のバックアップを開始します。
  9. 読み取りプール インスタンスをアップグレードします。

アップグレード前のチェックに合格すると、クラスタが同じプロジェクトの内部クラスタにクローンされます。クラスタのクローンを作成するために必要なバックアップと復元には、データベースのサイズによっては時間がかかることがあります。次の例は、データベースのサイズと、対応するバックアップと復元の所要時間を示しています。

  • 1 TB のクラスタのクローンを作成するには約 30 分かかります。
  • 10 TB の場合、クラスタのクローンを作成するのに約 2 時間かかります。

クローン作成オペレーション中は、元のクラスタを継続して使用できます。クローン作成オペレーションが完了すると、アップグレード プロセスが開始されます。プライマリ インスタンスがアップグレードされるまで、プライマリ インスタンスは読み取りと書き込みの両方で使用できません。通常、予想されるダウンタイムは 20 分から 1 時間で、主にデータベース スキーマとオブジェクトの数によって異なります。

プライマリ インスタンスのアップグレード前のいずれかのステップでメジャー バージョンのアップグレードが失敗した場合、AlloyDB はすべての変更を自動的にロールバックします。

プライマリ インスタンスがアップグレードされると、クラスタ バージョンがターゲット バージョンにアップグレードされ、この時点以降の障害に対してロールバックはトリガーされません。たとえば、1 つ以上の読み取りプール インスタンスのアップグレードが失敗しても、AlloyDB はクラスタをロールバックしません。このような場合は、Google Cloud CLI サポートにお問い合わせください。

詳細については、データベースのメジャー バージョンをインプレースでアップグレードするをご覧ください。

アップグレードのステータス

インプレース データベースのメジャー バージョン アップグレード オペレーションのステータスをモニタリングできます。

アップグレード プロセスには、次のステージがあります。

  • ALLOYDB_PRECHECK
  • PG_UPGRADE_CHECK
  • PREPARE_FOR_UPGRADE
  • PRIMARY_INSTANCE_UPGRADE
  • READ_POOL_INSTANCES_UPGRADE
  • ROLLBACK(読み取りプールのアップグレード前に障害が発生した場合のみ)
  • CLEANUP

これらのステージのステータスには、次のものがあります。

  • NOT_STARTED
  • IN_PROGRESS
  • SUCCESS
  • FAILED
  • CANCEL_IN_PROGRESS
  • CANCELLED

アップグレードの解約

プライマリ インスタンスのアップグレード中に、特定の時点までアップグレード オペレーションをキャンセルできます。この期間を過ぎると、アップグレードをキャンセルすることはできません。

Google Cloud コンソールで、[アップグレードをキャンセル] ボタンがグレー表示になっている場合、オペレーションはキャンセルできません。Google Cloud CLI または REST API を使用して、アップグレード ステータスの upgradeClusterStatus を確認することで、アップグレードをキャンセルできるかどうかを判断できます。

  • cancellabletrue の場合、アップグレードをキャンセルできます。
  • cancellablefalse の場合、またはステータスにない場合、アップグレードをキャンセルすることはできません。

アップグレード前後の自動バックアップ

メジャー バージョン アップグレードを実行すると、AlloyDB は次の継続バックアップを自動的に作成します。ここで、XX はソースのメジャー バージョン、YY はターゲットのメジャー バージョンです。

  • アップグレード前のバックアップは、アップグレードの開始直前に作成されます。このバックアップの名前は pre-upgrade-bkp-pgXX-pgYY-<uuid> の形式で付けられます。このバックアップを使用して、アップグレード前の状態に復元できます。復元はインプレース オペレーションではなく、新しいクラスタが作成されることに注意してください。
  • アップグレード後のバックアップは、プライマリ インスタンスのアップグレード後に作成されます。このバックアップの名前は post-upgrade-bkp-pgXX-pgYY-<uuid> の形式で付けられます。

継続的バックアップは増分バックアップです。つまり、バックアップには、前回の継続的バックアップと比較して変更されたデータのみが保存されます。このアプローチにより、バックアップのサイズとコスト(リソース)が削減され、バックアップ作成プロセスが高速化されます。詳細については、データのバックアップと復元の概要をご覧ください。

バックアップのリストを表示すると、アップグレード バックアップは CONTINUOUS タイプで表示されます。詳細については、バックアップのリストを表示するをご覧ください。

ポイントインタイム リカバリ(PITR)を実行するには、バージョンのバックアップが使用可能である必要があります。アップグレード後のバックアップ、またはプライマリ インスタンスのアップグレード後に開始された別のバックアップが完了するまで、アップグレードされたクラスタで復元は使用できません。

次のステップ