アカウントオブジェクトの複製¶

ステップ1:複製が有効なデータベースの複製を無効にする¶

複製またはフェールオーバーグループに追加するために、 SYSTEM$DISABLE_DATABASE_REPLICATION 関数を実行して、プライマリデータベースとそれにリンクされているセカンダリデータベースの複製を無効にします。

プライマリデータベースのソースアカウントから次の SQL ステートメントを実行します。

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

ステップ2:データベースをプライマリフェールオーバーグループに追加し、セカンダリフェールオーバーグループを作成する¶

データベースの複製を正常に無効にすると、プライマリデータベースをソースアカウントのフェールオーバーグループに追加できます。

次に、ターゲットアカウントにセカンダリフェールオーバーグループを作成します。セカンダリフェールオーバーグループがターゲットアカウントで更新されると、以前のセカンダリデータベースがセカンダリフェールオーバーグループのメンバーとして自動的に追加され、プライマリデータベースからの変更で更新されます。

プライマリおよびセカンダリフェールオーバーグループの作成の詳細については、 ワークフロー をご参照ください。

例¶

希望するSnowflakeクライアントで次の SQL ステートメントを実行して、アカウントとデータベースオブジェクトの複製とフェールオーバーを有効にし、オブジェクトを更新します。

前提条件: 組織内のアカウントの複製を有効にする¶

組織管理者（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;

+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+
| 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        |
+------------------+-------------------------------+--------------+-----------------+-----------------+-------------------+--------------+

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 パラメーターを設定することにより、セカンダリの更新をスケジュールするようにお勧めします。

SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME() を使用してグローバル IDs を適用する¶

ソースアカウントとターゲットアカウントで同名の一致するオブジェクトをリンクすると、一部のオブジェクト型の欠落を防ぐことができます。SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数は、グローバル識別子をターゲットのアカウントオブジェクトに追加します。

グローバル識別子を、フェールオーバーグループ myfg の object_types リストに含まれる型のターゲットアカウント内にあるアカウントオブジェクトに適用します。

ACCOUNTADMIN ロールを使用して次の SQL ステートメントを実行します。

SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('myfg');

ユーザーおよびロールの初期複製¶

USERS および ROLES オブジェクト型の初期リフレッシュ操作の動作は、ターゲットアカウントに同名の一致するオブジェクトがあるかどうかによって異なる場合があります。

• ソースアカウントにあるユーザーと同名のユーザーがターゲットアカウントに存在する場合は、初期リフレッシュ操作に失敗し、継続するために必要なオプション2つが説明されます。

  • リフレッシュ操作を強制し、ターゲットアカウントにある既存ユーザーのドロップを許可します。ソースアカウントにあるユーザーが、ターゲットアカウントに複製されます。

    グループを強制的にリフレッシュするには、リフレッシュコマンドの FORCE パラメーターを使用します。たとえば、フェールオーバーグループを強制的にリフレッシュするには、以下のコマンドを実行します。

    ALTER FAILOVER GROUP <fg_name> REFRESH FORCE;
    

    Copy

  • 名前でアカウントオブジェクトをリンクします。 SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数は、ターゲットアカウントとソースアカウントで同じ名前を持つユーザーをリンクします。リンクされているターゲットアカウントのユーザーは削除されません。

    アカウントオブジェクトを名前でリンクするには、次のコマンドを実行します。

    SELECT SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME('<rg_name>');
    

    Copy

    注釈

    ソースアカウントに一致する名前の ない ターゲットアカウントのユーザーは、すべて ドロップ されます。

• ソースアカウントにあるユーザーと同名のユーザーがターゲットアカウントに存在 しない 場合は、ターゲットアカウントでの初期リフレッシュ操作によりすべてのユーザーがドロップされます。これにより、データやメタデータが失われる可能性があります。

  • 複製またはフェールオーバーグループの OBJECT_TYPES リストに USERS が含まれている場合は、

    • ワークシートが失われます。

    • クエリの履歴が失われます。

  • OBJECT_TYPES に USERS は含まれるが、 ROLES は含まれない場合は、

    • ユーザーへの権限付与が失われます。

  • OBJECT_TYPES に ROLES が含まれる場合は、

    • オブジェクトを共有するための権限付与は失われます。

ターゲットアカウントでユーザーまたはロールのドロップを回避するには、

1. 初期複製の前に、ターゲットアカウントに のみ 存在するユーザーまたはロールを手動でソースアカウントに再作成します。

2. SYSTEM$LINK_ACCOUNT_OBJECTS_BY_NAME 関数を使用して、両方のアカウントで同じ名前を持つオブジェクトをターゲットアカウントでリンクします。

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を使用した自動化の構成 をご参照ください。

複製グループまたはフェールオーバーグループの更新の進行状況をモニターする¶

複製またはフェールオーバーグループの更新の進行状況をモニターするには、 REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB テーブル関数（Snowflake Information Schema 内）をクエリします。

SELECT PHASE_NAME, START_TIME, END_TIME, PROGRESS, DETAILS
  FROM TABLE(information_schema.replication_group_refresh_progress('myfg'));

複製履歴¶

指定した日付範囲内の特定の複製またはフェールオーバーグループの複製履歴を表示するには、次のいずれかをクエリします。

• REPLICATION_GROUP_REFRESH_HISTORY テーブル関数（Snowflake Information Schema 内）。

• REPLICATION_GROUP_REFRESH_HISTORY ビュー （Account Usage 内）。

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';

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 ビュー （Account Usage 内）。

• REPLICATION_GROUP_USAGE_HISTORY テーブル関数（Snowflake Information Schema 内）。

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())));

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());

データベースの複製コストをモニターする¶

複製またはフェールオーバーグループに含まれる個別データベースの複製のコストは、データベースのコピーされたバイト数を取得し、それを使用されたクレジットに関連付けることによって計算できます。

例¶

以下の例では、データベース mydb はフェールオーバーグループ myfg に含まれています。テーブル mydb を含んでいるデータベース mytable。