これは何?
Snowflakeのレプリケーションに関してまとめてみたメモ。
レプリケーション(replication)は日本語マニュアルでは「複製」と表現される。
あとはプレビュー中の機能が多い印象。
公式情報
-
レプリケーション(複製)
- レプリカを作成する機能
- 元データ(ソース)を「プライマリオブジェクト」という
- 元データ(ソース)を持つアカウントを指して「ソースアカウント」という
- レプリケーション先を「セカンダリオブジェクト」という
- レプリケーション先のアカウントを指して「ターゲットアカウント」という
- AWS、GCP、Azureのリージョン全般でサポートされる
- グループ
- 複製グループ
- 1つ以上のターゲットアカウントにユニットとして複製される、ソースアカウント内のオブジェクトの定義済みコレクション
- 複製されたオブジェクトへの「読み取り専用」アクセスを提供する
- つまり、セカンダリオブジェクトに対して書き込み(更新)できない
- フェールオーバーグループ
- フェールオーバーも可能な複製グループ
- セカンダリフェールオーバーグループが、プライマリフェールオーバーグループに昇格すると、「読み取り/書き込み」アクセスが利用可能になる
- 複製グループ
- グループを使わない複製/フェールオーバーもある
-
ALTER DATABASE
で設定できるALTER DATABASE <name> ENABLE REPLICATION TO ACCOUNTS <account_identifier>
ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <account_identifier>
- グループを使った複製に移行したい場合は、先に無効にする必要がある
-
- エディション差分
- 複製自体は全エディションで使用できる
- 一部機能はBusiness Critical以上で利用できる
- アカウントオブジェクト(データベースおよび共有以外)複製
- フェールオーバーグループ
- Tri-Secret Secureで保護されたデータ
- レプリカを作成する機能
-
複製できるオブジェクト
- データベース
- ただし以下はNG
- 仮テーブル(テンポラリーテーブル/Temporary table)
- 外部テーブル
- イベントテーブル
- ただし以下はNG
- シェア(共有)
- プロバイダーとして自分で作成したシェアオブジェクトが対象
- 一方で共有されたものは複製できない
- (Business Critical以上) ユーザー
- (Business Critical以上) ロール
- (Business Critical以上) ロールと権限の付与
- (Business Critical以上) ウェアハウス
- (Business Critical以上) リソースモニター
- (Business Critical以上) パラメーター(アカウントレベル)
- (Business Critical以上) ネットワークポリシー
- (Business Critical以上) 統合(インテグレーション/integration)
- ただし以下はプレビュー中
- ストレージ統合
- 外部アクセス統合
- ただし以下はプレビュー中
- データベース
-
複製スケジュール
- スケジュールによる自動更新が推奨されている
-
REPLICATION_SCHEDULE
パラメーターで設定する- こちら参照
-
- 一度に1回の更新のみが実行される
- 次回の更新がスケジュールされているときに更新がまだ実行中の場合、現在実行中の更新が完了後に次回の更新が遅れて開始される
- 更新の実行中は、セカンダリフェールオーバーグループをプライマリグループに昇格できない
- ターゲットアカウントでスケジュールされた複製を一時停止してから昇格する
- スケジュールされた複製を一時停止しても、現在進行中の更新操作は停止されない
- 複製処理が完了後、以降のスケジュールが停止される
- スケジュールによる自動更新が推奨されている
-
下位エディションのアカウントへの複製
- デフォルトではエラーになりうる
- デフォルトではBusiness Critical(またはそれ以上)のアカウントから、機密データを下位エディションのアカウントに誤って複製することを防ぐ動きになる点に注意する
- その手のデータ(HIPAA HITRUST規制、PHI データ)が含まれているときに複製しようとするとエラーになる
- エラー回避
-
CREATE <オブジェクト>
かALTER <オブジェクト>
のSQLの実行時にIGNORE EDITION CHECK句
を含めることで、エラーの回避は可能(デフォルトの動作を上書きする)
-
- デフォルトではエラーになりうる
-
複製に関する考慮事項 (いっぱいある...)
- オブジェクトは、1つのフェールオーバーグループにのみ存在できる
- 複製先が異なる場合は、1つのオブジェクトは複数の複製グループに所属できる
- オブジェクトは、フェールオーバーグループと複製グループの両方に含めることはできない
- セカンダリ(レプリカ)オブジェクトを、プライマリ複製グループまたはフェールオーバーグループに追加することはできない
-
複製の権限
- デフォルトではACCOUNTADMINで各種処理を実行できる
- カスタムロールで実行したい場合は以下の権限を考慮
- 複製グループの
OWNERSHIP
- フェールオーバーグループの
OWNERSHIP
-
CREATE REPLICATION GROUP
(複製グループを作成する権限) -
CREATE FAILOVER GROUP
(フェールオーバーグループを作成する権限) -
FAILOVER
(セカンダリフェールオーバーグループを昇格する権限) -
REPLICATE
(セカンダリグループを更新する権限) -
MODIFY
(オブジェクトの設定やプロパティを変更する機能) -
MONITOR
(オブジェクト内の詳細を表示する権限)
- 複製グループの
-
複製グループ間での複製と参照
-
ダングリングリファレンス/dangling referencesに注意する
- 要はオブジェクト間の依存関係に関するの話
- BY_NAME (CTASを実行するとき、AS以降に指定するテーブル名とか)
- BY_ID (ストレージ統合、外部ステージとか)
- BY_NAME_AND_ID (マテリアライズドビューとか)
- 依存関係を持っているオブジェクトが複製時に存在しなかった等の理由でエラーになる可能性がある
-
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.
- 回避策
- プライマリデータベースに、ストリームとそのベースオブジェクトの両方を含めておく
- ストリームを含むデータベースと、ストリームが参照するベースオブジェクトを含むデータベースが、同じ複製グループかフェールオーバーグループに含まれていること
- こんなエラーが出る
-
ネットワークポリシーの考慮点
- こんなエラーが出る
Dangling references in the snapshot. Correct the errors before refreshing again.
- ネットワークポリシーの参照と割り当ての複製では、参照されるオブジェクトと、ネットワークポリシーが割り当てられているオブジェクトも複製される
- サポートするオブジェクト型を適切に複製しないと、Snowflakeはターゲットアカウントでリフレッシュ操作に失敗する
- 回避策
- ネットワークポリシーがネットワークルールを使用する場合は、ネットワークルールが作成されたスキーマを含むデータベースを含めること(こちら参照)
- ネットワークポリシーがアカウントに関連付けられている場合は、 OBJECT_TYPES リストに NETWORK POLICIES と ACCOUNT PARAMETERS を含めること
- ネットワークポリシーがユーザーに関連付けられている場合は、 OBJECT_TYPES リストに NETWORK POLICIES と USERS を含めること
- 複製する時の具体例
- こちら参照
- こんなエラーが出る
-
シークレットの考慮点
- 以下を単一の複製グループまたはフェイルオーバーグループで指定する
- シークレットを含むデータベース
- シークレットを参照するUDFsやプロシージャを含むデータベース
- シークレットを参照する統合を
- 以下を単一の複製グループまたはフェイルオーバーグループで指定する
-
複製およびTime Travel
- セカンダリデータベース用に新たにTime Travel(タイムトラベル)、Fail-safe(フェールセーフ)が作成される
- プライマリデータベースとは独立している
-
複製と外部テーブル
- 複製しようとするとエラーが発生する
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.
- 回避策
- セカンダリになるデータベース内に外部テーブルが含まれないようにしておく
- 複製しようとするとエラーが発生する
-
複製とストリーム
- 以下のストリームはサポートされない
- 外部テーブル
- 共有から作成したデータベースのテーブル/ビュー
- 異なる複製グループ/フェールオーバーグループに、ストリームとソースオブジェクトが存在する(分離されている)場合
- ストリームとそのストリームが参照するオブジェクトは同じグループに入れておく必要があるということ
-
データ重複の回避
- ここに書いてある事例は見ておくとよさそう
-
ストリーム複製およびTime Travel
- ここに書いてある事例(図)は見ておくとよさそう
- 以下のストリームはサポートされない
-
複製とタスク
- タスクが複製されるかどうか
- こちら参照
- 基本的には「タスク作成後、再開も実行もされていないもの」は複製されない
- すべてのセカンダリタスクは中断される
- フェールオーバー後(セカンダリ昇格後)、順次タスクがスケジュールされる
- タスクが複製されるかどうか
- 要はオブジェクト間の依存関係に関するの話
-
ダングリングリファレンス/dangling referencesに注意する
-
複製経由以外の方法でターゲットアカウントにオブジェクトを作成した場合
- ターゲットアカウントがソースアカウントからリフレッシュされると、グローバル識別子を持たないターゲットアカウント内にある OBJECT_TYPES リストのすべてのアカウントオブジェクト型が削除される
-
複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製
- アカウントとデータベースオブジェクトの複製を有効にし、オブジェクトを更新する手順が書いてある
- こちら参照
- ソースアカウントでフェールオーバーグループを作成
- ターゲットアカウントでフェールオーバーグループをレプリカとして作成
- その後、初回複製はスケジュールが設定されていれば自動で実施される
-
アカウントオブジェクトとデータベースの複製
- ORGADMIN権限で以下の実行が必要
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
- ORGADMIN権限で以下の実行が必要
-
ターゲットアカウントのスクリプトによって作成されたオブジェクトにグローバル IDs を適用する
- 複製経由「以外」の方法でターゲットアカウントにアカウントオブジェクトを作成すると、リフレッシュ時に削除される
- これを回避する時の方法が書かれてある
- 初期複製の前に、ターゲットアカウントにのみ存在するユーザーまたはロールを手動でソースアカウントに再作成する
- SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME関数を使用して、両方のアカウントで同じ名前を持つオブジェクトをターゲットアカウントでリンクする
- ユーザーおよびロールの初期複製を行う
- アカウントとデータベースオブジェクトの複製を有効にし、オブジェクトを更新する手順が書いてある
-
API 統合のリモートサービスの更新
- Snowflakeアカウント毎に統合のID/アクセス管理(IAM)エンティティが必要になる
- ソースアカウントで設定した時と同じ要領でターゲットアカウント用の設定が必要
- 各クラウドベンダー毎の設定方法に従って対応する
-
複数のアカウントにわたるセキュリティ統合の複製
- 各種事例が載っているのでそれを参照する
-
ステージ、パイプ、ロード履歴の複製
- こちらは全般的にプレビュー機能とのこと
-
複製コストについて
- ターゲットアカウントで費用が発生する
- データ転送
- リージョン間でデータを転送するのでそのコストがかかる
- こちら参照
- コンピューティングリソース
- データをコピーする際にSnowflakeが提供するコンピュートリソースを使用するのでそのコストがかかる
-
こちら参照
- Table 5: Serverless Feature Credit Table
- ストレージコスト
- セカンダリデータベースのデータの標準ストレージコスト
- クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加する
- 実際にかかったコスト
- 複製に失敗した時
- 失敗までに消費したリソースのコストはもちろんかかる
- 最初の複製またはリフレッシュ操作が失敗する前にコピーされたデータは、その後のリフレッシュ操作(14日以内に実行された場合)で再利用できる
-
アカウントオブジェクトのフェールオーバー
- セカンダリフェールオーバーグループをプライマリフェールオーバーグループに昇格
-
ALTER FAILOVER GROUP...PRIMARY
を実行
-
- ターゲットアカウントでスケジュールされた複製を再開
-
ALTER FAILOVER GROUP...RESUME
を実行
-
- セカンダリフェールオーバーグループをプライマリフェールオーバーグループに昇格
-
ALTER FAILOVER GROUPについて
- フェールオーバーグループのプロパティ変更のために使用する
- ソースアカウントから実行する場合
- セカンダリフェールオーバーグループの自動更新の複製スケジュールを設定または更新する
- 複製とフェールオーバーが有効になっているターゲットアカウントを追加または削除する
- 共有またはデータベースを別のフェールオーバーグループに移動する
- 他、名前変更など
- ターゲットアカウントから実行する場合
- セカンダリフェールオーバーグループをプライマリに昇格する
- オブジェクトのフェールオーバーグループをフェールオーバーする
- ソースアカウントからターゲットアカウントのオブジェクトを手動更新する
- スケジュールされた複製を停止/再開する
- セカンダリフェールオーバーグループをプライマリに昇格する
- ソースアカウントから実行する場合
- 必要な権限
- REFRESH
- フェールオーバーグループの
OWNERSHIP
かREPLICATE
- フェールオーバーグループの
- PRIMARY
- フェールオーバーグループの
OWNERSHIP
かFAILOVER
- フェールオーバーグループの
- データベースをフェールオーバーグループに追加する
- データベースの
MONITOR
- データベースの
- フェールオーバーグループに共有を追加する
- 共有の
OWNERSHIP
- 共有の
- REFRESH
- フェールオーバーグループのプロパティ変更のために使用する
ざっくりポイント
- セカンダリデータベースは、プライマリとは異なるクラウドベンダーおよびリージョンに配置することができる
- セカンダリは読み取り専用
- 昇格してプライマリになると書き込みができる
- レプリケーション時のデータ転送とコンピュートリソースのコストがかかるのはターゲットアカウント(セカンダリ)側
- 外部テーブルに注意
- スケジュールによる自動更新が基本
- 下位エディションへの複製に注意
所感
ん〜なんか難しい。
あんま使わないからイメージも湧きづらい...かといって試すのも結構重いか。
プレビュー機能も多いから、実践的に使われているものなのかどうかよくわからん。
リージョンまたぎやクラウドベンダーまたぎのシェアのためには必須の機能なので、どちらかというとその目的のために使われているのかな(というか使わざるを得ない)