複製に関する考慮事項

このトピックでは、 複製またはフェールオーバーグループ あるいは データベース複製 を使用して複製する際における、セカンダリデータベース内およびオブジェクト内にある特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。

以前に ALTER DATABASE ... ENABLE REPLICATION TO ACCOUNTS コマンドを使用して個別のデータベースのデータベース複製を有効にした場合は、データベース複製に固有の追加の考慮事項について、 データベース複製の考慮事項 をご参照ください。

このトピックの内容:

複製グループとフェールオーバーグループの制約

次のセクションでは、アカウントオブジェクト、データベース、および共有を複製およびフェールオーバーグループに追加する際の制約について説明します。

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

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

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

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

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

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

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

アカウントオブジェクト

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

複製権限

このセクションでは、ユーザーがシステム内にある複製およびフェールオーバーグループオブジェクトに対して実行できる操作を指定するためにロールに付与できる複製権限について説明します。GRANT コマンドの構文については、 GRANT <権限> をご参照ください。

注釈

データベース複製 の場合は、 ACCOUNTADMIN ロールを持つユーザーのみが、データベースの複製とフェールオーバーを有効にして管理できます。データベース複製に必要な権限の詳細については、 ステップ6.スケジュールに基づいてセカンダリデータベースを更新する必要な権限のテーブル をご参照ください。

権限

オブジェクト

使用状況

メモ

OWNERSHIP

複製グループ

フェールオーバーグループ

オブジェクトへのアクセスを削除、変更、付与または取り消す機能を付与します。

付与者:

ACCOUNTADMIN のロール または

MANAGE GRANTS 権限を持つロール または

グループに対して OWNERSHIP 権限を持つロール。

CREATE REPLICATION GROUP

アカウント

複製グループを作成する権限を付与します。

ACCOUNTADMIN ロールによって付与される必要があります。

CREATE FAILOVER GROUP

アカウント

フェールオーバーグループを作成する権限を付与します。

ACCOUNTADMIN ロールによって付与される必要があります。

FAILOVER

フェールオーバーグループ

セカンダリフェールオーバーグループを昇格してプライマリフェールオーバーグループとして機能させる権限を付与します。

グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。

REPLICATE

複製グループ

フェールオーバーグループ

セカンダリグループを更新する権限を付与します。

グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。

MODIFY

複製グループ

フェールオーバーグループ

オブジェクトの設定やプロパティを変更する機能を付与します。

グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。

MONITOR

複製グループ

フェールオーバーグループ

オブジェクト内の詳細を表示する権限を付与します。

グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。

指定された権限のセットを使用してカスタムロールを作成する手順については、 カスタムロールの作成 をご参照ください。

セキュリティ保護可能なオブジェクト に対して SQL アクションを実行するためのロールと権限付与に関する一般的な情報については、 アクセス制御の概要 をご参照ください。

複製グループ間での複製と参照

ダングリングリファレンス(つまり、別の複製またはフェールオーバーグループ内にあるオブジェクトへの参照)を持つ複製(またはフェールオーバー)グループ内のオブジェクトは、場合によってはターゲットアカウントに正しく複製される可能性があります。複製操作の結果、ソースアカウントで発生する可能性のある動作と一致する動作がターゲットアカウントで発生する場合は、複製に成功します。

たとえば、フェールオーバーグループ fg_a のテーブルの列がフェールオーバーグループ fg_b のシーケンスを参照している場合は、両方のグループの複製に成功します。 fg_afg_b前に 複製される場合は、 fg_b が複製されないと、シーケンスを参照するテーブルの挿入操作(フェールオーバー後)に 失敗 します。この動作は、ソースアカウントで発生する可能性があります。シーケンスがソースアカウントでドロップされると、ドロップされたシーケンスを参照する列を持つテーブルへの挿入操作に失敗します。

ダングリングリファレンスがデータを保護するセキュリティポリシーである場合、セキュリティポリシーの複製(またはフェールオーバー)グループは、ポリシーを参照するオブジェクトを含む複製グループが複製される前に複製される 必要 があります。

注意

個別の複製またはフェールオーバーグループのデータを保護するセキュリティポリシーを更新すると、不整合が生じる可能性があるため、注意する必要があります。

データベースオブジェクトの場合は、Account Usage OBJECT_DEPENDENCIES ビューオブジェクトの依存関係 を表示できます。

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

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

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 POLICIESACCOUNT PARAMETERS を含めます。

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

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

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

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

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.

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

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

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

