ビジネス継続性と障害復旧におけるリストのサポート¶
プロバイダーは、リストとその依存関係（共有やデータベースなど）を:doc:`アカウント複製およびフェールオーバーグループ</user-guide/account-replication-intro>`に含めることができます。フェールオーバーグループを使用すると、サービスの低下または停止が発生した場合、リストはデータ複製と障害復旧のフェールオーバーグループに依存します。
注釈
規約¶
プライマリリスト：プライマリフェールオーバーグループ内のリスト
セカンダリリスト：セカンダリフェールオーバーグループ内のリスト
ビジネス継続性と障害復旧の必要性を理解する¶
プライマリリージョンで障害が発生した場合、プロバイダーにとってビジネス継続性と障害復旧（BCDR）は非常に重要になります。
プロバイダーは、障害発生時において、自社のデータ製品のサポートを継続し、中断を最小限に抑えなければなりません。
プロバイダーは、金銭的ペナルティを回避するため、RTO（目標復旧時間）およびRPO（目標復旧地点）に関するサービスレベル契約（SLAs）を遵守しなければなりません。
プロバイダーは、障害が発生した場合に備え、セカンダリリージョンにデータのレプリカを保持しなければなりません。
フェールオーバーと復旧の手動構成¶
フェールオーバーグループにリストを追加しないプロバイダーは、復旧時間が長くなり、古い情報をコンシューマーに提供することになります。BCDRがない場合、プロバイダーはフェールオーバー後にセカンダリリージョンでリストを再作成しなければなりません。その後、コンシューマーは新しいリストURLsに再マウントしなければなりません。この手動複製はETLパイプラインやアプリケーションに大規模な中断を引き起こし、結果としてコンシューマーのダウンタイムが長引き、プロバイダーのデータ転送コストが増加します。
自動フェールオーバーと復旧¶
リストのBCDRにより、企業の対応能力が向上し、障害による中断が低減されます。
リストのBCDRにより、プロバイダーはフェールオーバー後にリストを再作成する必要がなくなります。
新しいプライマリリージョンから安全な共有領域（SSA）アカウントへの再複製は行われません。増分変更のみがSSAアカウントに複製されるため、データ転送コストが節約できます。
リストのBCDRサポートにより、フェールオーバー後には以下のようになります。
コンシューマーはダウンタイムなしで、プロバイダーのデータに引き続きアクセスできます。
プロバイダーは、新しいプライマリリージョンから新しいコンシューマーリージョンにフルフィルメントを実行できます。
リストが新しいプライマリから更新されるため、プロバイダーは引き続きコンシューマーのデータ鮮度要件を満たすことができます。
リストのBCDRワークフロー¶
リストの典型的なBCDRワークフローは、以下のとおりです。
リージョンで障害が発生し、プライマリリージョンが影響を受けます。
プライマリリージョンがダウンしている間、コンシューマーリージョンのリストは更新できません。その結果、コンシューマーは古いデータで運用することになります。
データ復旧管理者が、組織のランブックを始動させます。
管理者は、セカンダリリージョンへのフェールオーバーの承認を得ます。
このセカンダリリージョンが新しいプライマリリージョンになります。
フェールオーバーグループ内のレプリカが、すべてのオブジェクトの新しい情報ソースになります。
管理者は、外部テーブルやETLパイプラインなどのデータソースからの最新情報で新しいプライマリを更新します。
管理者は、新しいプライマリ内のオブジェクトのスナップショットを取得し、最新のデータが保持されていることを確認します。
管理者は、新しいプライマリリージョンを監査して、本番稼働の準備ができているかどうかを確認します。
フェールオーバーが完了すると、新しいプライマリからの次の更新間隔で自動フルフィルメントが再び機能し始めます。
注釈
管理者は、:doc:`/sql-reference/sql/show-listings-in-failover-group`コマンドを使用して、リストの本番稼働の準備ができていることを確認できます。
BCDRの選択基準¶
以下の場合、BCDRはサポートされません。
リストがドラフト状態である。
リストがステージを基盤としている。
リストが有料リストである。
リストの:doc:`自動フルフィルメント</collaboration/provider-listings-auto-fulfillment>`が有効になっていない。
リストが|native-app|のリストである。
動作、考慮事項、制約¶
リストのBCDRの動作、考慮事項、制約を理解するには、以下のセクションを確認してください。
動作¶
セカンダリフェールオーバーグループが削除されると、そのフェールオーバーグループ内のセカンダリリストは自動的に削除されます。
考慮事項¶
外部管理のIcebergテーブルは、自動フルフィルメントではサポートされていますが、現時点でフェールオーバーではサポートされていません。管理対象のIcebergテーブルのフェールオーバーは、現在:doc:`パブリックプレビュー</user-guide/tables-iceberg-replication>`段階です。
一部の機能は、データベースレベルのフェールオーバーではサポートされていなくても、リストレベルのフェールオーバーではサポートされている場合があります。サポートされていないオブジェクトは、複製中に無視されます。
制約¶
リストのBCDRを構成する前に、次の制約を確実に理解しておいてください。
完全部分集合制約（オールオアナッシングルール）¶
フェールオーバーグループにオブジェクトを追加する際、自動フルフィルメントが有効になっているリストによって参照されているオブジェクトがある場合は、その同じリストによって参照されるすべてのオブジェクトを同じフェールオーバーグループに含めなければなりません。
フェールオーバーグループからオブジェクトを削除する際、自動フルフィルメントが有効になっているリストによって参照されているオブジェクトがある場合は、その同じリストによって参照されるすべてのオブジェクトをまとめて削除しなければなりません。
フェールオーバーグループのオブジェクト型の要件¶
自動フルフィルメントが有効になっているリストによって参照されているデータベースまたは共有がフェールオーバーグループに含まれる場合は、そのフェールオーバーグループの:code:`OBJECT_TYPES`パラメーターに:code:`LISTINGS`を含めなければなりません。例:
リストの自動フルフィルメント設定に関する制約¶
リストで自動フルフィルメントを有効にする、または自動フルフィルメントが有効になっているリストを公開する前に、リストの依存関係（共有やデータベースなど）すべてを、:code:`LISTINGS`オブジェクト型を含むフェールオーバーグループで構成しなければなりません。
自動フルフィルメントは、セカンダリアカウントで手動で有効にしなければなりません（まだ有効にしていない場合）。詳細については、 SYSTEM$ENABLE_GLOBAL_DATA_SHARING_FOR_ACCOUNT をご参照ください。
リストで:doc:` REFERENCE_USAGE </sql-reference/sql/grant-privilege-share>`権限が使用される場合、リストに直接関連していないオブジェクトでも、完全部分集合制約における部分集合の一部としてカウントされる場合があります。
内部Marketplaceのリストに関する制約¶
内部Marketplaceのリスト（組織リスト）には、以下の制約が適用されます。
リクエスト承認ワークフロー¶
コンシューマーが未承認の組織リストのリクエストを送信し、システムがセカンダリデプロイメントにフェールオーバーした場合、レプリカプロバイダーにはそのコンシューマーのリクエストが表示されません。これは、リクエストが最初に行われたデプロイメントに紐付いているためです。コンシューマーはリストを再リクエストする必要があります。
プライマリリージョンにフェールバックした後にリストの公開を解除しようとすると、次のシナリオでは失敗します。
コンシューマーが、プライマリリージョンとそのフェールオーバーリージョンにあるリストをリクエストしており、
そのコンシューマーがリストを再リクエストし、セカンダリリージョンにある間に承認された場合。
この失敗は、元の保留中のリクエストが残っているために発生します。公開解除を成功させるには、プロバイダーが元のリクエストを明示的に拒否してから、公開解除操作を再試行しなければなりません。
データディクショナリ¶
特集オブジェクトは、フェールオーバーの複製プロセスの対象ではありません。その結果、プライマリインスタンスで選択された特集オブジェクトは、フェールオーバー後のセカンダリインスタンスに反映されません。プロバイダーは、フェールオーバー後にこれらのオブジェクトを手動でリセットしなければなりません。プロバイダーが特集オブジェクトをリセットしない場合、コンシューマーには（新しいテーブルを追加したとしても）古いデータディクショナリが表示されます。これは、バックグラウンドジョブがこのリストをスキップするためです。特集オブジェクトが設定された後、バックグラウンドジョブはこのリストをピックアップします。
システムがレプリカとして動作している間に特集オブジェクトに変更が加えられた場合、それらの変更はフェールバック後に元のプライマリインスタンスに再同期されません。
データプレビュー¶
データプレビュー情報は、セカンダリリージョンに複製されません。その結果、フェールオーバー後、コンシューマーにはデータプレビューファイルが表示されません。セカンダリリージョンにおいて、プロバイダーはデータプレビューファイルを再生成しなければなりません。
データディクショナリと同様に、フェールオーバー状態の間にデータプレビューに加えられた変更は、フェールバック後に元のプライマリに再同期されません。プロバイダーは、フェールバック後に元のプライマリでデータプレビュー情報をリセットできます。
組織プロファイル¶
プライマリプロバイダーとセカンダリプロバイダーの両方が、リストを公開できる:doc:`プロファイル</user-guide/collaboration/organization-profiles/org-profiles-create-manage>`を使用しなければなりません。
プロファイル複製に関する制約¶
プロファイルがフェールオーバーグループによって複製されない場合、セカンダリアカウントのリストはプロファイルが紐付いていない状態で引き続き機能します。
プロファイルがフェールオーバーグループによって複製されない場合、元のプライマリアカウントのプロファイルは、フェールオーバーやフェールバックの更新後も、変更されずに維持されます。
セカンダリアカウントのプロファイルは、フェールオーバーが発生するまで読み取り専用です。フェールオーバー後、新しいプライマリアカウントでプロファイルを作成、変更、または削除できます。
セカンダリアカウントに既存のローカルプロファイルがある場合、潜在的なデータ損失を防ぐため、初回のフェールオーバーグループの更新は意図的に失敗します。続行するには、クエリ結果のメッセージに表示される手順に従ってください。
プロファイルの承認リクエストは複製されません。元のプライマリアカウントに保留中の承認リクエストがある場合、フェールオーバー後、新しいプライマリアカウントで承認を再リクエストできます。
読み取り専用のセカンダリリストに関する制約¶
セカンダリリストは直接変更できません。ALTERおよびDROPなどのすべての書き込み操作は、プライマリリストに対して実行しなければなりません。