複製に関する考慮事項¶

データベースと共有オブジェクト¶

次の制約がデータベースと共有オブジェクトに適用されます。

• オブジェクトは、1つのフェールオーバーグループにのみ存在できます。

• 各グループが 異なる ターゲットアカウントに複製される限り、オブジェクトは複数の複製グループに属することができます。

• オブジェクトは、フェールオーバーグループと複製グループの両方に含めることはできません。

• セカンダリ（レプリカ）オブジェクトをプライマリ複製またはフェールオーバーグループに追加することはできません。

複製できるのはアウトバウンド共有のみです。 インバウンド共有 （プロバイダーからの共有）はサポート されていません。

アカウントオブジェクト¶

アカウントには、データベースまたは共有 以外 のオブジェクトを含む複製またはフェールオーバーグループを1つだけ含めることができる。

セッションポリシーとセカンダリロール¶

詳細については、 セカンダリロールを持つセッションポリシー をご参照ください

ダングリング参照とネットワークポリシー¶

ネットワークポリシーにダングリング参照があると、複製に失敗し、次のエラーメッセージが表示される場合があります。

Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities])

ダングリング参照を回避するには、複製またはフェールオーバーグループに対して CREATE または ALTER コマンドを実行する際、 OBJECT_TYPES リストに次のオブジェクト型を指定します。

• ネットワークポリシーがネットワークルールを使用する場合は、ネットワークルールが作成されたスキーマを含むデータベースを含めます。

• ネットワークポリシーがアカウントに関連付けられている場合は、 OBJECT_TYPES リストに NETWORK POLICIES と ACCOUNT PARAMETERS を含めます。

• ネットワークポリシーがユーザーに関連付けられている場合は、 OBJECT_TYPES リストに NETWORK POLICIES と USERS を含めます。

詳細については、 ネットワークポリシーの複製 をご参照ください。

ダングリング参照とパッケージポリシー¶

アカウントに パッケージポリシー が設定されている場合、アカウントオブジェクトを含む複製グループまたはフェールオーバーグループの更新処理中に、次のダングリング参照エラーが発生します。

003131 (55000): Dangling references in the snapshot. Correct the errors before refreshing again.
The following references are missing (referred entity <- [referring entities]):
POLICY '<policy_db>.<policy_schema>.<packages_policy_name>' <- [ACCOUNT '<account_locator>']

ダングリング参照を回避するには、パッケージポリシーを含むデータベースをターゲットアカウントに複製します。ポリシーを含むデータベースは、同じまたは異なる複製グループまたはフェールオーバーグループに存在できます。

ダングリング参照とシークレット¶

詳細については、 複製とシークレット をご参照ください。

ダングリング参照とストリーム¶

ストリームのダングリング参照により、複製が失敗し、次のエラーメッセージが表示されます。

Primary database: the source object ''<object_name>'' for this stream ''<stream_name>'' is not included in the replication group.
Stream replication does not support replication across databases in different replication groups. Please see Streams Documentation
https://docs.snowflake.com/en/user-guide/account-replication-considerations#replication-and-streams for options.

ダングリング参照エラーを回避するには、

• プライマリデータベースには、ストリームとそのベースオブジェクトの両方が含まれている必要があります。 または、

• ストリームを含むデータベースと、ストリームによって参照されるベースオブジェクトを含むデータベースが、同じ複製グループまたはフェールオーバーグループに含まれている必要があります。

ターゲットアカウントに再作成されたオブジェクト¶

ソースアカウントの既存のオブジェクトが CREATE OR REPLACE ステートメントを使用して置き換えられる場合、既存のオブジェクトはドロップされ、同じ名前の新しいオブジェクトが1つのトランザクションで作成されます。たとえば、既存のテーブル t1 に対して CREATE OR REPLACE ステートメントを実行すると、テーブル t1 がドロップされ、新しいテーブル t1 が作成されます。詳細については、 CREATE TABLE の使用上の注意 をご参照ください。

オブジェクトがターゲットアカウント上で置き換えられる場合、 DROP ステートメントと CREATE ステートメントは更新操作中にアトミックに実行されません。つまり、オブジェクトが新しいオブジェクトとして再作成される間、オブジェクトがターゲットアカウントから一時的に消える可能性があります。

認証、パスワード、セッションポリシー¶