複製と読み取り専用のセカンダリオブジェクト

セカンダリデータベースと共有を含む、ターゲットアカウント内のすべてのセカンダリオブジェクトは読み取り専用です。複製されたオブジェクトまたはオブジェクト型を、ターゲットアカウントでローカルに変更することはできません。たとえば、 USERS オブジェクト型がソースアカウントからターゲットアカウントに複製される場合、ターゲットアカウントで新しいユーザーを作成または変更することはできません。

新しいローカルデータベースおよび共有は、ターゲットアカウントで作成および変更 できますROLES もターゲットアカウントに複製される場合、そのターゲットアカウントで新しいロールを作成または変更することはできません。よって、ターゲットアカウントにあるセカンダリオブジェクトのロールへの権限付与(または取り消し)はできません。ただし、ターゲットアカウントで作成されたローカルオブジェクト(例: データベース、共有、複製またはフェールオーバーグループ)のセカンダリロールに権限を付与する(または取り消す)ことは できます

ターゲットアカウントでの複製とオブジェクト

複製経由以外の方法 (例: スクリプトの使用)でターゲットアカウントにユーザーやロールなどのアカウントオブジェクトを作成した場合、デフォルトでこれらのユーザーとロールにはグローバル識別子がありません。ターゲットアカウントがソースアカウントからリフレッシュされると、リフレッシュ操作により、グローバル識別子を持たないターゲットアカウント内にある OBJECT_TYPES リストのすべてのアカウントオブジェクト型が ドロップ されます。

注釈

USERS または ROLESを複製するための初期リフレッシュ操作でエラーが発生する場合があります。これは、ユーザーやロールに関連するデータやメタデータが誤って削除されるのを防ぐためです。これらのオブジェクト型がドロップされるか、またはリフレッシュ操作が失敗するかどうかを決定する状況の詳細については、 ユーザーおよびロールの初期複製 をご参照ください。

これらのオブジェクトのドロップを回避するには、 ターゲットアカウントのスクリプトによって作成されたオブジェクトにグローバル IDs を適用する をご参照ください。

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

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

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

複製とセキュリティポリシー

セキュリティポリシーと参照(つまり、割り当て)を含むデータベースは、複製およびフェールオーバーグループを使用して複製できます。セキュリティポリシーには、次が含まれます。

データベース複製 を使用している場合は、 データベース複製とセキュリティオブジェクト をご参照ください。

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

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

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

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

注釈

ポリシーは、アカウントレベルのポリシー割り当ておよびユーザーレベルのポリシー割り当てと同じアカウントにある必要があります。

アカウントまたはアカウント内のユーザーにセキュリティポリシーが設定されていて、ポリシーと USERS を含んでいる policy_db を含めるように複製またはフェールオーバーグループを更新しないと、ターゲットアカウントでダングリング参照が発生します。この場合、ダングリング参照は、ポリシーの完全修飾名がソースアカウントのデータベースをポイントしているため、Snowflakeはターゲットアカウントでポリシーを見つけることができないことを意味します。したがって、ターゲットアカウントまたはターゲットアカウント内のユーザーは、セキュリティポリシーに準拠する必要はありません。

セキュリティポリシーを正常に複製するには、ダングリング参照を防ぐために必要なオブジェクト型とデータベースが複製またはフェールオーバーグループに含まれていることを確認します。

複製とシークレット

複製グループまたはフェールオーバーグループを使用してのみ、シークレットを複製できます。シークレットを含むデータベース、シークレットを参照する UDFs またはプロシージャを含むデータベース、およびシークレットを参照する統合を、単一の複製グループまたはフェイルオーバーグループで指定します。

ある複製グループまたはフェールオーバーグループにシークレットを含むデータベースがあり、別の複製グループまたはフェールオーバーグループにシークレットを参照する統合がある場合:

  • まず統合を複製し、次にシークレットを複製すると、操作は成功します。すべてのオブジェクトが複製され、未解決の参照はありません。

  • 統合前にシークレットを複製し、そのシークレットがターゲットアカウントにまだ存在しない場合、ダングリング参照を防ぐためにターゲットアカウントに「プレースホルダーシークレット」が追加されます。Snowflake はプレースホルダーの秘密を統合にマッピングします。

    統合を含むグループを複製した後、シークレットを含むグループの次の更新操作で、Snowflakeはターゲットアカウントを更新して、プレースホルダーシークレットを統合で参照されるシークレットに置き換えます。

  • シークレットを複製し、 account1 から account2 への統合を複製しない場合、シークレットを使用する統合がないため、統合はターゲットアカウント(account2)で機能しません。さらに、フェールオーバーを行い、ターゲットアカウントがソースアカウントに昇格した場合、統合は機能しません。

    account1 をソースアカウントとするフェールオーバーを決定すると、シークレットと統合参照が一致し、プレースホルダシークレットは使用されません。これにより、セキュリティの統合と認証情報を含むシークレットを使用できるようになります。オブジェクトがお互いに参照できるためです。

