データベースの複製の考慮事項¶
このトピックでは、セカンダリデータベース内における特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。
このトピックの内容:
複製と自動クラスタリング¶
プライマリデータベースでは、Snowflakeは 自動クラスタリング を使用してクラスター化されたテーブルを監視し、必要に応じてそれらを再クラスター化します。更新操作の一部として、クラスター化されたテーブルは、テーブルのマイクロパーティションの現在の並べ替えを使用してセカンダリデータベースに複製されます。そのため、セカンダリデータベース内のクラスター化されたテーブルで再クラスタリングが再度実行されることは ありません 。これは冗長です。
セカンダリデータベースにクラスター化されたテーブルが含まれており、データベースがプライマリデータベースになると、Snowflakeはこのデータベースのテーブルの自動クラスタリングを開始すると同時に、以前のプライマリデータベースのクラスター化テーブルの監視を一時停止します。
マテリアライズドビューの自動クラスタリングの詳細については、このトピックの 複製とマテリアライズドビュー をご参照ください。
複製とマテリアライズドビュー¶
プライマリデータベースでは、Snowflakeはマテリアライズドビューの自動バックグラウンドメンテナンスを実行します。ベーステーブルが変更されると、テーブルで定義されているすべてのマテリアライズドビューは、Snowflakeが提供する計算リソースを使用するバックグラウンドサービスによって更新されます。さらに、マテリアライズドビューに対して自動クラスタリングが有効になっている場合、ビューはプライマリデータベースで必要に応じてモニターおよび再クラスター化されます。
リフレッシュ操作は、マテリアライズドビューの 定義 をセカンダリデータベースに複製します。マテリアライズドビューの データ は複製されません。セカンダリデータベースのマテリアライズドビューの自動バックグラウンドメンテナンスは、デフォルトで有効になっています。プライマリデータベースにあるマテリアライズドビューの自動クラスタリングが有効になっている場合は、セカンダリデータベースにあるマテリアライズドビューの自動モニタリングと再クラスタリングも有効になります。
ダングリングリファレンス (このトピック内)もご参照ください。
注釈
マテリアライズドビューの自動バックグラウンド同期の料金は、セカンダリデータベースを含む各アカウントに請求されます。
複製と外部テーブル¶
プライマリデータベースの外部テーブル¶
現在、プライマリデータベースの外部テーブルが原因で、複製または更新操作は失敗し、次のエラーメッセージが表示されます。
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.
この制限を回避するには、複製されたセカンダリデータベースではない別のデータベースに外部テーブルを移動するようにお勧めします。
複製およびセキュリティポリシー¶
- ポリシー
マスキングポリシーと行アクセスポリシーのオブジェクト、またその割り当ては、データベース複製と複製グループを使用して複製することができます。
データベース複製 の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。
プライマリデータベースはEnterprise(またはそれ以上)のアカウントにあり、ポリシーを含んでいるが、複製を承認された1つ以上のアカウントが下位エディションにある。
プライマリデータベースに含まれるオブジェクトには、別のデータベースにあるタグへの ダングリングリファレンス がある。
複製グループ で複数のデータベースを複製すると、データベース複製のダングリングリファレンス動作を回避できます。
注釈
フェールオーバーまたはフェールバックのアクションを使用している場合、SnowflakeアカウントはBusiness Critical Editionかそれ以上である必要があります。
詳細については、 データベース複製とフェールオーバー/フェールバック をご参照ください。
- タグベースのマスキングポリシー
タグが以前にプライマリデータベースからセカンダリデータベースにデータベース複製を使用して 複製され、プライマリデータベース内のスキーマに格納されているタグにマスキングポリシーが割り当てられている場合は、セカンダリデータベース上での更新操作に関する次の点に注意してください。
タグベースのマスキングポリシーがセカンダリアカウントのテーブル、ビュー、または列に割り当てられている場合は、更新操作が機能します。
複製されたタグが、セカンダリアカウントのスキーマまたはデータベースに割り当てられているか、セカンダリアカウント自体に割り当てられている場合は、これらのオブジェクトの更新操作は失敗します。
このポリシーの詳細については、 タグベースのマスキングポリシー をご参照ください。
- ネットワークポリシー
詳細については、 ネットワークポリシー複製 をご参照ください。
- パスワードおよびセッションポリシー
これらのオブジェクトは、データベース複製と複製グループを使用して複製できます。
データベース複製の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。
プライマリデータベースはEnterprise(またはそれ以上)のアカウントにあり、ポリシーを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがある。
プライマリデータベースに含まれるこれらのオブジェクトのいずれかが、同じアカウントのユーザーに関連付けられている。この場合、Snowflakeは複製操作に失敗します。
ユーザーへの参照が原因でデータベースの複製操作に失敗するのを避けるには、代わりに 複製グループ を使用します。
詳細については、 複製およびセキュリティポリシー (アカウント複製のトピック内)をご参照ください。
複製およびストリーム¶
このセクションでは、 データベース複製とフェールオーバー/フェールバック または アカウント複製およびフェールオーバー/フェールバック でストリームを複製する際の推奨される方法と潜在的な懸念事項について説明します。
ストリームでサポートされるソースオブジェクト¶
複製されたストリームは、同じデータベース内のテーブルとビューの変更データを正常に追跡できます。
現在、次のソースオブジェクト型はサポート されていません。
ディレクトリテーブル
外部テーブル
ストリームデータベースとは別のデータベース内にあるテーブルまたはビュー。
この設計は、ストリームデータベースとソースオブジェクトを格納するデータベースの両方が同じ 複製グループまたはフェールオーバーグループ に含まれている 場合 に機能します。
共有データベースのテーブルまたはビュー(つまり、プロバイダーアカウントから自分のアカウントに共有されるデータベース)
サポートされていないソースオブジェクトを含むストリームがプライマリデータベースに含まれている場合は、データベースの複製または更新操作に失敗します。いずれかのストリームのソースオブジェクトがドロップされている場合も、操作に失敗します。
データ重複の回避¶
注釈
このセクションで説明するシナリオに加えて、セカンダリデータベースのストリームは、更新操作で最初に含まれるときに、重複する行を返す可能性があります。この場合の 重複行 は、複数の METADATA$ACTION 列値を持つ単一の行を指します。
最初の更新操作の後、セカンダリデータベースでこの特定の問題が発生することはありません。
DML 操作が一意性チェックなしでストリームから同じ変更データを複数回書き込むと、データの重複が発生します。これが発生する可能性があるのは、ストリームとストリーム変更データの宛先テーブルが別々のデータベースに格納されており、これらのデータベースが複製されず、同じグループでフェールオーバーされた場合です。
たとえば、ストリーム s
からテーブル dt
に変更データを定期的に挿入するとします。(この例では、ストリームのソースオブジェクトは重要ではありません。)個別のデータベースには、ストリームと宛先テーブルが格納されます。
タイムスタンプ
t1
で、ストリームs
のソーステーブルに行が挿入され、新しいテーブルバージョンが作成されます。ストリームは、このテーブルバージョンのオフセットを格納します。タイムスタンプ
t2
で、ストリームを格納するセカンダリデータベースが更新されます。複製されたストリームs
にオフセットが格納されるようになりました。タイムスタンプ
t3
で、ストリームs
の変更データがテーブルdt
に挿入されます。タイムスタンプ
t4
で、ストリームs
を格納するセカンダリデータベースがフェールオーバーされます。タイムスタンプ
t5
で、ストリームs
の変更データがテーブルdt
に再度挿入されます。
この状況を回避するには、ストリームとその宛先テーブルを格納するデータベースを一緒に複製してフェールオーバーします。
タスク WHEN 句でのストリーム参照¶
WHEN boolean_expr
句でストリームを参照する、複製されたタスクを実行するときの予期しない動作を回避するには、次のいずれかを実行するようにお勧めします。
タスクとストリームを同じデータベースに作成する。 または
ストリームを参照するタスクとは別のデータベースにストリームが格納されている場合は、両方のデータベースを同じ フェールオーバーグループ に含める。
タスクが別のデータベースのストリームを参照し、両方のデータベースが同じフェールオーバーグループに含まれていない場合、タスクを含むデータベースは、ストリームを含むデータベースなしでフェールオーバーされる可能性があります。このシナリオでは、フェールオーバーされたデータベースでタスクが再開され、タスクを実行しようとするとエラーが記録され、参照されたストリームを検出することができません。この問題は、ストリームを含むデータベースをフェールオーバーするか、タスクを含むフェールオーバーされたデータベースと同じアカウント内で、データベースとストリームを再作成することにより解決できます。
ストリームの陳腐化¶
プライマリデータベースのストリームが 古くなった 場合、セカンダリデータベースの複製されたストリームも古くなり、クエリを実行したり、その変更データを消費したりできなくなります。この問題を解決するには、プライマリデータベースでストリームを再作成します (CREATE OR REPLACE STREAM を使用)。セカンダリデータベースが更新されると、複製されたストリームは再び読み取り可能になります。
再作成されたストリームのオフセットは、デフォルトで現在のテーブルバージョンになることに注意してください。Time Travelを使用して、以前のテーブルバージョンをポイントするストリームを再作成できます。ただし、複製されたストリームは読み取れないままになります。詳細については、 ストリーム複製およびTime Travel (このトピック内)をご参照ください。
ストリーム複製およびTime Travel¶
プライマリデータベースがフェールオーバーされた後、データベースのストリームが Time Travel を使用して、ソースオブジェクトの テーブルバージョン を最後の更新タイムスタンプより前の時点から読み取ると、複製されたストリームをクエリしたり、変更データを消費したりすることができません。同様に、 SELECT ステートメントの CHANGES 句を使用して、最後の更新タイムスタンプより前の時点からソースオブジェクトの変更データをクエリすると、エラーをともない失敗します。
これは、更新操作によってテーブル履歴が1つのテーブルバージョンに折りたたまれるためです。更新操作のタイムスタンプより前に作成された反復テーブルバージョンは、複製されたソースオブジェクトのテーブル履歴に保存されません。
次の例を考えてみましょう:
テーブル
t1
がプライマリデータベースに作成され、変更追跡が有効になっています(テーブルバージョンtv0
)。後続の DML トランザクションは、テーブルバージョンt1
およびt2
を作成します。テーブル
t1
を含むセカンダリデータベースが更新されます。この複製されたテーブルのテーブルバージョンはt2
です。ただし、テーブル履歴は複製されません。Time Travelを使用して、オフセットをテーブルバージョン
tv1
に設定したプライマリデータベースにストリームが作成されます。セカンダリデータベースがフェールオーバーされ、プライマリデータベースになります。
テーブルバージョン
tv1
がテーブル履歴にないため、ストリームs1
をクエリするとエラーが返されます。
テーブル t1
の後続の DML トランザクションがテーブルバージョンを tv3
に反復すると、ストリーム s1
のオフセットが進むことに注意してください。ストリームは再び読み取り可能になります。
データ損失の回避¶
フェールオーバー操作の前にセカンダリデータベースの最新の更新操作が完了すると、データが失われる可能性があります。リスクを最小限に抑えるために、セカンダリデータベースを頻繁に更新することをお勧めします。
ストリーム複製を有効にする¶
ストリーム複製のプレビューを有効にするには、 ストリームとタスクの複製のプレビューを有効にする --- オプション をご参照ください。
複製およびタグ¶
タグとその割り当ては、データベース複製と複製グループを使用して複製できます。
ソースアカウントのタグ割り当ては、ターゲットアカウントに引き継がれます。ただし、複製が発生した後に、ソースアカウントのタグ割り当てをターゲットアカウントで変更することはできません。たとえば、複製されたデータベースにタグを設定することは許可されていません。複製の更新操作では、Snowflakeはターゲットアカウントのタグ割り当てを更新して、ソースアカウントのタグ割り当てと一致させることに注意してください。
データベース複製 の場合は、次のいずれかの条件に該当すると、複製操作に失敗します。
プライマリデータベースはEnterprise(またはそれ以上)のアカウントにあり、タグを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがあります。
プライマリデータベースに含まれるオブジェクトには、別のデータベースにあるタグへの ダングリングリファレンス がある。
複製グループ を使用すると、データベース複製でのダングリング参照の動作と、アカウントレベルのオブジェクトでのダングリング参照を回避できます。複製グループで次が指定されていることを確認します。
ALLOWED_DATABASES
プロパティのタグを含むデータベース。OBJECT_TYPES
プロパティにタグを持つその他のアカウントレベルのオブジェクト(例:ROLES
、WAREHOUSES
)。詳細については、 CREATE REPLICATION GROUP および CREATE FAILOVER GROUP をご参照ください。
注釈
データベース複製または複製グループを使用するときに、
フェールオーバーまたはフェールバックのアクションを使用している場合、SnowflakeアカウントはBusiness Critical Editionかそれ以上である必要があります。
詳細については、 データベース複製とフェールオーバー/フェールバック をご参照ください。
ALTER DATABASE ステートメントか、 CREATE REPLICATION GROUP または ALTER REPLICATION GROUP ステートメントのある複製グループでデータベース複製用の
IGNORE EDITION CHECK
句を指定すると、ターゲットアカウントが Business Critical よりも下位のエディションの場合にタグの複製が発生します。詳細については、これらのコマンドにある句の説明をご参照ください。
複製およびタスク¶
このセクションでは、 データベース複製とフェールオーバー/フェールバック または アカウント複製およびフェールオーバー/フェールバック におけるタスク複製について説明します。
複製のシナリオ¶
次のテーブルでは、さまざまなタスクシナリオについて説明し、タスクが複製されるかどうかを示します。特に断りのない限り、シナリオはスタンドアロンタスクと DAG 内のタスクの両方に関係します。
シナリオ |
複製 |
メモ |
---|---|---|
タスクが作成され、手動で(EXECUTE TASK を使用して)再開または実行されました。タスクを再開または実行すると、タスクの初期バージョンが作成されます。 |
✔ |
|
タスクは作成されましたが、再開も実行もされませんでした。 |
❌ |
|
タスクは再作成されました(CREATE OR REPLACE TASK を使用)が、再開も実行もされませんでした。 |
✔ |
タスクが再作成される 前 の最新バージョンが複製されます。 タスクを再開または手動で実行すると、新しいバージョンがコミットされます。データベースが再度複製されると、新しいバージョンまたは最新のバージョンがセカンダリデータベースに複製されます。 |
タスクが作成され、再開または実行され、その後に変更(ALTER TASK を使用)されましたが、改めて再開または実行されませんでした。 |
✔ |
タスクを再開または手動で実行すると、タスクパラメーターへの変更を含む新しいバージョンがコミットされます。新しい変更はコミットされていないため、タスクが一時停止および変更される前の最新バージョンが複製されます。 変更されたタスクが保持期間(現在30日間)内に再開されない場合は、タスクの最新バージョンがドロップされることに注意してください。この期間が過ぎると、タスクは改めて再開されない限り、セカンダリデータベースに複製されません。 |
スタンドアロンタスクが作成され、再開または実行されましたが、その後ドロップされました。 |
❌ |
|
DAG のルートタスクが作成され、再開または実行されましたが、その後一時停止され、ドロップされました。 |
❌ |
DAG 全体がセカンダリデータベースに複製されるわけではありません。 |
DAG 内の子タスクが作成され、再開または実行されますが、その後一時停止され、ドロップされます。 |
✔ |
DAG の最新バージョン(タスクが一時停止され、ドロップされる前)がセカンダリデータベースに複製されます。 |
複製されたタスクの再開または一時停止の状態¶
次の条件がすべて満たされている場合、タスクは再開された状態でセカンダリデータベースに複製されます。
スタンドアロンまたはルートタスクは、複製または更新操作が開始されると、操作が完了するまで、プライマリデータベースで再開された状態になります。タスクがこの期間の一部だけ再開状態にある場合でも、再開状態で複製される可能性があります。
子タスクは、タスクの最新バージョンで再開された状態にあります。
親データベースは、同じまたは異なる 複製グループまたはフェールオーバーグループ 内のロールオブジェクトとともに、ターゲットアカウントに複製されました。
ロールとデータベースが複製された後、 ALTER REPLICATION GROUP ... REFRESH または ALTER FAILOVER GROUP ... REFRESH をそれぞれ実行して、ターゲットアカウントのオブジェクトを更新する必要があります。 ALTER DATABASE ... REFRESH を実行してデータベースを更新すると、データベース内のタスクの状態が一時停止に変更されます。
複製または更新操作には、最新のテーブルバージョンがコミットされた時点で最新であったタスクの権限付与が含まれます。詳細については、 複製されたタスクと権限付与 (このトピック内)をご参照ください。
これらの条件が満たされない場合、タスクは一時停止状態でセカンダリデータベースに複製されます。
注釈
state
に関係なく、すべてのセカンダリタスクは 中断 されます。詳細については、 フェールオーバー後にタスクが実行される をご参照ください。
複製されたタスクと権限付与¶
親データベースが、同じまたは異なる複製グループやフェールオーバーグループ内のロールオブジェクトと共にターゲットアカウントに複製される場合は、データベース内のタスクに付与された権限も同様に複製されます。
次のロジックにより、複製または更新操作で複製されるタスク権限が決定されます。
現在のタスク所有者(つまり、タスクに対する OWNERSHIP 権限を持つロール)が、最後にタスクが再開されたときと同じロールである場合は、タスクに対する現在のすべての権限がセカンダリデータベースに複製されます。
現在のタスクの所有者が、最後にタスクが再開されたときと同じロール ではない 場合は、タスクバージョンで所有者のロールに付与された OWNERSHIP 権限のみがセカンダリデータベースに複製されます。
現在のタスク所有者ロールが使用できない場合(例: 子タスクがドロップされたが、新しいバージョンのタスク DAG がまだコミットされていない場合)は、タスクバージョンで所有者ロールに付与された OWNERSHIP 権限のみがセカンダリデータベースに複製されます。
フェールオーバー後にタスクが実行される¶
セカンダリフェールオーバーグループがプライマリグループとして機能するように昇格された後、フェールオーバーグループ内のデータベースで再開されたタスクは、段階的にスケジュールされます。再開されたすべてのスタンドアロンタスクと DAGs の通常のスケジュールを復元するために必要な時間は、データベース内にある再開されたタスクの数によって異なります。
タスク複製を有効にする¶
タスク複製のプレビューを有効にするには、 ストリームとタスクの複製のプレビューを有効にする --- オプション をご参照ください。
複製およびTime Travel¶
Time Travel と Fail-safe のデータは、セカンダリデータベースのために独立して維持され、プライマリデータベースからは複製されません。Time Travelを使用してセカンダリデータベースのテーブルとビューをクエリすると、プライマリデータベースで同じクエリを実行した場合とは異なる結果が生成される可能性があります。
- 履歴データ
Time Travelを使用してプライマリデータベースでクエリできる履歴データは、セカンダリデータベースに複製されません。
例えば、Snowpipeを使用してデータが10分ごとにテーブルに継続的にロードされ、セカンダリデータベースが1時間ごとに更新されるとします。更新操作では、テーブルの最新バージョンのみが複製されます。保持期間内のテーブルの1時間ごとのバージョンは、Time Travelを使用したクエリで使用できますが、1時間以内の反復バージョン(個々のSnowpipeロード)は使用できません。
- データ保持期間
セカンダリデータベース内のテーブルのデータ保持期間は、プライマリデータベース内のテーブルに書き込まれた DML 操作(つまり、データの変更または削除)でセカンダリデータベースが更新されると始まります。
注釈
データ保持期間パラメーター DATA_RETENTION_TIME_IN_DAYS の複製先は、データベース自体ではなく、セカンダリデータベースにあるデータベースオブジェクトに限られます。パラメーター複製の詳細については、 パラメーター をご参照ください。
複製と大規模でチャーン率の高いテーブル¶
テーブルの1つ以上の行が更新または削除されると、このデータをプライマリデータベースに保存する、影響を受けるすべてのマイクロパーティションが再作成され、セカンダリデータベースと同期する必要があります。大規模でチャーン率の高いディメンションテーブルの場合、複製コストがかなり高くなる可能性があります。
大幅な複製コストが発生する大規模でチャーン率の高いディメンションテーブルの場合、次の軽減策を利用できます。
このようなテーブルを保存するプライマリデータベースをより低い頻度で複製します。
データモデルを変更して、チャーン率を減らします。
詳細については、 大規模でチャーンの大きいテーブルのコスト管理 をご参照ください。
複製とクローニング¶
クローンオブジェクトは、論理的にセカンダリデータベースに複製されるのではなく、物理的に複製されます。つまり、クローンに対する DML 操作が既存のデータに追加または変更しない限り、標準データベース内のクローンテーブルは全体的なデータストレージに寄与しません。ただし、クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加します。
ダングリングリファレンス¶
別のデータベース内のオブジェクトへの参照¶
プライマリデータベースのビューまたはテーブル制約が別のデータベースを参照しているかどうかを慎重に分析します。
- ビュー
このタイプの参照は名前ベースであるため、別のデータベース内のオブジェクトを参照する非マテリアライズドビュー(例:テーブル列、他のビュー、 UDFs、またはステージ)を複製できます。名前ベースの参照によって複製が失敗することはありません。ただし、他のデータベースが同じリージョンに複製されていない場合、セカンダリデータベースのビューに対するクエリは失敗します。
たとえば、データベース
d1
のビューv1
が、データベースd1
とd2
のテーブルt1
とt2
をそれぞれ参照するとします。セカンダリデータベースd1
のビューV1を正常にクエリするには、セカンダリデータベースd2
もアカウントに存在する必要があります(例: 別のセカンダリデータベースとして)。さらに、プライマリデータベースとの一貫したクエリ結果を得るには、セカンダリデータベースd1
とd2
を同時に更新する必要があります。マテリアライズドビューでダングリング参照があると、複製に失敗し、次のエラーメッセージが表示される場合があります。
Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
これらのダングリング参照は、次の場合に発生する可能性があります。
マテリアライズドビューが別のデータベース内にある任意のオブジェクトを参照する。
マテリアライズドビューは、オブジェクトを名前ではなく ID で参照します。データベーススナップショットは、データベース外部のオブジェクトへの ID ベースの参照を解決できません。
別のデータベースにあるオブジェクトへのダングリング参照を避けるために、マテリアライズドビューとそれらが参照するオブジェクトを同じデータベースに格納することをお勧めします。
マテリアライズドビューが無効である(つまり、 ドロップされたオブジェクト を参照している)。
無効なマテリアライズドビューのダングリング参照エラーを回避するには、マテリアライズドビューの問題を特定して修正します。マテリアライズドビューのトピック内の トラブルシューティング セクションをご参照ください。
- 制約
現在、外部キーをダングリングすると複製に失敗し、次のエラーメッセージが表示されます。
Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
この状況は、プライマリデータベースの外部キーが別のデータベースの主キーを参照する場合、またはその逆の場合に発生します。これは、制約参照が ID ベースであるためです。データベーススナップショットは、独自のデータベース外にあるオブジェクトへの ID ベースの参照を解決できません。
アカウントの外部キー参照を表示するには、Information Schemaまたは ACCOUNT_USAGE スキーマにある TABLE_CONSTRAINTS ビューをクエリします。
この制限を回避するために、リンクされたテーブルは同じデータベースに保存することをお勧めします。
- シーケンス
現在、シーケンスをダングリングすると複製に失敗し、次のエラーメッセージが表示されます。
Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
この状況は、プライマリデータベースのテーブルが別のデータベースのシーケンスを参照している場合に発生します。これは、シーケンス参照が ID ベースであるためです。データベーススナップショットは、独自のデータベース外にあるオブジェクトへの ID ベースの参照を解決できません。
この制限を回避するために、シーケンスは同じデータベースで参照することをお勧めします。
- ポリシーおよびタグ
マスキングポリシー、 行アクセスポリシー、または タグ の参照をダングリングすると複製に失敗し、次のエラーメッセージが表示されます。
Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
この状況は、ポリシー/タグと、ポリシー/タグが割り当てられているオブジェクトが異なるデータベースに存在する場合に発生します。たとえば、
db1.s1.t1
という名前のテーブル、db2.s1.rap1
という名前の行アクセスポリシー、および行アクセスポリシーがテーブルに割り当てられます。このダングリングリファレンス動作は、データベース複製に適用されます。
これを回避するには、 複製グループ を使用してデータベースを複製します。
ネットワークポリシー が アカウント複製およびフェールオーバー のコンテキストでユーザーに割り当てられている場合にも、ダングリングリファレンスが発生する可能性があります。詳細については、 ネットワークポリシー複製 をご参照ください。
ドロップされたオブジェクトへの参照¶
同じデータベースまたは別のデータベース内の別のオブジェクトによって参照されているオブジェクトを削除すると、ダングリングリファレンスを引き起こします。プライマリデータベース内のオブジェクトが削除されたオブジェクトを参照すると、レプリケーション操作が失敗し、次のエラーメッセージが表示されます。
Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities])
この制限を回避するには、次のステップのいずれか 1つ を完了することをお勧めします。
削除された参照されているオブジェクトを復元します。
参照するオブジェクトを変更します(例: ALTER MATERIALIZED VIEW を使用してマテリアライズドビューを変更)。別のオブジェクトを参照するか、ドロップされたオブジェクトへの参照を削除します。
ドロップされたオブジェクトを参照するオブジェクトをプライマリデータベースでドロップします。
ストアドプロシージャとユーザー定義関数の複製(UDFs)¶
ストアドプロシージャと UDFs は、プライマリデータベースからセカンダリデータベースに複製されます。
ステージの複製はまだサポートされていないことに注意してください。ストアドプロシージャまたは UDF がステージ内のファイルに依存する場合(例: ステージからアップロードされたPythonコードでストアドプロシージャが定義されている場合)は、ステージとそのファイルをセカンダリデータベースに手動で複製する必要があります。
たとえば、プライマリデータベースに、ステージに格納されているコードをインポートするインラインPython UDF がある場合、 UDF はセカンダリデータベースに複製されますが、ステージとインポートされたコードが手動でセカンダリデータベースに複製されるまでは機能しません。
複製とアクセス制御¶
セカンダリデータベースは読み取り専用です。ただし、データベース所有者(つまり、セカンダリデータベースに対して OWNERSHIP 権限を持つロール)は、 GRANT <権限> を使用して、データベースオブジェクト(つまり、スキーマ、テーブル、ビューなど)に対する権限を他のロールに付与できます。
複数のデータベースの複製¶
複数のデータベースが複製される場合、データベース間でのポイントインタイムの一貫性は利用できません。各プライマリデータベースのスナップショットは個別に作成され、セカンダリデータベースへの変更は個別にコミットされます。これは、異なるデータベースのテーブル間で結合するビューがある場合、またはデータベース間のトランザクションに依存する場合に問題になる可能性があります。たとえば、2つのプライマリデータベースをアトミックに更新するトランザクションは、セカンダリデータベースに同時に反映されない可能性があります。
履歴使用データ¶
プライマリデータベースのアクティビティの履歴使用データは、セカンダリデータベースに複製されません。各アカウントには、独自のクエリ履歴、ログイン履歴などがあります。
履歴使用データには、次の Snowflake Information Schema 表関数または アカウントの使用 ビューによって返されたクエリデータが含まれます。
COPY_HISTORY
LOGIN_HISTORY
QUERY_HISTORY
など。