複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製¶

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

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

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

SELECT SYSTEM$DISABLE_DATABASE_REPLICATION('mydb');

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

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

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

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

例¶

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

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

組織管理者は、ソースアカウントとターゲットアカウントの複製を有効にする必要があります。

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

ステップ6:フェールオーバーグループの FAILOVER 権限をロールに付与する --- オプション¶

コマンドを実行してターゲットアカウントのセカンダリフェールオーバーグループをフェールオーバーするには、フェールオーバーグループに対する FAILOVER 権限 を持つロールを使用する必要があります。FAILOVER 権限は現在複製 されず、ソースとターゲットの各アカウントで付与する必要があります。

詳細については、 ロールと付与の複製 をご参照ください。

例えば、フェールオーバーグループ my_fg 上のロール my_failover_role に FAILOVER 権限を付与するには、 ターゲットアカウント で、グループ上の OWNERSHIP 権限を持つロールを使用して、以下のステートメントを実行します。

GRANT FAILOVER ON FAILOVER GROUP myfg TO ROLE my_failover_role;

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

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

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 キューに切り替えた後、パイプをリフレッシュする必要があります。

  SQS から SNS に移行することもできます。詳細については、 Amazon Simple Notification Service（SNS）への移行 をご参照ください。

• 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ソースのエンドポイントとして構成されている必要があります。

構成の詳細については、下図を参照してください。

新しいEvent Gridサブスクリプションとストレージキューを作成します。次に、ターゲットアカウントで新しい通知統合を作成し、Snowflakeにストレージキューへのアクセス権を付与します。手順については、 Azure Event Gridを使用した自動化の構成 をご参照ください。

Google Cloud Storageの外部ステージ¶

Google Cloud Storageにあるファイルからデータを自動的にロードするパイプには、Google Pub/Subサブスクリプションと、そのサブスクリプションを参照する通知統合が必要です。ターゲットアカウントの複製された各パイプには、Google Pub/Subサブスクリプションと、そのサブスクリプションを参照する通知統合も必要です。各ソースおよびターゲットアカウントのPub/Subサブスクリプションは、Google Cloud Storageソースからの通知を受信する同じPub/Subトピックにサブスクライブする必要があります。

構成の詳細については、下図を参照してください。

Pub/Subトピックに新しいサブスクリプションを作成し、ターゲットアカウントに新しい通知統合を作成します。

次に、SnowflakeにPub/Subサブスクリプションへのアクセス権を付与します。手順については、 GCS Pub/Subを使用した自動化の構成 をご参照ください。

例¶

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

Snowsightを使用した、ソースアカウントの複製グループまたはフェールオーバーグループの変更¶

これらのアクションを実行するには、ソースアカウントにサインインしている必要があります。サインインしていない場合、 Status 列にはリフレッシュステータスの代わりにサインインメッセージが表示されます。

1. Snowsight にサインインし、 Admin » Accounts に移動します。

2. Replication を選択してから、 Groups を選択します。

3. 編集する複製グループまたはフェールオーバーグループを探し、行の最後の列にある More メニュー（...）を選択します。

4. Edit を選択します。

5. グループ名を変更するには、 Group Name ボックスに以下の条件を満たす新しい名前を入力します。

   • 識別子文字列が二重引用符で囲まれていない限り（例えば、"My object"）、アルファベット文字で始まる必要があり、スペースや特殊文字を含めることはできません。二重引用符で囲まれた識別子も大文字と小文字が区別されます。

     詳細については、 識別子の要件 をご参照ください。

   • アカウント内のフェールオーバーグループと複製グループの名前は一意にする必要があります。

6. 共有オブジェクトとアカウントオブジェクトを追加または削除するには、 Select Objects を選択します。

   注釈

   アカウントオブジェクトは、1つの複製グループまたはフェールオーバーグループにのみ追加できます。アカウントオブジェクトを持つ複製グループまたはフェイルオーバーグループがアカウントに既に存在する場合、それらのオブジェクトを選択することはできません。

7. データベースオブジェクトを追加または削除するには、 Select Databases を選択します。

8. グループの複製スケジュールを変更するには、 Replication Frequency を選択します。

9. Save Changes を選択してグループを更新します。

   グループへの変更の保存に失敗した場合は、よくあるエラーとその解決方法について Snowsightを使用した複製グループの作成と編集に関する問題のトラブルシューティング を参照してください。

SQL を使用した、ソースアカウントの複製グループまたはフェールオーバーグループの変更¶

複製グループまたはフェイルオーバーグループのプロパティは、 ALTER REPLICATION GROUP または ALTER FAILOVER GROUP コマンドを使用して変更できます。

Snowsightを使用したターゲットアカウントでの複製スケジュールの一時停止または再開¶

複製スケジュールを一時停止または再開するには、ターゲットアカウントにサインインしている必要があります。

1. Snowsight にサインインし、 Admin » Accounts に移動します。

2. Replication を選択してから、 Groups を選択します。

3. 編集する複製グループまたはフェールオーバーグループを探し、行の最後の列にある More メニュー（...）を選択します。

4. Pause または Resume を選択します。

SQL を使用したターゲットアカウントでの複製スケジュールの一時停止または再開¶

ALTER REPLICATION GROUP または ALTER FAILOVER GROUP コマンドを使用して、ターゲットアカウントの複製スケジュールを一時停止または再開できます。一時停止するには、 SUSPEND パラメーターを指定します。再開するには、 RESUME パラメーターを指定します。

SQL を使用したプライマリ複製グループまたはフェールオーバーグループのドロップ¶

プライマリ複製またはフェールオーバーグループは、グループのすべてのレプリカ（つまり、セカンダリ複製またはフェールオーバーグループ）がドロップされた後にのみドロップできます。または、セカンダリフェールオーバーグループを昇格してプライマリフェールオーバーグループとして機能させてから、以前のプライマリフェールオーバーグループをドロップすることもできます。

グループ所有者のみがグループをドロップできることに注意してください。

Snowsightを使用した複製グループまたはフェールオーバーグループのドロップ¶

プライマリ複製グループまたはフェイルオーバーグループと、リンクされているセカンダリグループを削除できます。

1. Snowsight にサインインし、 Admin » Accounts に移動します。

2. Replication を選択してから、 Groups を選択します。

3. 削除する複製グループまたはフェイルオーバーグループを探します。行の最後の列で More メニュー (...) を選択します。

4. Drop を選択してから、 Drop Group を選択します。

データベースをグループに追加することはできません¶

Database '<database_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.

Cannot directly add previously replicated object '<database_name>' to a
replication group. Please use the provided system functions to convert
this object first.

グループに共有を追加することはできません¶

Share '<share_name>' is already configured to replicate to
account '<account_name>' by replication group '<group_name>'.