複製グループまたはフェールオーバーグループでポリシー（ALLOWED_DATABASES = policy_db）と USERS を含むデータベースを指定すると、ユーザーの認証、パスワード、セッションポリシーの参照が複製されます。

ポリシーデータベースまたはユーザーがすでにターゲットアカウントに複製されている場合は、ソースアカウントの複製またはフェールオーバーグループを更新して、ポリシーを正常に複製するために必要なデータベースとオブジェクト型を含めます。次に、更新操作を実行して、ターゲットアカウントを更新します。

ユーザーレベルのポリシーが使用されていない場合は、 USERS を複製またはフェールオーバーグループに含める必要はありません。

プライバシーポリシー¶

差分プライバシー に関連するプライバシーポリシーとプライバシー保護されたテーブルおよびビューを複製する場合は、以下を考慮してください。

• プライバシーポリシーがソースアカウントのテーブルまたはビューに割り当てられている場合、そのポリシーをターゲットアカウントに複製する必要があります。

• プライバシー予算に対する累積プライバシー損失は複製されません。

• ターゲットアカウントとソースアカウントにおけるプライバシーの累積損失は別々に追跡されます。

• ターゲットアカウントの管理者は、複製されたプライバシーバジェットを調整できません。プライバシー予算は、ソースアカウントのものと同期されます。

• アナリストがソースアカウントとターゲットアカウントの両方でプライバシー保護されたテーブルまたはビューにアクセスできる場合、プライバシーバジェットの上限に達する前に、2倍のプライバシー損失が発生する可能性があります。

• 列に設定されたプライバシードメインも複製されます。

セカンダリロールを持つセッションポリシー¶

セカンダリロールでセッションポリシーを使用する場合は、ロールを含む同じ複製グループでポリシーデータベースを指定する必要があります。例:

CREATE REPLICATION GROUP myrg
  OBJECT_TYPES = DATABASES, ROLES, USERS
  ALLOWED_DATABASES = session_policy_db
  ALLOWED_ACCOUNTS = myorg.myaccount
  REPLICATION_SCHEDULE = '10 MINUTE';

セカンダリロールを参照するセッションポリシーデータベースを、アカウントレベルのオブジェクトを含む複製グループまたはフェールオーバーグループ（myrg）とは異なる複製グループまたはフェールオーバーグループ（rg2）に指定し、 rg2 を先に複製またはフェールオーバーすると、 ダングリング参照 が発生します。セッションポリシーデータベースを、ロールを含む複製グループまたはフェールオーバーグループに配置するようエラーメッセージが表示されます。この動作は、アカウントまたはユーザーにセッションポリシーが設定されている場合に発生します。

セッションポリシーとアカウントレベルのオブジェクトが異なる複製グループにあり、セッションポリシーがアカウントまたはユーザーに設定されていない場合、ターゲットアカウントをレプリケートしてリフレッシュできます。アカウントレベルのオブジェクトを含む複製グループを最初にリフレッシュしてください。

セカンダリロールおよびロールオブジェクトを含むセッションポリシーをレプリケートまたはフェイルオーバーした後にターゲットアカウントをリフレッシュすると、ターゲットアカウントにソースアカウントのセッションポリシーおよびセカンダリロールの動作が反映されます。

さらに、ターゲットアカウントでデータベースをリフレッシュし、データベースにセカンダリロールを参照するセッションポリシーが含まれている場合、 ALLOWED_SECONDARY_ROLES は常に [ALL] と評価されます。

動的テーブルと複製グループ¶

動的テーブルを含むデータベースは、複製グループを使用して複製できます。依存するベースオブジェクトは、同じ複製グループ内にある必要はありません。

セカンダリオブジェクトは、ターゲットアカウントでは 読み取り専用 です。ターゲットアカウントでセカンダリ複製グループがドロップされると、そのグループに含まれていたデータベースは読み取り/書き込み可能になります。ただし、複製グループに含まれる動的テーブルは、ターゲットアカウントでセカンダリグループがドロップされた後でも、 読み取り専用のまま です。これらの読み取り専用の動的テーブルでは DML または動的テーブルのリフレッシュはできません。

動的テーブル、フェールオーバーグループ、データベース複製¶

動的テーブルを含むデータベースは、フェールオーバーグループを使用して複製できます。依存するベースオブジェクトは、同じフェールオーバーグループに含まれている 必要があります。そうでない場合は、リフレッシュ処理中にダングリング参照が発生し、次のようなエラーメッセージが表示されます。

