アカウントオブジェクトの複製¶
このトピックでは、同じ組織内のSnowflakeアカウント間でアカウントオブジェクトとデータを複製し、オブジェクトとデータの同期を維持するために必要なステップについて説明します。アカウント複製は、異なる リージョン のSnowflakeアカウント間および クラウドプラットフォーム 間で発生する可能性があります。
注釈
アカウントをBusiness Critical Edition(またはそれ以上)にアップグレードした場合、フェールオーバー機能が利用可能になるまで最大12時間かかる場合があります。
このトピックの内容:
複製およびフェールオーバー/フェールバックのリージョンサポート¶
お客様は、リージョングループ内のリージョン全域で複製できます。異なる リージョングループ のリージョン間で複製するには(例: Snowflake商用リージョンからSnowflake政府リージョンへ)、 Snowflakeサポート に連絡してアクセスを有効にしてください。
データベース複製からグループベース複製への移行¶
ALTER DATABASE を使用して複製が有効になっているデータベースは、複製またはフェールオーバーグループに追加する 前に 複製を無効にする必要があります。
注釈
ACCOUNTADMIN ロールを使用して、このセクションの SQL ステートメントを実行します。
ステップ1:複製が有効なデータベースの複製を無効にする¶
複製またはフェールオーバーグループに追加するために、 SYSTEM$DISABLE_DATABASE_REPLICATION 関数を実行して、プライマリデータベースとそれにリンクされているセカンダリデータベースの複製を無効にします。
プライマリデータベースのソースアカウントから次の SQL ステートメントを実行します。
SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');
ステップ2:データベースをプライマリフェールオーバーグループに追加し、セカンダリフェールオーバーグループを作成する¶
データベースの複製を正常に無効にすると、プライマリデータベースをソースアカウントのフェールオーバーグループに追加できます。
次に、ターゲットアカウントにセカンダリフェールオーバーグループを作成します。セカンダリフェールオーバーグループがターゲットアカウントで更新されると、以前のセカンダリデータベースがセカンダリフェールオーバーグループのメンバーとして自動的に追加され、プライマリデータベースからの変更で更新されます。
プライマリおよびセカンダリフェールオーバーグループの作成の詳細については、 ワークフロー をご参照ください。
注釈
以前に複製されたデータベースを複製またはフェールオーバーグループに追加すると、Snowflakeはそのデータベースに対してすでに複製されたデータを再複製 しません。グループが更新されると、最後の更新以降の変更のみが複製されます。
ワークフロー¶
次の SQL ステートメントは、アカウントとデータベースオブジェクトの複製を有効にし、オブジェクトを更新するためのワークフローを示しています。各ステップについては、以下で詳しく説明します。
注釈
次の例では、ソースアカウントとターゲットアカウントに対して複製を有効にする必要があります。詳細については、 前提条件: 組織内のアカウントの複製を有効にする をご参照ください。
例¶
希望するSnowflakeクライアントで次の SQL ステートメントを実行して、アカウントとデータベースオブジェクトの複製とフェールオーバーを有効にし、オブジェクトを更新します。
ソースアカウントでの実行¶
ロールを作成し、それに CREATE FAILOVER GROUP 権限を付与します。このステップは オプション です。
USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
ソースアカウントにフェールオーバーグループを作成し、特定のターゲットアカウントへの複製を有効にします。
注釈
以前に ALTER DATABASE を使用して、データベースの複製とフェールオーバーが有効になっている複製またはフェールオーバーグループに追加するデータベースがある場合は、グループに追加する前に、 データベース複製からグループベース複製への移行 (このトピック内)の手順に従います。
データベースをフェールオーバーグループに追加するには、データベースに対する MONITOR 権限がアクティブなロールに必要です。データベース権限の詳細については、 データベース権限 (別のトピック内)をご参照ください。
USE ROLE myrole; CREATE FAILOVER GROUP myfg OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES ALLOWED_DATABASES = db1, db2 ALLOWED_ACCOUNTS = myorg.myaccount2, myorg.myaccount3 REPLICATION_SCHEDULE = '10 MINUTE';
ターゲットアカウントでの実行¶
ターゲットアカウントにロールを作成し、それに CREATE FAILOVER GROUP 権限を付与します。このステップは オプション です。
USE ROLE ACCOUNTADMIN; CREATE ROLE myrole; GRANT CREATE FAILOVER GROUP ON ACCOUNT TO ROLE myrole;
ソースアカウントのフェールオーバーグループのレプリカとして、ターゲットアカウントにフェールオーバーグループを作成します。
注釈
ソースアカウントに存在しないアカウントオブジェクト(例: ユーザーまたはロール)がターゲットアカウントに存在する場合は、セカンダリグループを作成する前に ユーザーおよびロールの初期複製 をご参照ください。
USE ROLE myrole; CREATE FAILOVER GROUP myfg AS REPLICA OF myorg.myaccount1.myfg;
セカンダリフェールオーバーグループを手動で更新します。これは オプション のステップです。複製スケジュールを使用してプライマリフェールオーバーグループが作成されている場合は、セカンダリフェールオーバーグループの作成時に、セカンダリフェールオーバーグループの初期更新が自動的に実行されます。
フェールオーバーグループに対する REPLICATE 権限を持つロールを作成します。このステップは オプション です。
フェールオーバーグループに対する OWNERSHIP 権限を持つロールを使用して、ターゲットアカウントで実行します。
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
REPLICATE 権限を持つロールを使用して更新ステートメントを実行します。
USE ROLE my_replication_role; ALTER FAILOVER GROUP myfg REFRESH;
アカウントオブジェクトとデータベースの複製¶
このセクションの手順では、アカウントを複製用に準備する方法、ソースアカウントからターゲットアカウントに特定のオブジェクトを複製できるようにする方法、およびターゲットアカウントのオブジェクトを同期する方法について説明します。
重要
ターゲットアカウントでは、 Tri-Secret Secure またはSnowflakeサービスへのプライベート接続(AWS PrivateLink など)がデフォルトで有効になっていません。コンプライアンス、セキュリティ、またはその他の目的でSnowflakeサービスへのTri-Secret Secureまたはプライベート接続が必要な場合は、ターゲットアカウントでこれらの機能を構成して有効にする責任があります。
前提条件: 組織内のアカウントの複製を有効にする¶
組織管理者(ORGADMIN ロール)は、ソースアカウントとターゲットアカウントの複製を有効にする必要があります。
アカウントの複製を有効にするには、 ORGADMIN ロールを持つユーザーが、 SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 関数を使用して ENABLE_ACCOUNT_DATABASE_REPLICATION
パラメーターを true
に設定します。組織内の複数のアカウントで、同じ ORGADMIN アカウントからの複製を有効にできることに注意してください。
ORGADMIN アカウントにログインして、組織内の各ソースアカウントとターゲットアカウントの複製を有効にします。
USE ROLE ORGADMIN;
-- View the list of the accounts in your organization
-- Note the organization name and account name for each account for which you are enabling replication
SHOW ORGANIZATION ACCOUNTS;
-- Enable replication by executing this statement for each source and target account in your organization
SELECT SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER('<organization_name>.<account_name>', 'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');
SYSTEM$GLOBAL_ACCOUNT_SET_PARAMETER 関数は従来の アカウントロケーター 識別子をサポートしていますが、組織が同じロケーターを共有する複数のアカウントを(異なるリージョンで)持つ場合は、予期しない結果が生じます。
ステップ1: ソースアカウントに CREATE FAILOVER GROUP 権限を持つロールを作成する --- オプション¶
ロールを作成し、それに CREATE FAILOVER GROUP 権限を付与します。このステップはオプションです。このロールをすでに作成している場合は、 ステップ2: ソースアカウントにプライマリフェールオーバーグループを作成する にスキップします。
USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT
TO ROLE myrole;
ステップ2: ソースアカウントにプライマリフェールオーバーグループを作成する¶
プライマリフェールオーバーグループを作成し、現在の(ソース)アカウントから同じ組織内にある1つ以上のターゲットアカウントに、特定のオブジェクトを複製およびフェールオーバーできるようにします。
複製が有効になっているすべてのアカウントを表示する¶
複製が有効になっている組織内のアカウントのリストを取得するには、 SHOW REPLICATION ACCOUNTS を使用します。
ACCOUNTADMIN ロールを使用して次の SQL ステートメントを実行します。
SHOW REPLICATION ACCOUNTS;
戻り値:
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| snowflake_region | created_on | account_name | account_locator | comment | organization_name | is_org_admin |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_WEST_2 | 2020-07-15 21:59:25.455 -0800 | myaccount1 | myacctlocator1 | | myorg | true |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_1 | 2020-07-23 14:12:23.573 -0800 | myaccount2 | myacctlocator2 | | myorg | false |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| AWS_US_EAST_2 | 2020-07-25 19:25:04.412 -0800 | myaccount3 | myacctlocator3 | | myorg | false |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
地域 IDs の包括的なリストをご参照ください。
フェールオーバーと複製グループのメンバーシップを表示する¶
アカウント、データベース、および共有オブジェクトには、 グループメンバーシップの制約 があります。新しいグループを作成したり、既存のグループにオブジェクトを追加したりする前に、既存のフェールオーバーグループと各グループのオブジェクトのリストを確認できます。
注釈
このセクションの SQL ステートメントを実行できるのは、アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)またはグループ所有者(グループに対する OWNERSHIP 権限を持つロール)のみです。
現在のアカウントにリンクされているすべてのフェールオーバーグループと、各グループのオブジェクト型を表示します。
SHOW FAILOVER GROUPS;
フェールオーバーグループ myfg
内のすべてのデータベースを表示します。
SHOW DATABASES IN FAILOVER GROUP myfg;
フェールオーバーグループ myfg
内のすべての共有を表示します。
SHOW SHARES IN FAILOVER GROUP myfg;
ソースアカウントからターゲットアカウントへのアカウントおよびデータベースオブジェクトの複製を有効にする¶
ソースアカウントに指定されたアカウントとデータベースオブジェクトのフェールオーバーグループを作成し、ターゲットアカウントのリストへの複製とフェールオーバーを有効にします。構文については、 CREATE FAILOVER GROUP をご参照ください。
たとえば、同じ組織内のソースアカウントから myaccount2
アカウントへのユーザー、ロール、ウェアハウス、リソースモニター、およびデータベース db1
および db2
の複製を有効にします。10分ごとに myaccount2
を自動的に更新するように複製スケジュールを設定します。
注釈
以前に ALTER DATABASE を使用してデータベース複製が有効になっている複製またはフェールオーバーグループに追加するデータベースがある場合は、グループに追加する前に、 データベース複製からグループベース複製への移行 (このトピック内)の手順に従います。
ソースアカウントで実行:
USE ROLE myrole;
CREATE FAILOVER GROUP myfg
OBJECT_TYPES = USERS, ROLES, WAREHOUSES, RESOURCE MONITORS, DATABASES, INTEGRATIONS, NETWORK POLICIES
ALLOWED_DATABASES = db1, db2
ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS
ALLOWED_ACCOUNTS = myorg.myaccount2
REPLICATION_SCHEDULE = '10 MINUTE';
ステップ3: ターゲットアカウントに CREATE FAILOVER GROUP 権限を持つロールを作成する ---オプション¶
ターゲットアカウントにロールを作成し、それに CREATE FAILOVER GROUP 権限を付与します。このステップはオプションです。このロールをすでに作成している場合は、 ステップ4: ターゲットアカウントにセカンダリフェールオーバーグループを作成する にスキップします。
USE ROLE ACCOUNTADMIN;
CREATE ROLE myrole;
GRANT CREATE FAILOVER GROUP ON ACCOUNT
TO ROLE myrole;
ステップ4: ターゲットアカウントにセカンダリフェールオーバーグループを作成する¶
注釈
ソースアカウントに存在しないアカウントオブジェクト(例: ユーザーまたはロール)がターゲットアカウントに存在する場合は、セカンダリグループを作成する前に ユーザーおよびロールの初期複製 をご参照ください。
ソースアカウントにあるプライマリフェールオーバーグループのレプリカとして、ターゲットアカウントにセカンダリフェールオーバーグループを作成します。
ステップ2: ソースアカウントにプライマリフェールオーバーグループを作成する (このトピック内)で複製を有効にした各ターゲットアカウントで、 CREATE FAILOVER GROUP...AS REPLICA OF ステートメントを実行します。
各ターゲットアカウントから実行:
USE ROLE myrole;
CREATE FAILOVER GROUP myfg
AS REPLICA OF myorg.myaccount1.myfg;
ステップ5:ターゲットアカウントにセカンダリフェールオーバーグループを手動で更新する --- オプション¶
ターゲットアカウント内のオブジェクトを手動で更新するには、 ALTER FAILOVER GROUP...REFRESH コマンドを実行します。
ベストプラクティスとして、 CREATE FAILOVER GROUP または ALTER FAILOVER GROUP を使用して REPLICATION_SCHEDULE パラメーターを設定することにより、セカンダリの更新をスケジュールするようにお勧めします。
注釈
ターゲットアカウントで関数を呼び出したユーザーがソースアカウントでドロップされた場合は、更新操作に失敗します。
フェールオーバーグループの REPLICATE 権限をロールに付与する --- オプション¶
コマンドを実行してターゲットアカウントのセカンダリ複製またはフェールオーバーグループを更新するには、フェールオーバーグループに対する REPLICATE 権限を持つロールを使用する必要があります。現在、 REPLICATE 権限は複製 されない ため、ソースアカウントとターゲットアカウントの両方のフェールオーバー(または複製)グループで付与する必要があります。
グループに対する OWNERSHIP 権限を持つロールを使用して、このステートメントをソースアカウントから実行します。
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;グループに対する OWNERSHIP の権限を持つロールを使用して、このステートメントをターゲットアカウントから実行します。
GRANT REPLICATE ON FAILOVER GROUP myfg TO ROLE my_replication_role;
セカンダリフェールオーバーグループを手動で更新する¶
たとえば、フェールオーバーグループ myfg
内のオブジェクトを更新するには、ターゲットアカウントから次のステートメントを実行します。
USE ROLE my_replication_role; ALTER FAILOVER GROUP myfg REFRESH;
ターゲットアカウントのスクリプトによって作成されたオブジェクトにグローバル IDs を適用する¶
複製経由 以外 の方法(例: スクリプトを使用)でターゲットアカウントにユーザーやロールなどのアカウントオブジェクトを作成した場合、これらのユーザーとロールにはデフォルトでグローバル識別子がありません。更新操作は、グローバル識別子を使用して、これらのオブジェクトをソースアカウント内の同じオブジェクトに同期します。
大半の場合、ターゲットアカウントがソースアカウントからリフレッシュされると、リフレッシュ操作により、グローバル識別子を持たないターゲットアカウント内の OBJECT_TYPES
リストにあるすべてのアカウントオブジェクト型が ドロップ されます。ただし、ターゲットアカウントへのユーザーとロールの最初の複製では、初期のリフレッシュ操作に失敗する可能性があります。この動作に関する詳細については、 ユーザーおよびロールの初期複製 をご参照ください。
SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() を使用してグローバル IDs を適用する¶
ソースアカウントとターゲットアカウントで同名の一致するオブジェクトをリンクすると、一部のオブジェクト型の欠落を防ぐことができます。SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数は、グローバル識別子をターゲットのアカウントオブジェクトに追加します。
注釈
グローバル識別子は、次のオブジェクト型の複製またはフェールオーバーグループに含まれるアカウントオブジェクトにのみ追加されます。
RESOURCE_MONITOR
ROLE
USER
WAREHOUSE
グローバル識別子を、フェールオーバーグループ myfg
の object_types
リストに含まれる型のターゲットアカウント内にあるアカウントオブジェクトに適用します。
ACCOUNTADMIN ロールを使用して次の SQL ステートメントを実行します。
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');
ユーザーおよびロールの初期複製¶
USERS および ROLES オブジェクト型の初期リフレッシュ操作の動作は、ターゲットアカウントに同名の一致するオブジェクトがあるかどうかによって異なる場合があります。
注釈
このセクションで説明する動作は、これらのオブジェクト型がターゲットアカウントに複製される 最初 の回にのみ適用されます。
以下のシナリオでは、 USERS の複製について説明します。ROLES の複製も同様です。
ソースアカウントにあるユーザーと同名のユーザーがターゲットアカウントに存在する場合は、初期リフレッシュ操作に失敗し、継続するために必要なオプション2つが説明されます。
リフレッシュ操作を強制し、ターゲットアカウントにある既存ユーザーのドロップを許可します。ソースアカウントにあるユーザーが、ターゲットアカウントに複製されます。
グループを強制的にリフレッシュするには、リフレッシュコマンドの FORCE パラメーターを使用します。たとえば、フェールオーバーグループを強制的にリフレッシュするには、以下のコマンドを実行します。
ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
名前でアカウントオブジェクトをリンクします。 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数は、ターゲットアカウントとソースアカウントで同じ名前を持つユーザーをリンクします。リンクされているターゲットアカウントのユーザーは削除されません。
アカウントオブジェクトを名前でリンクするには、次のコマンドを実行します。
SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
注釈
ソースアカウントに一致する名前の ない ターゲットアカウントのユーザーは、すべて ドロップ されます。
ソースアカウントにあるユーザーと同名のユーザーがターゲットアカウントに存在 しない 場合は、ターゲットアカウントでの初期リフレッシュ操作によりすべてのユーザーがドロップされます。これにより、データやメタデータが失われる可能性があります。
複製またはフェールオーバーグループの OBJECT_TYPES リストに USERS が含まれている場合は、
ワークシートが失われます。
クエリの履歴が失われます。
OBJECT_TYPES に USERS は含まれるが、 ROLES は含まれない場合は、
ユーザーへの権限付与が失われます。
OBJECT_TYPES に ROLES が含まれる場合は、
オブジェクトを共有するための権限付与は失われます。
ターゲットアカウントでユーザーまたはロールのドロップを回避するには、
初期複製の前に、ターゲットアカウントに のみ 存在するユーザーまたはロールを手動でソースアカウントに再作成します。
SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数を使用して、両方のアカウントで同じ名前を持つオブジェクトをターゲットアカウントでリンクします。
セカンダリストレージ統合のためのクラウドストレージアクセスの構成¶
ストレージ統合複製を有効にしている場合は、ストレージ統合がターゲットアカウントに複製された後に追加の手順を実行する必要があります。複製された統合には、プライマリ統合のIDおよび IAM エンティティとは異なる独自のIDおよびアクセス管理(IAM)エンティティがあります。したがって、クラウドプロバイダーの権限を更新して、複製された統合にクラウドストレージへのアクセス権を付与する必要があります。
この信頼関係の構成は、ターゲットアカウントに対して1回のみ行う必要があります。
このプロセスは、ソースアカウントでアクセスを許可するのと似ています。詳細については、次のページをご参照ください。
セカンダリステージでのディレクトリテーブルの自動リフレッシュの構成¶
外部ステージをディレクトリテーブルで複製し、ソースディレクトリテーブルに自動リフレッシュを構成した場合、セカンダリディレクトリテーブルに 自動リフレッシュ を構成する手順を実行する必要があります。
このプロセスは、ソースアカウントで自動リフレッシュを設定するのと似ています。詳細については、次をご参照ください。
Amazon S3: 構成プロセスは、イベント通知の設定方法に応じて異なります。
Amazon Simple Queue Service(SQS)でAmazon S3イベント通知を使用している場合は ステップ2: イベント通知を構成する の手順に従ってください。
Amazon Simple Notification Service(SNS)を使用している場合は、 Snowflake SQS キューを SNS トピックにサブスクライブする をご参照ください。
Google Cloud Storage: Pub/Subトピックに新しいサブスクリプションを作成し、ターゲットアカウントに新しい通知統合を作成します。次に、SnowflakeにPub/Subサブスクリプションへのアクセス権を付与します。手順については、 GCS Pub/Subを使用した自動化の構成 をご参照ください。
Azure Blob Storage: 新しいEvent Gridサブスクリプションとストレージキューを作成します。次に、ターゲットアカウントで新しい通知統合を作成し、Snowflakeにストレージキューへのアクセス権を付与します。手順については、 Azure Event Gridを使用した自動化の構成 をご参照ください。
重要
ターゲットアカウントでこれらの構成手順を完了した後、ディレクトリテーブルの完全なリフレッシュを実行し、通知漏れがないことを確認する必要があります。
Google Cloud StorageとAzure Blob Storageの場合、各ターゲットアカウントの通知統合名は、ソースアカウントの通知統合名と一致する必要があります。
セカンダリ自動インジェストパイプの通知構成¶
フェールオーバーの前に、セカンダリ自動インジェストパイプのクラウド通知を構成するための追加の手順を実行する必要があります。このセクションでは、この追加構成が必要な理由と、サポートされている各クラウドプロバイダーで構成を完了する方法について説明します。
Amazon S3¶
構成プロセスは、イベント通知の設定方法に応じて異なります。たとえば、Snowflakeステージの場所に関するメッセージを公開するためにAmazon Simple Notification Service(SNS)トピックに依存する自動インジェストパイプがあるとします。
パイプをターゲットアカウントに複製すると、Snowflakeは自動的に新しいAmazon Simple Queue Service(SQS)キューを作成します。ステージの場所に関する通知を受け取るには、ターゲットアカウントのこの SQS キューを SNS トピックにサブスクライブする必要があります。
Amazon Simple Queue Service(SQS)でAmazon S3イベント通知を使用している場合は ステップ4:イベント通知を構成する の手順に従ってください。
重要
パイプが通知を見逃していないことを確認するために、新しい SQS キューに切り替えた後、パイプをリフレッシュする必要があります。
Amazon Simple Notification Service(SNS)を使用している場合は、 Snowflake SQS キューを SNS トピックにサブスクライブする をご参照ください。
Amazon EventBridgeを使用している場合は、 オプション3: Snowpipeを自動化するためにAmazon EventBridge を設定する をご参照ください。
Microsoft Azure Blob Storage¶
Microsoft Azure Blob Storageのステージにあるファイルからデータを自動的にロードするパイプには、Event Gridサブスクリプション、ストレージキュー、ストレージキューにバインドされた通知統合が必要です。ターゲットアカウントのセカンダリパイプには、個別のEvent Grid、ストレージキュー、ストレージキューにバインドされた通知統合が必要です。ソースアカウントとターゲットアカウントの両方のEvent Gridが、同じAzure Storageソースのエンドポイントとして構成されている必要があります。
構成の詳細については、下図を参照してください。
Azure Event Gridを使用した自動化の構成 の詳細な手順に従って、Event Gridのサブスクリプションと通知統合を構成します。
重要
各ターゲットアカウントの通知統合の名前は、ソースアカウントの通知統合の名前と 一致する必要があります。
Google Cloud Storageの外部ステージ¶
Google Cloud Storageにあるファイルからデータを自動的にロードするパイプには、Google Pub/Subサブスクリプションと、そのサブスクリプションを参照する通知統合が必要です。ターゲットアカウントの複製された各パイプには、Google Pub/Subサブスクリプションと、そのサブスクリプションを参照する通知統合も必要です。各ソースおよびターゲットアカウントのPub/Subサブスクリプションは、Google Cloud Storageソースからの通知を受信する同じPub/Subトピックにサブスクライブする必要があります。
構成の詳細については、下図を参照してください。
Pub/Subサブスクリプションの作成と通知統合の詳細な手順については、 GCS Pub/Subを使用した自動化の構成 をご参照ください。
重要
各ターゲットアカウントの通知統合の名前は、ソースアカウントの通知統合の名前と 一致する必要があります。
API 統合のリモートサービスを更新する¶
API 統合複製を有効にしている場合は、 API 統合がターゲットアカウントに複製された後で追加のステップが必要です。複製された統合には、プライマリ統合のIDおよび IAM エンティティとは異なる独自のIDおよびアクセス管理(IAM)エンティティがあります。したがって、複製された関数へのアクセスを許可するには、リモートサービスの権限を更新する必要があります。このプロセスは、プライマリアカウントの関数へのアクセスを許可するのと似ています。詳細については、以下のリンクをご参照ください。
Amazon Web Services Snowflakeと新しい IAM ロールの間における信頼関係の設定。
Google Cloud Platform: プロキシサービスの GCP セキュリティポリシーを作成する。
Microsoft Azure:
ステップ1: Azureの API 統合をリンクする
ステップ2: JWT 検証ポリシーを作成する
複製のモニター¶
このセクションでは、アカウントの複製の進行状況、履歴、およびコストをモニターする方法について説明します。
複製グループまたはフェールオーバーグループの更新の進行状況をモニターする¶
複製またはフェールオーバーグループの更新の進行状況をモニターするには、 REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB テーブル関数(Snowflake Information Schema 内)をクエリします。
例¶
フェールオーバーグループ myfg
に対する最新の更新操作の進行状況を表示します。
SELECT PHASE_NAME, START_TIME, END_TIME, PROGRESS, DETAILS
FROM TABLE(information_schema.replication_group_refresh_progress('myfg'));
複製履歴¶
指定した日付範囲内の特定の複製またはフェールオーバーグループの複製履歴を表示するには、次のいずれかをクエリします。
例¶
Information Schema REPLICATION_GROUP_REFRESH_HISTORY テーブル関数をクエリして、過去7日間のフェールオーバーグループ myfg
のアカウント複製履歴を表示します。
SELECT PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM TABLE(information_schema.replication_group_refresh_history('myfg'))
WHERE START_TIME >= current_date - interval '7 days';
Account Usage REPLICATION_GROUP_REFRESH_HISTORY ビューをクエリして、当月のアカウント複製履歴を表示します。
SELECT REPLICATION_GROUP_NAME, PHASE_NAME, START_TIME, END_TIME, TOTAL_BYTES, OBJECT_COUNT
FROM snowflake.account_usage.replication_group_refresh_history
WHERE START_TIME >= date_trunc('month', current_date());
複製コストをモニターする¶
複製のクレジット使用状況をモニターするには、次のいずれかをクエリします。
例¶
REPLICATION_GROUP_USAGE_HISTORY テーブル関数をクエリして、過去7日間にアカウントの複製に使用されたクレジットを表示します。
SELECT start_time, end_time, replication_group_name, credits_used, bytes_transferred
FROM table(information_schema.replication_group_usage_history(date_range_start=>dateadd('day', -7, current_date())));
Account Usage REPLICATION_GROUP_USAGE_HISTORY ビューをクエリして、当月内にアカウント複製履歴のために、複製またはフェールオーバーグループによって使用されたクレジットを表示します。
SELECT start_time,
end_time,
replication_group_name,
credits_used,
bytes_transferred
FROM snowflake.account_usage.replication_group_usage_history
WHERE start_time >= DATE_TRUNC('month', CURRENT_DATE());
データベースの複製コストをモニターする¶
複製またはフェールオーバーグループに含まれる個別データベースの複製のコストは、データベースのコピーされたバイト数を取得し、それを使用されたクレジットに関連付けることによって計算できます。
例¶
Account Usageビューのクエリ¶
次の例では、過去30日間における複製グループ1つのデータベース複製のコストを計算します。
REPLICATION_GROUP_REFRESH_HISTORY Account Usageビューをクエリして、データベースごとに複製されたバイト数の合計を計算します。
たとえば、過去30日間に複製グループ
myrg
内のデータベースで複製されたバイト数の合計を計算するには、次を実行します。select sum(value:totalBytesToReplicate) as sum_database_bytes from snowflake.account_usage.replication_group_refresh_history rh, lateral flatten(input => rh.total_bytes:databases) where rh.replication_group_name = 'MYRG' and rh.start_time >= current_date - interval '30 days';
データベースバイトの合計の出力に注意してください。
+--------------------+ | SUM_DATABASE_BYTES | |--------------------| | 22016 | +--------------------+
REPLICATION_GROUP_USAGE_HISTORY Account Usageビューをクエリして、使用されたクレジット数の合計と、複製のために転送されたバイトの合計を計算します。
たとえば、過去30日間に使用されたクレジット数の合計と、複製グループ
myrg
の複製のために転送されたバイトの合計を計算するには、次を実行します。select sum(credits_used) as credits_used, SUM(bytes_transferred) as bytes_transferred from snowflake.account_usage.replication_group_usage_history where replication_group_name = 'MYRG' and start_time >= current_date - interval '30 days';
使用されたクレジットの合計と転送されたバイトの合計の出力に注意してください。
+--------------+-------------------+ | CREDITS_USED | BYTES_TRANSFERRED | |--------------+-------------------| | 1.357923604 | 22013 | +--------------+-------------------+
データベースに転送されたバイトの値、使用されたクレジットの合計、および前の2つのステップから複製のために転送されたすべてのバイトの合計を使用して、データベースの複製コストを計算します。
(<転送されたデータのバイト> / <転送されたバイト>) * <使用されたクレジット>
例:
(22016 / 22013) * 1.357923604 = 1.35810866)
Information Schemaテーブル関数のクエリ¶
過去14日以内の更新操作の場合は、関連するInformation Schemaテーブル関数をクエリします。
REPLICATION_GROUP_REFRESH_HISTORY テーブル関数をクエリして、複製グループ
myrg
のデータベース複製用にコピーされたバイト数の合計を表示します。select sum(value:totalBytesToReplicate) from table(information_schema.replication_group_refresh_history('myrg')) as rh, lateral flatten(input => total_bytes:databases) where rh.phase_name = 'COMPLETED' and rh.start_time >= current_date - interval '14 days';
REPLICATION_GROUP_USAGE_HISTORY テーブル関数をクエリして、使用されたクレジット数の合計と、複製グループ
myrg
の複製のために転送されたバイトの合計を表示します。select sum(credits_used), sum(bytes_transferred) from table(information_schema.replication_group_usage_history( date_range_start=>dateadd('day', -14, current_date()), replication_group_name => 'myrg' ));
プライマリデータベースとセカンダリデータベースのデータセットの比較¶
データベースオブジェクトが複製グループまたはフェールオーバーグループで複製される場合は、 HASH_AGG 関数を使用して、プライマリデータベースとセカンダリデータベースにあるテーブルのランダムセットの行を比較し、データの一貫性を確認できます。 HASH_AGG 関数は、入力行の(順序付けられていない)セットの署名付き64ビットハッシュ値の集合を返します。セカンダリデータベースとプライマリデータベースのテーブルのすべてまたはランダムなサブセット(プライマリデータベーススナップショットのタイムスタンプ時点)でこの関数をクエリし、出力を比較します。
例¶
以下の例では、データベース mydb
はフェールオーバーグループ myfg
に含まれています。テーブル mydb
を含んでいるデータベース mytable
。
ターゲットアカウントでの実行¶
REPLICATION_GROUP_REFRESH_PROGRESS テーブル関数(Snowflake Information Schema 内)をクエリします。
PRIMARY_UPLOADING_METADATA
フェーズのDETAILS
列にあるprimarySnapshotTimestamp
に注意してください。これは、プライマリデータベースの最新スナップショットのタイムスタンプです。SELECT PARSE_JSON(details)['primarySnapshotTimestamp'] FROM TABLE(information_schema.replication_group_refresh_progress('myfg')) WHERE PHASE_NAME = 'PRIMARY_UPLOADING_METADATA';
セカンダリデータベースにある指定されたテーブルの HASH_AGG 関数をクエリします。次のクエリは、
mytable
テーブル内にあるすべての行のハッシュ値を返します。SELECT HASH_AGG( * ) FROM mytable;
ソースアカウントでの実行¶
プライマリデータベースにある同じテーブルの HASH_AGG 関数をクエリします。Time Travelを使用して、セカンダリデータベースの最新のスナップショットが作成されたときのタイムスタンプを指定します。
SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => '<primarySnapshotTimestamp>'::TIMESTAMP);
2つのクエリの結果を比較します。出力は同一である必要があります。
セカンダリ複製またはフェールオーバーグループのドロップ¶
DROP REPLICATION GROUP または DROP FAILOVER GROUP コマンドを使用して、セカンダリ複製またはフェールオーバーをドロップできます。グループをドロップできるのは、複製またはフェールオーバーグループの所有者(つまり、グループに対する OWNERSHIP 権限を持つロール)のみです。
プライマリ複製またはフェールオーバーグループのドロップ¶
プライマリ複製またはフェールオーバーグループは、グループのすべてのレプリカ(つまり、セカンダリ複製またはフェールオーバーグループ)がドロップされた後にのみドロップできます。または、セカンダリフェールオーバーグループを昇格してプライマリフェールオーバーグループとして機能させてから、以前のプライマリフェールオーバーグループをドロップすることもできます。
グループ所有者のみがグループをドロップできることに注意してください。