複製とクローニング

クローンオブジェクトは、論理的にセカンダリデータベースに複製されるのではなく、物理的に複製されます。つまり、クローンに対する DML 操作が既存のデータに追加または変更しない限り、標準データベース内のクローンテーブルは全体的なデータストレージに寄与しません。ただし、クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加します。

複製と自動クラスタリング

プライマリデータベースでは、Snowflakeは 自動クラスタリング を使用してクラスター化されたテーブルをモニターし、必要に応じてそれらを再クラスター化します。更新操作の一部として、クラスター化されたテーブルは、テーブルのマイクロパーティションの現在の並べ替えを使用してセカンダリデータベースに複製されます。そのため、セカンダリデータベース内のクラスター化されたテーブルで再クラスタリングが再度実行されることは ありません 。これは冗長です。

セカンダリデータベースにクラスター化されたテーブルが含まれており、データベースがプライマリデータベースになると、Snowflakeはこのデータベースのテーブルの自動クラスタリングを開始すると同時に、以前のプライマリデータベースのクラスター化テーブルの監視を中断します。

マテリアライズドビューの自動クラスタリングの詳細については、このトピックの 複製とマテリアライズドビュー をご参照ください。

複製と大規模でチャーン率の高いテーブル

テーブルの1つ以上の行が更新または削除されると、このデータをプライマリデータベースに保存する、影響を受けるすべてのマイクロパーティションが再作成され、セカンダリデータベースと同期する必要があります。大規模でチャーン率の高いディメンションテーブルの場合、複製コストがかなり高くなる可能性があります。

大幅な複製コストが発生する大規模でチャーン率の高いディメンションテーブルの場合、次の軽減策を利用できます。

  • このようなテーブルを保存するプライマリデータベースをより低い頻度で複製します。

  • データモデルを変更して、チャーン率を減らします。

詳細については、 大規模でチャーンの大きいテーブルのコスト管理 をご参照ください。

複製およびTime Travel

Time TravelFail-safe のデータは、セカンダリデータベースのために独立して維持され、プライマリデータベースからは複製されません。Time Travelを使用してセカンダリデータベースのテーブルとビューをクエリすると、プライマリデータベースで同じクエリを実行した場合とは異なる結果が生成される可能性があります。

履歴データ:

Time Travelを使用してプライマリデータベースでクエリできる履歴データは、セカンダリデータベースに複製されません。

例えば、Snowpipeを使用してデータが10分ごとにテーブルに継続的にロードされ、セカンダリデータベースが1時間ごとに更新されるとします。更新操作では、テーブルの最新バージョンのみが複製されます。保持期間内のテーブルの1時間ごとのバージョンは、Time Travelを使用したクエリで使用できますが、1時間以内の反復バージョン(個々のSnowpipeロード)は使用できません。

データ保持期間:

セカンダリデータベース内のテーブルのデータ保持期間は、プライマリデータベース内のテーブルに書き込まれた DML 操作(つまり、データの変更または削除)でセカンダリデータベースが更新されると始まります。

注釈

データ保持期間パラメーター DATA_RETENTION_TIME_IN_DAYS の複製先は、データベース自体ではなく、セカンダリデータベースにあるデータベースオブジェクトに限られます。パラメーター複製の詳細については、 パラメーター をご参照ください。

複製とマテリアライズドビュー

プライマリデータベースで、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.

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

複製と動的テーブル

動的テーブルの複製は、動的テーブルを含むプライマリデータベースが複製グループに複製されているか、フェールオーバーグループに複製されているかによって動作が異なります。

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

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

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

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

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

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

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

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

複製およびSnowpipe Streaming

プライマリデータベースの Snowpipe Streaming によって生成されたテーブルが、ターゲットアカウントのセカンダリデータベースに複製されます。