002749 (55000): SQL execution error: Dynamic table <dt_name> has dependencies that are missing in the replication membership: <dependency_table_name>

動的テーブルがデータベース複製を使用してデータベースに複製されている場合も同様です。動的テーブルが依存するベースオブジェクトは、ダングリング参照エラーを避けるために同じデータベースに含まれている必要があります。

セカンダリダイナミックテーブルは読み取り専用で、更新されません。フェールオーバーが発生し、セカンダリダイナミックテーブルがプライマリダイナミックテーブルに昇格した後、最初の更新は再初期化で、ダイナミックテーブルがデータの増分更新に設定されている場合は、増分更新が続きます。

データ損失の回避¶

フェールオーバー時のデータ損失を防ぐには、上流データソースに正常に挿入された行のデータ保持時間を構成された 複製スケジュール より長くする必要があります。プライマリデータベースのテーブルにデータが挿入され、データがセカンダリデータベースに複製される前にフェールオーバーが発生した場合は、新しく昇格したプライマリデータベースのテーブルに同じデータを挿入する必要があります。以下はシナリオ例です。

1. プライマリデータベース repl_db のテーブル t1 に、Snowpipe StreamingとKafkaコネクタを使用してデータを投入します。

2. プライマリ データベースにある t1 の offsetToken は、チャネル1で100、チャネル2で100です。

3. ターゲットアカウントでリフレッシュ操作は正常に完了します。

4. セカンダリ データベースにある t1 の offsetToken は、チャネル1で100、チャネル2で100です。

5. プライマリデータベースの t1 にさらに行が挿入されます。

6. プライマリ データベースにある t1 の offsetToken は、チャネル1で200、チャネル2で200になります。

7. 追加の行と新しいチャネルオフセットがセカンダリデータベースに複製される前に、フェールオーバーが発生します。

この場合、新しく昇格したプライマリデータベースにあるテーブル t1 の各チャネルで100個のオフセットが欠落しています。欠落データを挿入するには、 Snowpipe Streamingのためのアクティブチャネルを新しく昇格したソースアカウントで再度開く をご参照ください。

要件¶

Snowpipe Streaming複製のサポートには、以下の最小バージョンが必要です。

• Snowflake Ingest SDK バージョン1.1.1以降

• Kafkaコネクタを使用している場合: Kafkaコネクタのバージョン1.9.3以降

上流データソースに正常に挿入された行のデータ保持時間を複製頻度より長くする必要があります。Kafkaコネクタを使用している場合は、 log.retention 構成が十分なバッファで設定されていることを確認してください。

ストアドプロシージャ、 UDFs、およびステージ¶

ストアドプロシージャまたは UDF がステージ内のファイルに依存する場合（例: ステージからアップロードされたPythonコードでストアドプロシージャが定義されている場合）は、ステージとそのファイルをセカンダリデータベースに複製する必要があります。ステージ複製については、 ステージ、パイプ、ロード履歴の複製 をご参照ください。

たとえば、プライマリデータベースに、ステージに格納されているコードをインポートするインラインPython UDF がある場合、 UDF はステージとインポートされたコードがセカンダリデータベースに複製されるまでは機能しません。

ストアドプロシージャ、 UDFs、および外部ネットワークアクセス¶

ストアドプロシージャまたは UDF が 外部ネットワークロケーション へのアクセスに依存している場合は、以下のオブジェクトを複製する必要があります:

• 複製グループまたはフェールオーバーグループの allowed_integration_types リストに EXTERNAL ACCESS INTEGRATIONS が含まれている必要があります。

• ネットワークルールを含むデータベース。

• 外部ネットワークロケーションと認証するための認証情報を格納するシークレットを含むデータベース。

• シークレットオブジェクトがセキュリティ統合を参照する場合は、複製グループまたはフェールオーバーグループの allowed_integration_types リストに SECURITY INTEGRATIONS を含める必要があります。

ストリームでサポートされるソースオブジェクト¶

複製されたストリームは、同じデータベース内のテーブルとビューの変更データを正常に追跡できます。

現在、次のソースオブジェクト型はサポート されていません。

• 外部テーブル

• ストリームデータベースとソースオブジェクトを格納するデータベースの 両方 が同じ 複製グループまたはフェールオーバーグループ に含まれていない限り、データべース内のテーブルまたはビューはストリームデータベースとは分離されています。

