複製に関する考慮事項¶
このトピックでは、 複製またはフェールオーバーグループ あるいは データベース複製 を使用して複製する際における、セカンダリデータベース内およびオブジェクト内にある特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。
以前に ALTER DATABASE ... ENABLE REPLICATION TO ACCOUNTS コマンドを使用して個別のデータベースのデータベース複製を有効にした場合は、データベース複製に固有の追加の考慮事項について、 データベース複製の考慮事項 をご参照ください。
このトピックの内容:
複製グループおよびフェールオーバーグループの制約¶
次のセクションでは、アカウントオブジェクト、データベース、および共有を複製およびフェールオーバーグループに追加する際の制約について説明します。
アカウントオブジェクト¶
アカウントには、データベースまたは共有 以外 のオブジェクトを含む複製またはフェールオーバーグループを1つだけ含めることができる。
複製権限¶
このセクションでは、ユーザーがシステム内にある複製およびフェールオーバーグループオブジェクトに対して実行できる操作を指定するためにロールに付与できる複製権限について説明します。GRANT コマンドの構文については、 GRANT <権限> をご参照ください。
注釈
データベース複製 の場合は、 ACCOUNTADMIN ロールを持つユーザーのみが、データベースの複製とフェールオーバーを有効にして管理できます。データベース複製に必要な権限の詳細については、 ステップ6:スケジュールに基づいてセカンダリデータベースを更新する の 必要な権限のテーブル をご参照ください。
権限 |
オブジェクト |
使用状況 |
メモ |
---|---|---|---|
OWNERSHIP |
複製グループ フェールオーバーグループ |
オブジェクトへのアクセスを削除、変更、付与または取り消す機能を付与します。 |
付与者:
|
CREATE REPLICATION GROUP |
アカウント |
複製グループを作成する権限を付与します。 |
ACCOUNTADMIN ロールによって付与される必要があります。 |
CREATE FAILOVER GROUP |
アカウント |
フェールオーバーグループを作成する権限を付与します。 |
ACCOUNTADMIN ロールによって付与される必要があります。 |
FAILOVER |
フェールオーバーグループ |
セカンダリフェールオーバーグループを昇格してプライマリフェールオーバーグループとして機能させる権限を付与します。 |
グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。 |
REPLICATE |
複製グループ フェールオーバーグループ |
セカンダリグループを更新する権限を付与します。 |
グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。 |
MODIFY |
複製グループ フェールオーバーグループ |
オブジェクトの設定やプロパティを変更する機能を付与します。 |
グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。 |
MONITOR |
複製グループ フェールオーバーグループ |
オブジェクト内の詳細を表示する権限を付与します。 |
グループに対する OWNERSHIP 権限を持つロールによって付与または取り消すことができます。 |
指定された権限のセットを使用してカスタムロールを作成する手順については、 カスタムロールの作成 をご参照ください。
セキュリティ保護可能なオブジェクト に対して SQL アクションを実行するためのロールと権限付与に関する一般的な情報については、 アクセス制御の概要 をご参照ください。
複製グループ間での複製と参照¶
ダングリングリファレンス(つまり、別の複製またはフェールオーバーグループ内にあるオブジェクトへの参照)を持つ複製(またはフェールオーバー)グループ内のオブジェクトは、場合によってはターゲットアカウントに正しく複製される可能性があります。複製操作の結果、ソースアカウントで発生する可能性のある動作と一致する動作がターゲットアカウントで発生する場合は、複製に成功します。
たとえば、フェールオーバーグループ fg_a
のテーブルの列がフェールオーバーグループ fg_b
のシーケンスを参照している場合は、両方のグループの複製に成功します。 fg_a
が fg_b
の 前に 複製される場合は、 fg_b
が複製されないと、シーケンスを参照するテーブルの挿入操作(フェールオーバー後)に 失敗 します。この動作は、ソースアカウントで発生する可能性があります。シーケンスがソースアカウントでドロップされると、ドロップされたシーケンスを参照する列を持つテーブルへの挿入操作に失敗します。
ダングリングリファレンスがデータを保護するセキュリティポリシーである場合、セキュリティポリシーの複製(またはフェールオーバー)グループは、ポリシーを参照するオブジェクトを含む複製グループが複製される前に複製される 必要 があります。
注意
個別の複製またはフェールオーバーグループのデータを保護するセキュリティポリシーを更新すると、不整合が生じる可能性があるため、注意する必要があります。
データベースオブジェクトの場合は、Account Usage OBJECT_DEPENDENCIES ビュー で オブジェクトの依存関係 を表示できます。
ストリーム¶
ストリームのダングリング参照により、複製が失敗し、次のエラーメッセージが表示されます。
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
を含めます。
詳細については、 複数のアカウントにわたるセキュリティ統合およびネットワークポリシーの複製 トピック内の ネットワークポリシー をご参照ください。
複製および読み取り専用のセカンダリオブジェクト¶
セカンダリデータベースと共有を含む、ターゲットアカウント内のすべてのセカンダリオブジェクトは読み取り専用です。複製されたオブジェクトまたはオブジェクト型を、ターゲットアカウントでローカルに変更することはできません。たとえば、 USERS
オブジェクト型がソースアカウントからターゲットアカウントに複製される場合、ターゲットアカウントで新しいユーザーを作成または変更することはできません。
新しいローカルデータベースおよび共有は、ターゲットアカウントで作成および変更 できます。 ROLES
もターゲットアカウントに複製される場合、そのターゲットアカウントで新しいロールを作成または変更することはできません。よって、ターゲットアカウントにあるセカンダリオブジェクトのロールへの権限付与(または取り消し)はできません。ただし、ターゲットアカウントで作成されたローカルオブジェクト(例: データベース、共有、複製またはフェールオーバーグループ)のセカンダリロールに権限を付与する(または取り消す)ことは できます。
ターゲットアカウントでの複製とオブジェクト¶
複製経由以外の方法 (例: スクリプト使用)でターゲットアカウントにユーザーやロールなどのアカウントオブジェクトを作成する場合、デフォルトでこれらのユーザーとロールにはグローバル識別子がありません。ターゲットアカウントがソースアカウントから更新されると、更新操作により、グローバル識別子を持たないターゲットアカウント内にある OBJECT_TYPES
リスト(例: USERS
または ROLES
)のすべてのアカウントオブジェクト型が ドロップ されます。
これらのオブジェクトのドロップを回避するには、 ターゲットアカウントのスクリプトによって作成されたオブジェクトにグローバル IDs を適用する をご参照ください。
複製およびセキュリティポリシー¶
セキュリティポリシーと参照(つまり、割り当て)を含むデータベースは、複製およびフェールオーバーグループを使用して複製できます。セキュリティポリシーには、次が含まれます。
データベース複製 を使用している場合は、 データベース複製およびセキュリティポリシー をご参照ください。
パスワードおよびセッションポリシー¶
複製グループまたはフェールオーバーグループでポリシー(ALLOWED_DATABASES = policy_db
)と USERS
を含むデータベースを指定すると、ユーザーのパスワードとセッションポリシーの参照が複製されます。
ポリシーデータベースまたはユーザーがすでにターゲットアカウントに複製されている場合は、ソースアカウントの複製またはフェールオーバーグループを更新して、ポリシーを正常に複製するために必要なデータベースとオブジェクト型を含めます。次に、更新操作を実行して、ターゲットアカウントを更新します。
ユーザーレベルのポリシーが使用されていない場合は、 USERS
を複製またはフェールオーバーグループに含める必要はありません。
注釈
ポリシーは、アカウントレベルのポリシー割り当ておよびユーザーレベルのポリシー割り当てと同じアカウントにある必要があります。
アカウントまたはアカウント内のユーザーにセッションポリシーまたはパスワードポリシーが設定されていて、ポリシーと USERS
を含んでいる policy_db
を含めるように複製またはフェールオーバーグループを更新しないと、ターゲットアカウントでダングリング参照が発生します。この場合、ダングリング参照は、ポリシーの完全修飾名がソースアカウントのデータベースをポイントしているため、Snowflakeはターゲットアカウントでポリシーを見つけることができないことを意味します。したがって、ターゲットアカウントまたはターゲットアカウント内のユーザーは、セッションポリシーまたはパスワードポリシーに準拠する必要はありません。
セキュリティポリシーを正常に複製するには、ダングリング参照を防ぐために必要なオブジェクト型とデータベースが複製またはフェールオーバーグループに含まれていることを確認します。
複製とクローニング¶
クローンオブジェクトは、論理的にセカンダリデータベースに複製されるのではなく、物理的に複製されます。つまり、クローンに対する DML 操作が既存のデータに追加または変更しない限り、標準データベース内のクローンテーブルは全体的なデータストレージに寄与しません。ただし、クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加します。
複製と自動クラスタリング¶
プライマリデータベースでは、Snowflakeは 自動クラスタリング を使用してクラスター化されたテーブルをモニターし、必要に応じてそれらを再クラスター化します。更新操作の一部として、クラスター化されたテーブルは、テーブルのマイクロパーティションの現在の並べ替えを使用してセカンダリデータベースに複製されます。そのため、セカンダリデータベース内のクラスター化されたテーブルで再クラスタリングが再度実行されることは ありません 。これは冗長です。
セカンダリデータベースにクラスター化されたテーブルが含まれており、データベースがプライマリデータベースになると、Snowflakeはこのデータベースのテーブルの自動クラスタリングを開始すると同時に、以前のプライマリデータベースのクラスター化テーブルの監視を一時停止します。
マテリアライズドビューの自動クラスタリングの詳細については、このトピックの 複製とマテリアライズドビュー をご参照ください。
複製と大規模でチャーン率の高いテーブル¶
テーブルの1つ以上の行が更新または削除されると、このデータをプライマリデータベースに保存する、影響を受けるすべてのマイクロパーティションが再作成され、セカンダリデータベースと同期する必要があります。大規模でチャーン率の高いディメンションテーブルの場合、複製コストがかなり高くなる可能性があります。
大幅な複製コストが発生する大規模でチャーン率の高いディメンションテーブルの場合、次の軽減策を利用できます。
このようなテーブルを保存するプライマリデータベースをより低い頻度で複製します。
データモデルを変更して、チャーン率を減らします。
詳細については、 大規模でチャーンの大きいテーブルのコスト管理 をご参照ください。
複製およびTime Travel¶
Time Travel と Fail-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.
このエラーを回避するには、複製されたセカンダリデータベースではない別のデータベースに外部テーブルを移動します。
複製およびSnowpipe Streaming¶
プライマリデータベースの Snowpipe Streaming によって生成されたテーブルが、ターゲットアカウントのセカンダリデータベースに複製されます。
プライマリデータベースでは、テーブルが作成され、 チャネル を介して行が挿入されます。 オフセットトークン は、インジェスチョンの進捗を追跡します。リフレッシュ操作は、テーブルオブジェクト、テーブルデータ、およびテーブルに関連するチャネルオフセットをプライマリデータベースからセカンダリデータベースに複製します。
オフセットを取得するためのSnowflake Streaming読み取り専用操作は、ソースおよびターゲットアカウントで使用できます。
チャネル getLatestCommittedOffsetToken API
SHOW CHANNELS コマンド
Snowflake Streamingの書き込み操作は、ソースアカウントでのみ使用できます。
クライアント openChannel API
チャネル insertRow API
チャネル insertRows API
データ損失の回避¶
フェールオーバー時のデータ損失を防ぐには、上流データソースに正常に挿入された行のデータ保持時間を複製頻度より長くする必要があります。プライマリデータベースのテーブルにデータが挿入され、データがセカンダリデータベースに複製される前にフェールオーバーが発生した場合は、新しく昇格したプライマリデータベースのテーブルに同じデータを挿入する必要があります。以下はシナリオ例です。
プライマリデータベース
repl_db
のテーブルt1
に、Snowpipe StreamingとKafkaコネクタを使用してデータを投入します。プライマリ データベースにある
t1
のoffsetToken
は、チャネル1で100、チャネル2で100です。ターゲットアカウントでリフレッシュ操作は正常に完了します。
セカンダリ データベースにある
t1
のoffsetToken
は、チャネル1で100、チャネル2で100です。プライマリデータベースの
t1
にさらに行が挿入されます。プライマリ データベースにある
t1
のoffsetToken
は、チャネル1で200、チャネル2で200になります。追加の行と新しいチャネルオフセットがセカンダリデータベースに複製される前に、フェールオーバーが発生します。
この場合、新しく昇格したプライマリデータベースにあるテーブル t1
の各チャネルで100個のオフセットが欠落しています。欠落データを挿入するには、 Snowpipe Streamingのためのアクティブチャネルを新しく昇格したソースアカウントで再度開きます。 をご参照ください。
要件¶
Snowpipe Streaming複製のサポートには、以下の最小バージョンが必要です。
Snowflake Ingest SDK バージョン1.1.1以降
Kafkaコネクタを使用している場合: Kafkaコネクタのバージョン1.9.3以降
制限事項¶
Snowpipe Streamingによって投入されたSnowflakeテーブルでストリームを使用した複製が有効になっていません。Snowpipe Streamingによって投入されたSnowflakeテーブルでストリームを複製する場合は、 Snowflakeサポート にお問い合わせください。
ストアドプロシージャとユーザー定義関数の複製(UDFs)¶
ストアドプロシージャと UDFs は、プライマリデータベースからセカンダリデータベースに複製されます。
ステージの複製はまだサポートされていないことに注意してください。ストアドプロシージャまたは UDF がステージ内のファイルに依存する場合(例: ステージからアップロードされたPythonコードでストアドプロシージャが定義されている場合)は、ステージとそのファイルをセカンダリデータベースに手動で複製する必要があります。
たとえば、プライマリデータベースに、ステージに格納されているコードをインポートするインラインPython UDF がある場合、 UDF はセカンダリデータベースに複製されますが、ステージとインポートされたコードが手動でセカンダリデータベースに複製されるまでは機能しません。
複製およびストリーム¶
このセクションでは、 複数のアカウント間でのデータベースの複製 または アカウント複製およびフェールオーバー/フェールバック でストリームを複製する際の推奨される方法と潜在的な懸念事項について説明します。
ストリームでサポートされるソースオブジェクト¶
複製されたストリームは、同じデータベース内のテーブルとビューの変更データを正常に追跡できます。
現在、次のソースオブジェクト型はサポート されていません。
ディレクトリテーブル
外部テーブル
ストリームデータベースとは別のデータベース内にあるテーブルまたはビュー。
この設計は、ストリームデータベースとソースオブジェクトを格納するデータベースの両方が同じ 複製グループまたはフェールオーバーグループ に含まれている 場合 に機能します。
共有データベースのテーブルまたはビュー(つまり、プロバイダーアカウントから自分のアカウントに共有されるデータベース)
サポートされていないソースオブジェクトを含むストリームがプライマリデータベースに含まれている場合は、データベースの複製または更新操作に失敗します。いずれかのストリームのソースオブジェクトがドロップされている場合も、操作に失敗します。
データ重複の回避¶
注釈
このセクションで説明するシナリオに加えて、セカンダリデータベースのストリームは、更新操作で最初に含まれるときに、重複する行を返す可能性があります。この場合の 重複行 は、複数の 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 トランザクションは、テーブルバージョンtv1
およびtv2
を作成します。テーブル
t1
を含むセカンダリデータベースが更新されます。この複製されたテーブルのテーブルバージョンはtv2
です。ただし、テーブル履歴は複製されません。Time Travelを使用して、オフセットをテーブルバージョン
tv1
に設定したプライマリデータベースにストリームが作成されます。セカンダリデータベースがフェールオーバーされ、プライマリデータベースになります。
テーブルバージョン
tv1
がテーブル履歴にないため、ストリームs1
をクエリするとエラーが返されます。
テーブル t1
の後続の DML トランザクションがテーブルバージョンを tv3
に反復すると、ストリーム s1
のオフセットが進むことに注意してください。ストリームは再び読み取り可能になります。
データ損失の回避¶
セカンダリデータベースの最新の更新操作がフェールオーバー操作の前に完了していないと、データが失われる可能性があります。リスクを最小限に抑えるために、セカンダリデータベースを頻繁に更新することをお勧めします。
複製およびタスク¶
このセクションでは、 複数のアカウント間でのデータベースの複製 または アカウント複製およびフェールオーバー/フェールバック におけるタスク複製について説明します。
複製のシナリオ¶
次のテーブルでは、さまざまなタスクシナリオについて説明し、タスクが複製されるかどうかを示します。特に断りのない限り、シナリオはスタンドアロンタスクと 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 の通常のスケジュールを復元するために必要な時間は、データベース内にある再開されたタスクの数によって異なります。
複製およびタグ¶
タグとその割り当ては、ソースアカウントからターゲットアカウントに複製できます。
ソースアカウントから最初に複製した後に、ターゲットアカウントでタグの割り当てを変更することはできません。たとえば、セカンダリ(つまり、複製された)データベースにタグを設定することは許可されていません。ターゲットアカウントでタグの割り当てを変更するには、ソースアカウントでそれらを変更し、ターゲットアカウントに複製します。
タグを正常に複製するには、複製またはフェールオーバーグループに以下が含まれていることを確認します。
ALLOWED_DATABASES
プロパティのタグを含むデータベース。OBJECT_TYPES
プロパティにタグを持つその他のアカウントレベルのオブジェクト(例:ROLES
、WAREHOUSES
)。詳細については、 CREATE REPLICATION GROUP および CREATE FAILOVER GROUP をご参照ください。
履歴使用データ¶
プライマリデータベースにあるアクティビティの使用データ履歴は、セカンダリデータベースに複製されません。各アカウントには、独自のクエリ履歴、ログイン履歴などがあります。
履歴使用データには、次の Snowflake Information Schema 表関数または Account Usage ビューによって返されたクエリデータが含まれます。
COPY_HISTORY
LOGIN_HISTORY
QUERY_HISTORY
など。