プライマリデータベースでは、テーブルが作成され、 チャネル を介して行が挿入されます。 オフセットトークン は、インジェスチョンの進捗を追跡します。リフレッシュ操作は、テーブルオブジェクト、テーブルデータ、およびテーブルに関連するチャネルオフセットをプライマリデータベースからセカンダリデータベースに複製します。

  • オフセットを取得するためのSnowflake Streaming読み取り専用操作は、ソースおよびターゲットアカウントで使用できます。

  • Snowflake Streamingの書き込み操作は、ソースアカウントでのみ使用できます。

データ損失の回避

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

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

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

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

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

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

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

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

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

要件

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

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

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

複製とステージ

ステージオブジェクトには、次の制約が適用されます。

  • Snowflakeは現在、グループベースの複製(複製とフェールオーバーグループ)の一部として、ステージ複製をサポートしています。ステージ複製はデータベース複製ではサポートされていません。

  • 外部ステージを複製できます。ただし、外部ステージのファイルは複製されません。

  • 内部ステージを複製できます。内部ステージのファイルを複製するには、ステージのディレクトリテーブルを有効にする必要があります。Snowflakeは、ディレクトリテーブルによってマッピングされたファイルのみを複製します。

  • ディレクトリテーブルを持つ内部ステージを複製する場合、プライマリまたはセカンダリステージでディレクトリテーブルを無効にすることはできません。ディレクトリテーブルには、複製されたファイルや COPY ステートメントを使用してロードされたファイルに関する重要な情報が含まれています。

  • 内部ステージのディレクトリテーブルに 5GB を超えるサイズのファイルがある場合、リフレッシュ操作は失敗します。この制限を回避するには、 5GB より大きなファイルを別のステージに移動します。

    プライマリステージ、セカンダリステージ、または以前に複製されたステージのディレクトリテーブルを無効にすることはできません。ステージを含むデータベースを複製グループまたはフェールオーバーグループに追加する に、これらの手順に従ってください。

    1. プライマリステージで ディレクトリテーブルを無効化 します。

    2. 5GB より大きいファイルを、ディレクトリテーブルが有効になっていない別のステージに移動します。

    3. ファイルを別のステージに移動したら、プライマリステージのディレクトリテーブルを再度有効にします。

  • ユーザーステージとテーブルステージのファイルは複製されません。

  • ストレージ統合を使用する名前付き外部ステージの場合、フェールオーバーの前に、ターゲットアカウントでセカンダリストレージ統合の信頼関係を構成する必要があります。詳細については、 セカンダリストレージ統合のためにクラウドストレージアクセスを構成する をご参照ください。

  • 外部ステージをディレクトリテーブルで複製し、ソースディレクトリテーブルに 自動リフレッシュ を構成した場合、フェールオーバー前に セカンダリ ディレクトリテーブルに自動リフレッシュを構成する必要があります。詳細については、 セカンダリステージでディレクトリテーブルの自動リフレッシュを構成する をご参照ください。

  • 複製されたステージ上のディレクトリテーブルがステージ上の複製されたファイルと一致していない場合、コピーコマンドに予想以上の時間がかかることがあります。ディレクトリテーブルの一貫性を保つには、 ALTER STAGE ... REFRESH ステートメントでリフレッシュしてください。ディレクトリテーブルの整合性ステータスを確認するには、 SYSTEM$GET_DIRECTORY_TABLE_STATUS 関数を使用します。

複製とパイプ

パイプオブジェクトには、次の制約が適用されます。

  • Snowflakeは現在、グループベースの複製(複製とフェールオーバーグループ)の一部として、パイプ複製をサポートしています。パイプ複製はデータベース複製ではサポートされていません。

  • Snowflakeは、パイプがターゲットテーブルと同じ複製グループに属している場合にのみ、パイプのコピー履歴を複製します。

  • 通知統合の複製はサポートされていません。

  • Snowflakeは、最新のテーブル切り捨て後のロード履歴のみを複製します。

  • 通知を受け取るには、 フェールオーバーの前に ターゲットアカウントでセカンダリ自動インジェストパイプを構成する必要があります。詳細については、 セカンダリ自動インジェストパイプの通知を構成する をご参照ください。

  • SYSTEM$PIPE_STATUS 関数を使用して、フェールオーバー後に期待される実行状態にないパイプを解決します。