• 共有データベースのテーブルまたはビュー（つまり、プロバイダーアカウントから自分のアカウントに共有されるデータベース）

ステージ、パイプ、ロード履歴の複製 を有効にすると、ディレクトリテーブルでのストリームの複製がサポートされます。

サポートされていないソースオブジェクトを含むストリームがプライマリデータベースに含まれている場合は、データベースの複製または更新操作に失敗します。いずれかのストリームのソースオブジェクトがドロップされている場合も、操作に失敗します。

複製されたソースオブジェクトでは、追加のみのストリームはサポートされていません。

データ重複の回避¶

DML 操作が一意性チェックなしでストリームから同じ変更データを複数回書き込むと、データの重複が発生します。これが発生する可能性があるのは、ストリームとストリーム変更データの宛先テーブルが別々のデータベースに格納されており、これらのデータベースが複製されず、同じグループでフェールオーバーされた場合です。

たとえば、ストリーム s からテーブル dt に変更データを定期的に挿入するとします。（この例では、ストリームのソースオブジェクトは重要ではありません。）個別のデータベースには、ストリームと宛先テーブルが格納されます。

1. タイムスタンプ t1 で、ストリーム s のソーステーブルに行が挿入され、新しいテーブルバージョンが作成されます。ストリームは、このテーブルバージョンのオフセットを格納します。

2. タイムスタンプ t2 で、ストリームを格納するセカンダリデータベースが更新されます。複製されたストリーム s にオフセットが格納されるようになりました。

3. タイムスタンプ t3 で、ストリーム s の変更データがテーブル dt に挿入されます。

4. タイムスタンプ t4 で、ストリーム s を格納するセカンダリデータベースがフェールオーバーされます。

5. タイムスタンプ t5 で、ストリーム s の変更データがテーブル dt に再度挿入されます。

この状況を回避するには、ストリームとその宛先テーブルを格納するデータベースを一緒に複製してフェールオーバーします。

タスク WHEN 句でのストリーム参照¶

WHEN boolean_expr 句でストリームを参照する、複製されたタスクを実行するときの予期しない動作を回避するには、次のいずれかを実行するようにお勧めします。

• タスクとストリームを同じデータベースに作成する。 または

• ストリームを参照するタスクとは別のデータベースにストリームが格納されている場合は、両方のデータベースを同じ フェールオーバーグループ に含める。

タスクが別のデータベースのストリームを参照し、両方のデータベースが同じフェールオーバーグループに含まれていない場合、タスクを含むデータベースは、ストリームを含むデータベースなしでフェールオーバーされる可能性があります。このシナリオでは、フェールオーバーされたデータベースでタスクが再開され、タスクを実行しようとするとエラーが記録され、参照されたストリームを検出することができません。この問題は、ストリームを含むデータベースをフェールオーバーするか、タスクを含むフェールオーバーされたデータベースと同じアカウント内で、データベースとストリームを再作成することにより解決できます。

ストリームの陳腐化¶

プライマリデータベースのストリームが 古くなった 場合、セカンダリデータベースの複製されたストリームも古くなり、クエリを実行したり、その変更データを消費したりできなくなります。この問題を解決するには、プライマリデータベースでストリームを再作成します （CREATE OR REPLACE STREAM を使用）。セカンダリデータベースが更新されると、複製されたストリームは再び読み取り可能になります。

再作成されたストリームのオフセットは、デフォルトで現在のテーブルバージョンになることに注意してください。Time Travelを使用して、以前のテーブルバージョンをポイントするストリームを再作成できます。ただし、複製されたストリームは読み取れないままになります。詳細については、 ストリーム複製およびTime Travel （このトピック内）をご参照ください。

ストリーム複製およびTime Travel¶

プライマリデータベースがフェールオーバーされた後、データベースのストリームが Time Travel を使用して、ソースオブジェクトの テーブルバージョン を最後の更新タイムスタンプより前の時点から読み取ると、複製されたストリームをクエリしたり、変更データを消費したりすることができません。同様に、 SELECT ステートメントの CHANGES 句を使用して、最後の更新タイムスタンプより前の時点からソースオブジェクトの変更データをクエリすると、エラーをともない失敗します。

