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

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

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

Snowsightを使用した複製をモニターする¶

組織内の 複製グループおよびフェイルオーバーグループ の複製の進行状況とステータスをモニターするには、 Snowsight の Replication ページを使用します。

リフレッシュ操作のステータスと詳細を表示できます。

• 最新のリフレッシュ操作の現在のステータスを表示します。

• レプリカのタイムラグ (最後のリフレッシュ操作からの時間) を表示します。

• レプリカのタイムラグのグループ間の分布を表示します。

• スケジュールされた次回リフレッシュ操作の日時を表示します。

各複製グループまたはフェイルオーバーグループの複製ステータスを表示するには、以下のステップを完了します。

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

2. Replication 、 Groups の順に選択します。

Groups ページには、 リフレッシュ操作の詳細 が、あなたのロールに表示権限があるすべてのグループに対して表示されます。タイルを使って表示を絞り込むことができます。

• たとえば、 Status タイルが失敗したリフレッシュ操作があることを示している場合、そのタイルを選択して失敗したグループを調査できます。

• Longest Replication lag タイルのタイムラグは、最後のリフレッシュ操作からの時間を指します。これは、セカンダリ複製グループまたはフェイルオーバーグループがプライマリグループに 遅れる 時間の長さです。最も長いタイムラグは、最も古いセカンダリ複製グループが最後にリフレッシュされてからの時間の長さです。

  たとえば、 fg_1 、 fg_2 、 fg_3 の3つのフェイルオーバーグループがあり、それぞれ独立した複製スケジュールが10分、2時間、12時間である場合、最長タイムラグは12時間にもなります。ただし、 fg_3 が、ターゲットアカウントで最近リフレッシュされた場合は、タイラムラグが0にリセットされ、別のフェイルオーバーグループではタイムラグが長くなる可能性があります。

• Group Lag Distribution タイルで個々のバーを選択すると、結果を個々のグループに絞り込むことができます。

検索フィールドやドロップダウンメニューを使用してグループを絞り込むこともできます。

• (検索) ボックスを使用して、複製グループまたはフェイルオーバーグループの名前で検索できます。

• 複製グループまたはフェイルオーバーグループで結果をフィルタリングするには、 Type を選択します。

• プライマリグループ (To を選択) またはセカンダリグループ (From を選択) でフィルタリングするには、 Replicating を選択します。

• (アカウント) メニューを選択し、アカウント名で結果をフィルタリングします。

• Status を選択して、結果をリフレッシュ操作のステータスでフィルタリングします。

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

複製グループとフェイルオーバーグループに関する次の詳細を確認できます。

複製グループまたはフェイルオーバーグループを選択すると、各リフレッシュ操作の詳細情報を表示できます。詳細については、 Snowsightの複製履歴のセクション をご参照ください。

リフレッシュ操作の進行状況のモニター¶

このセクションでは、特定の複製グループまたはフェイルオーバーグループの複製の進行状況をモニターする方法について説明します。

SELECT phase_name, start_time, end_time, progress, details
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_PROGRESS('myfg'));

複製履歴の表示¶

複製履歴は、 Snowsight または SQL を使用して表示できます。

Snowsightを使用した複製履歴の表示¶

特定の複製グループまたはフェイルオーバーグループの詳細ページで、各リフレッシュ操作の複製履歴と詳細を表示できます。

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

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

3. 複製グループまたはフェイルオーバーグループの名前を選択します。

その後、グループに関する以下の情報を確認できます。

• グループタイプ (複製グループまたはフェイルオーバーグループ)。

• 複製のスケジュール (たとえば10分ごと)。

• 各複製操作の時間。

• レプリカのタイムラグ (最後のリフレッシュ操作からの時間)。

• スケジュールされた次回リフレッシュ操作の日時。

このページでは、ステータスや期間でデータを絞り込むことができます。

• Status を選択して、結果をリフレッシュ操作のステータスでフィルタリングします。

  • Refresh Cancelled

  • Refresh Failed

  • Refresh In Progress

  • Refresh Successful

• リフレッシュ操作の詳細を表示するには、 Duration を選択します。

  • Last hour

  • Last 24 hours

  • Last 7 days

  • All

  All を選択すると、過去14日間のリフレッシュ操作が表示されます。

各リフレッシュ操作の詳細には、以下の列が含まれます。

列	説明
Query ID	リフレッシュ操作のクエリ ID 。
Status	リフレッシュ操作のステータスを表示します。有効な値には、 Successful 、 Failed 、 In Progress が含まれます。
Ended	リフレッシュ処理が終了した日時。
Duration	リフレッシュ処理が完了するまでにかかった時間。 持続期間は、 複製フェーズ ごとに色分けされています。各色のセグメントの幅は、そのフェーズに費やされた時間の割合を示しています。 下の画像はイメージです。このグラフは、追加の詳細のために リフレッシュ操作 を選択したときに表示されます。
Transferred	複製されたバイト数。
Objects	複製されたオブジェクトの数。

行を選択すると、以下のような特定のリフレッシュ操作の追加の詳細が表示されます。

• 各複製フェーズの期間。

• エラーメッセージ (リフレッシュ操作に失敗した場合)。

• 複製されたデータベースオブジェクトの種類と数のリスト。

• 複製されたデータベースの数とデータベース名。

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。

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 コマンドを使用して変更できます。

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