ストアドプロシージャとユーザー定義関数の複製(UDFs)

ストアドプロシージャと UDFs は、プライマリデータベースからセカンダリデータベースに複製されます。

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

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

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

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

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

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

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

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

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

複製とストリーム

このセクションでは、 複数のアカウント間でのデータベースの複製 または アカウント複製およびフェールオーバー/フェールバック でストリームを複製する際の推奨される方法と潜在的な懸念事項について説明します。

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

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

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

  • 外部テーブル

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

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

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

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

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

データ重複の回避

注釈

このセクションで説明するシナリオに加えて、セカンダリデータベースのストリームは、更新操作で最初に含まれるときに、重複する行を返す可能性があります。この場合の 重複行 は、複数の METADATA$ACTION 列値を持つ単一の行を指します。

最初の更新操作の後、セカンダリデータベースでこの特定の問題が発生することはありません。

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つのテーブルバージョンに折りたたまれるためです。更新操作のタイムスタンプより前に作成された反復テーブルバージョンは、複製されたソースオブジェクトのテーブル履歴に保存されません。

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

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

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

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

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

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

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

データ損失の回避

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

複製とタスク

このセクションでは、 複数のアカウント間でのデータベースの複製 または アカウント複製およびフェールオーバー/フェールバック におけるタスク複製について説明します。

複製のシナリオ

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

シナリオ

複製

メモ

タスクが作成され、手動で(EXECUTE TASK を使用して)再開または実行されました。タスクを再開または実行すると、タスクの初期バージョンが作成されます。

タスクは作成されましたが、再開も実行もされませんでした。

タスクは再作成されました(CREATE OR REPLACE TASK を使用)が、再開も実行もされませんでした。

タスクが再作成される の最新バージョンが複製されます。

タスクを再開または手動で実行すると、新しいバージョンがコミットされます。データベースが再度複製されると、新しいバージョンまたは最新のバージョンがセカンダリデータベースに複製されます。

タスクが作成され、再開または実行され、その後に変更(ALTER TASK を使用)されましたが、改めて再開または実行されませんでした。

タスクを再開または手動で実行すると、タスクパラメーターへの変更を含む新しいバージョンがコミットされます。新しい変更はコミットされていないため、タスクが中断および変更される前の最新バージョンが複製されます。

変更されたタスクが保持期間(現在30日間)内に再開されない場合は、タスクの最新バージョンがドロップされることに注意してください。この期間が過ぎると、タスクは改めて再開されない限り、セカンダリデータベースに複製されません。

スタンドアロンタスクが作成され、再開または実行されましたが、その後ドロップされました。

タスクグラフのルートタスクが作成され、再開または実行されましたが、その後中断され、ドロップされました。

タスクグラフ全体がセカンダリデータベースに複製されるわけではありません。

タスクグラフ内の子タスクが作成され、再開または実行されますが、その後中断され、ドロップされます。

タスクグラフの最新バージョン(タスクが中断され、ドロップされる前)がセカンダリデータベースに複製されます。

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

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

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

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

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

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

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

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

注釈

state に関係なく、すべてのセカンダリタスクは 中断 されます。詳細については、 フェールオーバー後にタスクが実行される をご参照ください。

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

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

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

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

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

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

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

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

複製とタグ

タグとその割り当ては、ソースアカウントからターゲットアカウントに複製できます。

ソースアカウントから最初に複製した後に、ターゲットアカウントでタグの割り当てを変更することはできません。たとえば、セカンダリ(つまり、複製された)データベースにタグを設定することは許可されていません。ターゲットアカウントでタグの割り当てを変更するには、ソースアカウントでそれらを変更し、ターゲットアカウントに複製します。

タグを正常に複製するには、複製またはフェールオーバーグループに以下が含まれていることを確認します。

  • ALLOWED_DATABASES プロパティのタグを含むデータベース。

  • OBJECT_TYPES プロパティにタグを持つその他のアカウントレベルのオブジェクト(例: ROLESWAREHOUSES)。

    詳細については、 CREATE REPLICATION GROUP および CREATE FAILOVER GROUP をご参照ください。

履歴使用データ

プライマリデータベースにあるアクティビティの使用データ履歴は、セカンダリデータベースに複製されません。各アカウントには、独自のクエリ履歴、ログイン履歴などがあります。

履歴使用データには、次の Snowflake Information Schema 表関数または Account Usage ビューによって返されたクエリデータが含まれます。

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • など。