これは、更新操作によってテーブル履歴が1つのテーブルバージョンに折りたたまれるためです。更新操作のタイムスタンプより前に作成された反復テーブルバージョンは、複製されたソースオブジェクトのテーブル履歴に保存されません。

次の例を考えてみましょう：

1. テーブル t1 がプライマリデータベースに作成され、変更追跡が有効になっています（テーブルバージョン tv0）。後続の DML トランザクションは、テーブルバージョン tv1 および tv2 を作成します。

2. テーブル t1 を含むセカンダリデータベースが更新されます。この複製されたテーブルのテーブルバージョンは tv2 です。ただし、テーブル履歴は複製されません。

3. Time Travelを使用して、オフセットをテーブルバージョン tv1 に設定したプライマリデータベースにストリームが作成されます。

4. セカンダリデータベースがフェールオーバーされ、プライマリデータベースになります。

5. テーブルバージョン tv1 がテーブル履歴にないため、ストリーム s1 をクエリするとエラーが返されます。

テーブル t1 の後続の DML トランザクションがテーブルバージョンを tv3 に反復すると、ストリーム s1 のオフセットが進むことに注意してください。ストリームは再び読み取り可能になります。

データ損失の回避¶

セカンダリデータベースの最新の更新操作がフェールオーバー操作の前に完了していないと、データが失われる可能性があります。リスクを最小限に抑えるために、セカンダリデータベースを頻繁に更新することをお勧めします。

複製のシナリオ¶

次のテーブルでは、さまざまなタスクシナリオについて説明し、タスクが複製されるかどうかを示します。特に断りのない限り、シナリオはスタンドアロンタスクと タスクグラフ 内のタスクの両方に関係します。

複製されたタスクの再開または一時停止の状態¶

次の条件がすべて満たされている場合、タスクは再開された状態でセカンダリデータベースに複製されます。

• スタンドアロンまたはルートタスクは、複製または更新操作が開始されると、操作が完了するまで、プライマリデータベースで再開された状態になります。タスクがこの期間の一部だけ再開状態にある場合でも、再開状態で複製される可能性があります。

  子タスクは、タスクの最新バージョンで再開された状態にあります。

• 親データベースは、同じまたは異なる 複製グループまたはフェールオーバーグループ 内のロールオブジェクトとともに、ターゲットアカウントに複製されました。

  ロールとデータベースが複製された後、 ALTER REPLICATION GROUP ... REFRESH または ALTER FAILOVER GROUP ... REFRESH をそれぞれ実行して、ターゲットアカウントのオブジェクトを更新する必要があります。 ALTER DATABASE ... REFRESH を実行してデータベースを更新すると、データベース内のタスクの状態が一時停止に変更されます。

  複製または更新操作には、最新のテーブルバージョンがコミットされた時点で最新であったタスクの権限付与が含まれます。詳細については、 複製されたタスクと権限付与 （このトピック内）をご参照ください。

これらの条件が満たされない場合、タスクは一時停止状態でセカンダリデータベースに複製されます。

複製されたタスクと権限付与¶

親データベースが、同じまたは異なる複製グループやフェールオーバーグループ内のロールオブジェクトと共にターゲットアカウントに複製される場合は、データベース内のタスクに付与された権限も同様に複製されます。

次のロジックにより、複製または更新操作で複製されるタスク権限が決定されます。

• 現在のタスク所有者（つまり、タスクに対する OWNERSHIP 権限を持つロール）が、最後にタスクが再開されたときと同じロールである場合は、タスクに対する現在のすべての権限がセカンダリデータベースに複製されます。

• 現在のタスクの所有者が、最後にタスクが再開されたときと同じロール ではない 場合は、タスクバージョンで所有者のロールに付与された OWNERSHIP 権限のみがセカンダリデータベースに複製されます。

• 現在のタスク所有者ロールが使用できない場合（例: 子タスクがドロップされたが、新しいバージョンのタスクグラフがまだコミットされていない場合）は、タスクバージョンで所有者ロールに付与された OWNERSHIP 権限のみがセカンダリデータベースに複製されます。

フェールオーバー後にタスクが実行される¶

セカンダリフェールオーバーグループがプライマリグループとして機能するように昇格された後、フェールオーバーグループ内のデータベースで再開されたタスクは、段階的にスケジュールされます。再開されたすべてのスタンドアロンタスクとタスクグラフの通常のスケジュールを復元するために必要な時間は、データベース内にある再開されたタスクの数に応じて異なります。