Azure Database for PostgreSQL のビジネス継続性とは、特にコンピューティング インフラストラクチャの中断に直面した場合にビジネスを継続できるメカニズム、ポリシー、および手順を指します。 ほとんどの場合、Azure Database for PostgreSQLはクラウド環境で発生する可能性のある破壊的なイベントを処理し、アプリケーションとビジネス プロセスを実行し続けます。 ただし、次のような一部のイベントは自動的に処理できません。
- ユーザーが誤ってテーブル内の行を削除または更新した。
- 地震により停電が発生し、可用性ゾーンまたはリージョンが一時的に無効になります。
- バグまたはセキュリティの問題を修正するために、データベースの修正プログラムを適用する必要がある。
Azure Database for PostgreSQLには、計画的および計画外のダウンタイム イベント中に、ミッション クリティカルなデータベースのデータを保護し、ダウンタイムを軽減する機能が用意されています。 堅牢な回復性と可用性を提供する Azure インフラストラクチャに基づいて構築された Azure Database for PostgreSQL には、別の障害保護を提供し、復旧時間の要件に対処し、データ損失の露出を減らすビジネス継続性機能があります。 アプリケーションを設計するときは、ダウンタイムの許容度 (目標復旧時間 (RTO))、データ損失の露出 (目標復旧時点 ) を考慮してください。 たとえば、ビジネス クリティカルなデータベースでは、テスト データベースよりも厳しいアップタイムが必要になります。
次の表は、Azure Database for PostgreSQLが提供する機能を示しています。
| 特徴 | 説明 | 考慮事項 |
|---|---|---|
| 自動バックアップ | Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、データベース ファイルの毎日のバックアップを自動的に実行し、トランザクション ログを継続的にバックアップします。 バックアップは 7 日から 35 日まで保持できます。 データベース サーバーは、バックアップの保持期間内の任意の時点に復元できます。 RTO は、復元するデータのサイズとログ回復を実行する時間によって異なります。 数分から 12 時間までです。 詳細については、バックアップと復元の概念に関するページを参照してください。 | バックアップ データは、リージョン内に保持されます。 |
| ゾーン冗長の高可用性 | ゾーン冗長高可用性 (HA) 構成を使用してAzure Database for PostgreSQLフレキシブル サーバー インスタンスをデプロイできます。プライマリ サーバーとスタンバイ サーバーは、リージョン内の 2 つの異なる可用性ゾーンにデプロイされます。 この HA 構成は、ゾーン レベルの障害からデータベースを保護し、計画的および計画外のダウンタイム イベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。 プライマリ サーバーからのデータは、同期モードでスタンバイ レプリカにレプリケートされます。 プライマリ サーバーで何らかの障害が発生した場合、サーバーは自動的にスタンバイ レプリカにフェールオーバーされます。 ほとんどの場合、RTO は 120 秒未満であると予想されます。 RPO はゼロ (データ損失なし) であると想定されます。 詳細については、「 概念 - 高可用性」を参照してください。 | General Purpose と Memory Optimized のコンピューティング レベルでサポートされます。 複数のゾーンが使用可能なリージョンでのみ利用できます。 |
| 同一ゾーンの高可用性 | プライマリ サーバーとスタンバイ サーバーがリージョン内の同じ可用性ゾーンにデプロイされているのと同じゾーン高可用性 (HA) 構成を使用して、Azure Database for PostgreSQLフレキシブル サーバー インスタンスをデプロイできます。 この HA 構成は、ノード レベルの障害からデータベースを保護し、計画されたダウンタイム イベントや計画外のダウンタイム イベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。 プライマリ サーバーからのデータは、同期モードでスタンバイ レプリカにレプリケートされます。 プライマリ サーバーで何らかの障害が発生した場合、サーバーは自動的にスタンバイ レプリカにフェールオーバーされます。 ほとんどの場合、RTO は 120 秒未満であると予想されます。 RPO はゼロ (データ損失なし) であると想定されます。 詳細については、[概念 - 高可用性]/azure/reliability/reliability-postgresql-flexible-server を参照してください。 | General Purpose と Memory Optimized のコンピューティング レベルでサポートされます。 |
| Premium マネージド ディスク | データベース ファイルは、耐久性と信頼性に優れた Premium マネージド ストレージに格納されます。 このストレージは、可用性ゾーン内に格納されているレプリカの 3 つのコピーと自動データ復旧機能を備えたデータ冗長性を提供します。 詳細については、マネージド ディスクのドキュメントを参照してください。 | 可用性ゾーン内に格納されるデータ。 |
| ゾーン冗長バックアップ | Azure Database for PostgreSQL フレキシブル サーバー インスタンス のバックアップは、リージョンが可用性ゾーンをサポートしている場合、リージョン内のゾーン冗長ストレージに自動的かつ安全に格納されます。 サーバーがプロビジョニングされているゾーン レベルの障害が発生し、サーバーがゾーン冗長で構成されていない場合でも、別のゾーンの最新の復元ポイントを使用してデータベースを復元できます。 詳細については、バックアップと復元の概念に関するページを参照してください。 | 複数のゾーンが使用可能なリージョンにのみ適用されます。 |
| geo 冗長バックアップ | Azure Database for PostgreSQL フレキシブル サーバー インスタンスのバックアップは、リモート リージョンにコピーされます。 この機能は、プライマリ サーバー リージョンがダウンした場合のディザスター リカバリーの状況に役立ちます。 | この機能は、現在選択されているリージョンで有効になっています。 復元するデータのサイズと実行する復旧の量によっては、RTO は長くなり、RPO は高くなります。 |
| 読み取りレプリカ | リージョン間の読み取りレプリカをデプロイして、リージョン レベルの障害からデータベースを保護できます。 読み取りレプリカは、PostgreSQL の物理レプリケーション テクノロジを使用して非同期的に更新され、プライマリに遅れる可能性があります。 詳細については、読み取りレプリカの概念に関するページを参照してください。 | General Purpose と Memory Optimized のコンピューティング レベルでサポートされます。 |
次の表は、一般的なワークロード シナリオでの RTO と RPO を比較したものです。
| 能力 | バースト可能 | 運用 SKU (汎用/メモリ最適化) |
|---|---|---|
| バックアップからのポイントインタイム リストア | リテンション期間内の任意の復元ポイント RTO - 変動 RPO < 5 分 |
リテンション期間内の任意の復元ポイント RTO - 変動 RPO < 5 分 |
| Geo レプリケーション バックアップからの geo リストア | RTO - 変動 RPO < 1 時間 |
RTO - 変動 RPO < 1 時間 |
| 読み取りレプリカ | 該当なし | RTO - 分単位* RPO - 通常、30 秒から 5 分* の範囲 |
| 高可用性 | 該当なし | RTO < 120 秒 RPO = 0 |
計画的なダウンタイム イベント
次の表では、一般的な計画メンテナンス シナリオについて説明します。 通常、これらのイベントは数分のダウンタイムを引き起こしますが、データ損失は発生しません。
| シナリオ | 処理 |
|---|---|
| コンピューティングのスケーリング (ユーザーによる開始) | コンピューティング スケーリング操作中、このプロセスでは、アクティブなチェックポイントの完了、クライアント接続のドレイン、コミットされていないトランザクションの取り消し、ストレージのデタッチ、シャットダウンが可能になります。 このプロセスでは、同じデータベース サーバー名を持つ新しいAzure Database for PostgreSQLフレキシブル サーバー インスタンスがプロビジョニングされますが、コンピューティング構成はスケーリングされます。 このプロセスにより、ストレージが新しいサーバーにアタッチされ、データベースが開始されます。データベースは、クライアント接続を受け入れる前に必要に応じて復旧を実行します。 |
| ストレージのスケールアップ (ユーザーによる開始) | ストレージのスケールアップ操作を開始すると、アクティブなチェックポイントの完了、クライアント接続のドレイン、コミットされていないトランザクションの取り消しがプロセスによって許可されます。 その後、プロセスによってサーバーがシャットダウンされます。 このプロセスでは、ストレージを目的のサイズにスケーリングし、新しいサーバーにアタッチします。 このプロセスは、クライアント接続を受け入れる前に、必要に応じて復旧を実行します。 ストレージ サイズのスケールダウンはサポートされていないことに注意してください。 |
| 新しいソフトウェアのデプロイ (Azure による開始) | このサービスでは、計画メンテナンスの一環として、新機能やバグ修正が自動的にロールアウトされます。 これらのアクティビティがいつ発生するかをスケジュールできます。 詳細については、ポータルを確認してください。 |
| マイナー バージョンのアップグレード (Azure による開始) | Azure Database for PostgreSQL では、Azure によって決定されたマイナー バージョンへの修正プログラムが自動的にデータベース サーバーに適用されます。 この修正プログラムの適用は、サービスの計画メンテナンスの一環として行われます。 このプロセスでは、新しいマイナー バージョンでデータベース サーバーが自動的に再起動されます。 詳細については、こちらのドキュメントを参照してください。 ポータルでも確認できます。 |
高可用性を備えたAzure Database for PostgreSQLフレキシブル サーバー インスタンスを構成すると、サービスは最初にスタンバイ サーバーでスケーリングとメンテナンス操作を実行します。 詳細については、[概念 - 高可用性]/azure/reliability/reliability-postgresql-flexible-server を参照してください。
計画外のダウンタイムの軽減
計画外のダウンタイムは、基になるハードウェアの障害、ネットワークの問題、ソフトウェアのバグなど、予期しない中断の結果として発生する可能性があります。 高可用性で構成されたデータベース サーバーが予期せず停止した場合、サービスはスタンバイ レプリカをアクティブ化し、クライアントは操作を再開できます。 高可用性 (HA) でサーバーを構成しない場合、再起動が失敗した場合、サービスは新しいデータベース サーバーを自動的にプロビジョニングします。 計画外のダウンタイムを回避することはできませんが、Azure Database for PostgreSQLは、人の介入を必要とせずに復旧操作を自動的に実行することでダウンタイムを軽減するのに役立ちます。
エンジニアリング チームは継続的に高可用性の提供に努めていますが、Azure Database for PostgreSQLで障害が発生してデータベースが使用できなくなるため、アプリケーションに影響を与える場合があります。 サービスの監視によって、広範囲にわたる接続エラー、障害、またはパフォーマンスの問題を引き起こす問題が検出されると、サービスは自動的に停止を宣言して通知を受け取ります。
サービス停止
Azure Database for PostgreSQLフレキシブル サーバー インスタンスがダウンした場合、停止の詳細については、次の場所を参照してください。
- Azure ポータル バナー: サブスクリプションが影響を受けた場合、Azure ポータルの通知には、サービスの問題に関する停止アラートが表示されます。
![Azure portal の [通知] を示すスクリーンショット。](media/business-continuity/notification-service-issue-example.png)
- ヘルプ + サポート または サポート + トラブルシューティング: ヘルプ + サポート または サポート + トラブルシューティングからサポート チケットを作成すると、ポータルには、リソースに影響を与える問題に関する情報が含まれます。 影響の詳細と概要を確認するには、[View outage details] (停止の詳細を確認する) を選択します。 [ 新しいサポート要求 ] ページには、アラートも含まれています。
![Azure portal の [ヘルプとサポート] 通知を示すスクリーンショット。](media/business-continuity/help-support-service-health-notification.png)
- サービス正常性: Azure ポータルの [サービス正常性] ページには、データ センターの状態に関する情報Azureグローバルに表示されます。 Azure ポータルの検索バーで "サービス正常性" を検索し、[アクティブなイベント] カテゴリでサービスの問題を表示します。 また、[ヘルプ] メニューの任意のリソースの [リソース正常性] ページで、個々のリソースの正常性を確認することもできます。 [ サービス正常性] ページの次のスクリーンショットは、東南アジアでのアクティブなサービスの問題に関する情報を示しています。
- 電子メール通知: アラートを設定した場合、サービスの停止がサブスクリプションとリソースに影響を与えたときに電子メール通知を受け取ります。 メールは "azure-noreply@microsoft.com" から送信されます。 メールの本文は、"アクティビティ ログ アラート ... が Azure サブスクリプション ... のサービスの問題によってトリガーされました" で始まります。 サービス正常性アラートの詳細については、「Azure ポータルを使用して、Azure サービス通知のアクティビティ ログ アラートを受信する」を参照してください。
Important
その名前が示すように、PostgreSQL の一時テーブルスペースは一時オブジェクトだけでなく、その他の内部データベース操作 (並べ替えなど) にも使用されます。 そのため、サーバーの再起動後にこれらのオブジェクトの持続性、HA フェールオーバー、および同様のイベントが保証されないため、一時テーブルスペースにユーザー スキーマ オブジェクトを作成しないでください。
計画外のダウンタイム: 障害シナリオとサービス復旧
次の表では、計画外の一般的な障害シナリオと復旧プロセスについて説明します。
| シナリオ |
復旧プロセス [ゾーン冗長 HA なしで構成されたサーバー] |
復旧プロセス [ゾーン冗長 HA ありで構成されたサーバー] |
|---|---|---|
| データベース サーバーの障害 | データベース サーバーがダウンした場合、Azureはデータベース サーバーの再起動を試みます。 その試行が失敗した場合、Azureは別の物理ノード上のデータベース サーバーを再起動します。 復旧時間 (RTO) は、障害発生時のアクティビティ (大規模なトランザクションなど) やデータベース サーバーの起動プロセス中に実行する復旧量など、さまざまな要因によって異なります。 PostgreSQL データベースを使用するアプリケーションでは、削除された接続と失敗したトランザクションを検出して再試行する必要があります。 |
データベース サーバーの障害が検出された場合、サーバーはスタンバイ サーバーにフェールオーバーするため、ダウンタイムが短縮されます。 詳細については、[HA 概念ページ]/azure/reliability/reliability-postgresql-flexible-server を参照してください。 RTO は 60 ~ 120 秒で、データ損失は発生しません。 |
| ストレージの障害 | アプリケーションでは、ディスク障害や物理ブロックの破損など、ストレージ関連の問題による影響はありません。 データは 3 つのコピーに格納されるため、残りのストレージはデータのコピーを処理します。 破損したデータ ブロックは自動的に修復され、データの新しいコピーが自動的に作成されます。 | ストレージ全体にアクセスできない場合など、まれで回復不可能なエラーの場合、Azure Database for PostgreSQLフレキシブル サーバー インスタンスはスタンバイ レプリカにフェールオーバーしてダウンタイムを短縮します。 詳細については、[HA 概念ページ]/azure/reliability/reliability-postgresql-flexible-server を参照してください。 |
| 論理エラーまたはユーザー エラー | 誤って削除されたテーブルや誤って更新されたデータなどのユーザー エラーから回復するには、 ポイントインタイム リカバリー (PITR) を実行します。 復元操作の実行中に、エラーが発生する直前のカスタム復元ポイントを指定します。 データベース サーバー内のすべてのデータベースではなく、データベースまたは特定のテーブルのサブセットのみを復元する場合は、新しいインスタンスでデータベース サーバーを復元し、 pg_dumpを使用してテーブルをエクスポートしてから、 pg_restore を使用してそれらのテーブルをデータベースに復元できます。 |
すべての変更がスタンバイ レプリカに同期的にレプリケートされるため、これらのユーザー エラーは高可用性によって保護されません。 このようなエラーから復旧するには、ポイントインタイム リストアを実行する必要があります。 |
| 可用性ゾーンの障害 | ゾーン レベルの障害から復旧するには、バックアップを使用してポイントインタイム リストアを実行し、最新の時刻のカスタム復元ポイントを選択して最新のデータを復元します。 新しいAzure Database for PostgreSQLフレキシブル サーバー インスタンスを、影響を受けないものの別のゾーンにデプロイします。 復元にかかる時間は、前回のバックアップと、復旧するトランザクション ログの量によって異なります。 | Azure Database for PostgreSQLフレキシブル サーバー インスタンスは、60 ~ 120 秒以内に自動的にスタンバイ サーバーにフェールオーバーし、データ損失が発生しません。 詳細については、[HA 概念ページ]/azure/reliability/reliability-postgresql-flexible-server を参照してください。 |
| リージョンの障害 | サーバーが geo 冗長バックアップを使用して構成されている場合は、ペアになっているリージョンで geo 復元を実行できます。 Azure、新しいサーバーをプロビジョニングし、このリージョンにコピーされた最後の使用可能なデータに復旧します。 リージョンにまたがる読み取りレプリカも使用できます。 リージョンで障害が発生した場合は、読み取りレプリカをスタンドアロンの読み取り/書き込み可能サーバーに昇格することで、ディザスター リカバリー操作を実行できます。 RPO は、障害発生時に RPO がレプリケーションのラグに近づく可能性がある重大なリージョン障害の場合を除き、最大 5 分 (データ損失が発生する可能性があります) と予想されます。 |
同じプロセス。 |
リージョン障害からの復旧後にデータベースを構成する
- geo リストアまたは geo レプリカを使用して障害から復旧する場合は、通常のアプリケーション機能を再開できるように、新しいサーバーへの接続が適切に構成されていることを確認します。 復元後のタスクに従います。
- 以前に元のサーバーで診断設定を設定した場合は、「Azure Database for PostgreSQLのログの構成とアクセス」の説明に従って、必要に応じてターゲット サーバーで同じ操作を行ってください。
- テレメトリ アラートを設定するには、既存のアラート ルール設定が新しいサーバーにマップされるように更新されていることを確認します。 アラート ルールの詳細については、「 Azure portal を使用して Azure Database for PostgreSQL のメトリックにアラートを設定する」を参照してください。
Important
削除されたサーバーを復元できます。 サーバーを削除する場合は、「削除されたサーバーを 復元 して回復する」のガイダンスに従ってください。 Azure リソース ロックを使用すると、サーバーが誤って削除されるのを防ぐことができます。