複製に関する考慮事項¶

データベースおよび共有オブジェクト¶

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

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

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

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

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

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

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

ストリーム¶

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

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.

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

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

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

ネットワークポリシー¶

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

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 リストに USERS を含めます。

詳細については、 複数のアカウントにわたるセキュリティ統合およびネットワークポリシーの複製 トピック内の ネットワークポリシー をご参照ください。

パスワードおよびセッションポリシー¶

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

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

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

プライマリデータベースの外部テーブル¶

現在、プライマリデータベースの外部テーブルが原因で、複製または更新操作は失敗し、次のエラーメッセージが表示されます。

003906 (55000): SQL execution error:
Primary database contains an external table '<database_name>'. Replication of a database with external table is not supported

このエラーを回避するには、複製されていない別のデータベースに外部テーブルを移動します。または、データベースを別のアカウントに移行する場合は、プライマリデータベースのクローンを作成し、クローンから外部テーブルを削除してから、クローンデータベースを複製することができます。ターゲットアカウントでセカンダリデータベースを昇格した後、データベースに外部テーブルを再作成する必要があります。

セカンダリデータベースの外部テーブル¶

外部テーブルが以前プライマリデータベースであり、その間に外部テーブルが作成された場合、外部テーブルはセカンダリデータベースに存在できます。別のデータベースが指定されたプライマリデータベースに昇格すると、そのデータベースはセカンダリデータベースになります。現在、セカンダリデータベースの外部テーブルが原因で、更新操作は失敗し、次のエラーが発生します。

003958 (55000): SQL execution error:
Secondary database contains an external table '<table_name>'. Replication of a database with external table is not supported.

このエラーを回避するには、複製されたセカンダリデータベースではない別のデータベースに外部テーブルを移動します。

データ損失の回避¶

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

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以降

制限事項¶

Snowpipe Streamingによって投入されたSnowflakeテーブルでストリームを使用した複製が有効になっていません。Snowpipe Streamingによって投入されたSnowflakeテーブルでストリームを複製する場合は、 Snowflakeサポート にお問い合わせください。

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

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

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

• ディレクトリテーブル

• 外部テーブル

• ストリームデータベースとは別のデータベース内にあるテーブルまたはビュー。

  この設計は、ストリームデータベースとソースオブジェクトを格納するデータベースの両方が同じ 複製グループまたはフェールオーバーグループ に含まれている 場合 に機能します。

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

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

データ重複の回避¶

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 のオフセットが進むことに注意してください。ストリームは再び読み取り可能になります。

データ損失の回避¶

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

複製のシナリオ¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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