複数のアカウント間におけるデータベースの複製

このトピックでは、異なる 地域 の複数のSnowflakeアカウントにデータベースを複製し、データベースオブジェクトと保存データの同期を維持するために必要な手順について説明します。

このトピックの内容:

データベース複製およびフェールオーバー/フェールバックの地域サポート

Amazon Web Services、Google Cloud Platform、およびMicrosoft Azure全般において、Snowflakeの全地域でデータベース複製とフェールオーバー/フェールバックをサポートするようになりました(Microsoft Azureの US バージニア政府を除く)。

アカウントでは、Virtual Private Snowflake(VPS)とマルチテナント地域間でのデータベース複製ができ、これらの地域間でのデータ共有とアカウントの移行が容易になります。この機能はデフォルトで無効になっています。VPS アカウントは、 Snowflakeサポート に連絡して、アクセスを有効にする必要があります。

データベース複製およびフェールオーバー/フェールバック用のウェブインターフェイス

アカウント管理者( ACCOUNTADMIN ロールを持つユーザー)は、Snowflakeウェブインターフェイスの Databases Databases tab タブの Replication エリアを使用して、以下のアクションを含む、データベース複製の構成と管理に関連するほとんどのアクションを実行できます。

  • プライマリデータベースとして機能するようにローカルデータベースを昇格。

  • プライマリデータベース(Business Critical Editionアカウント(またはそれ以上))のフェールオーバーを有効化。

  • セカンダリデータベースを1回(手動)または繰り返し(タスクを使用して、スケジュールに従い)更新。

  • プライマリデータベース(Business Critical Editionアカウント(またはそれ以上))として機能するセカンダリデータベースを昇格。

  • プライマリデータベースの複製および/またはフェールオーバーを無効化。

データベースを別のアカウントに複製する

このセクションの手順では、アカウントを複製用に準備する方法、ローカルデータベースをプライマリデータベースとして機能させる方法、このプライマリデータベースの別のアカウントへの初期レプリケーションを実行する方法について説明します。

重要

ターゲットアカウントには、 Tri-Secret Secure または AWS PrivateLink がデフォルトとして構成されていません。コンプライアンス、セキュリティ、またはその他の目的でTri-Secret Secureまたは PrivateLink が必要な場合、それらの機能がターゲットアカウントで構成されていることを確認するのはユーザーの責任です。

ステップ2:組織内のすべてのアカウントを表示する

組織内のアカウントのリストを取得します。これらのアカウントの既存の永続データベースまたは一時データベースは、プライマリデータベースとして機能するように変更できます。プライマリデータベース(つまり、セカンダリデータベース)のレプリカは、これらのアカウントでのみ作成できます。

注釈

アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)のみがこのセクションの SQL ステートメントを実行できます。

組織内のアカウントのリストを表示するには、 SHOW REPLICATION ACCOUNTS をクエリします。

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------+
| snowflake_region | created_on                      | name          | comment    |
|------------------+---------------------------------+---------------+------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | MYACCOUNT1    |            |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | MYACCOUNT2    |            |
+------------------+---------------------------------+---------------+------------+

次の表には、Snowflake地域 IDs の完全なリストが示されています。

Snowflake地域 IDs

地域

地域 ID

Snowflake 地域 ID

メモ

Amazon Web Services(AWS)

US 西部(オレゴン)

us-west-2

aws_us_west_2

US 東部(オハイオ)

us-east-2.aws

aws_us_east_2

US 東部(バージニア北部)

us-east-1

aws_us_east_1

US 東部(商業組織、バージニア政府北部)

us-east-1-gov.aws

aws_us_east_1_gov

Business Critical(またはそれ以上)のアカウントでのみ使用できます。Snowflakeがまだサポートしていない独立した専用クラウドである、 AWS GovCloud (US)には位置していません。

カナダ(中部)

ca-central-1.aws

aws_ca_central_1

EU (アイルランド)

eu-west-1

aws_eu_west_1

EU (フランクフルト)

eu-central-1

aws_eu_central_1

アジア太平洋(東京)

ap-northeast-1.aws

aws_ap_northeast_1

アジア太平洋(ムンバイ)

ap-south-1.aws

aws_ap_south_1

アジア太平洋(シンガポール)

ap-southeast-1

aws_ap_southeast_1

アジア太平洋(シドニー)

ap-southeast-2

aws_ap_southeast_2

Google Cloud Platform(GCP)

US 中央部1(アイオワ)

us-central1.gcp

gcp_us_central1

ヨーロッパ西部2(ロンドン)

europe-west2.gcp

gcp_europe_west2

ヨーロッパ西部4(オランダ)

europe-west4.gcp

gcp_europe_west4

Microsoft Azure

西 US 2(ワシントン)

west-us-2.azure

azure_westus2

東 US 2(バージニア)

east-us-2.azure

azure_eastus2

US バージニア政府

us-gov-virginia.azure

azure_usgovvirginia

Business Critical(またはそれ以上)のアカウントでのみ利用可能です。

カナダ中央部(トロント)

canada-central.azure

azure_canadacentral

西ヨーロッパ(オランダ)

west-europe.azure

azure_westeurope

東南アジア(シンガポール)

southeast-asia.azure

azure_southeastasia

スイス北部(チューリッヒ)

switzerland-north.azure

azure_switzerlandnorth

オーストラリア東部(ニューサウスウェールズ)

australia-east.azure

azure_australiaeast

ステップ3:プライマリデータベースとして機能するローカルデータベースを昇格する

ALTER DATABASE ... ENABLE REPLICATION TO ACCOUNTS ステートメントを使用して、既存の永続データベースまたは一時データベースをプライマリデータベースとして機能するように変更します。このデータベース(つまり、セカンダリデータベース)のレプリカを格納できる組織内のアカウントのコンマ区切りリストを提供し、それらのアカウントのユーザーがセカンダリデータベースのオブジェクトをクエリできるようにします。

注釈

アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)のみがこのセクションの SQL ステートメントを実行できます。

ローカルデータベース mydb1aws_us_west_2 地域内)を昇格してプライマリデータベースとして機能させ、 myaccount2myaccount3aws_us_east_1 (AWS)と azure_westeurope (Azure)の地域内それぞれ)の各アカウントが、このデータベースのレプリカを格納できるように指定します。

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

ステップ4:プライマリデータベースのフェールオーバーを有効にする

注釈

このステップは、このプライマリデータベースを別のアカウントにフェールオーバーするように構成する予定がある場合に のみ 完了してください。詳細については、 ビジネス継続性と災害復旧の概要 をご参照ください。

ALTER DATABASE ... ENABLE FAILOVER TO ACCOUNTS ステートメントを使用して、組織内の1つ以上のアカウントへのプライマリデータベースのフェールオーバーを有効にします。これらのアカウントのいずれか(つまり、セカンダリデータベース)にあるこのプライマリデータベースのレプリカは、プライマリデータベースとして機能するように昇格できます。

プライマリデータベースのフェールオーバーの有効化は、指定されたアカウントでプライマリデータベースのレプリカが作成された前、 または 後に行うことができます。

プライマリデータベース mydb1aws_us_west_2 地域内)からアカウント myaccount2 および myaccount3aws_us_east_1 地域内(AWS)および azure_westeurope (Azure))へのフェールオーバーを有効にします。この例では、プライマリデータベースが myaccount1 アカウントに保存されているとします。 ALTER DATABASE コマンドはそのアカウントで実行する必要があります。

ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS aws_us_east_1.myaccount2, azure_westeurope.myaccount3;

ステップ5:セカンダリデータベースを作成する

プライマリデータベースを格納する同じアカウント、または別のアカウント(同じまたは別の地域)に既存のプライマリデータベースのレプリカを作成します。セカンダリデータベースは、 ステップ3:ローカルデータベースをプライマリデータベースとして機能するように昇格するALTER DATABASE ... ENABLE REPLICATION TO ACCOUNTS ステートメントで指定されたアカウントでのみ作成できることに注意してください。

各ターゲットアカウントで CREATE DATABASE ... AS REPLICA OF ステートメントを実行して、指定したプライマリデータベースのレプリカを作成します。

重要

ベストプラクティスとして、各セカンダリデータベースにプライマリデータベースと同じ名前を付けることをお勧めします。このプラクティスは、ビュー内の完全修飾テーブル名のクエリなど、同じデータベース内の他のオブジェクトによる完全修飾オブジェクト(つまり、 '<データベース>.<スキーマ>.<オブジェクト>')の参照をサポートしています。

セカンダリデータベースの名前がプライマリデータベースと異なる場合、これらのオブジェクト参照はセカンダリデータベースで壊れます。

組織のプライマリデータベースとセカンダリデータベースのリストを表示するには、 SHOW REPLICATION DATABASES をクエリします。

注釈

アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)のみがこのセクションの SQL ステートメントを実行できます。

セカンダリデータベースが作成された後、アカウント管理者はデータベースの所有権を別のロールに移行できます( GRANT OWNERSHIP を使用)。

次の例では、 aws_us_east_1.myaccount2 アカウントに aws_us_west_2.myaccount1.mydb1 プライマリデータベースのレプリカを作成し、レプリカのマテリアライズドビューの自動更新を有効にします。 SQL ステートメントは、同じ AWS 地域グループ(public)で実行されますが、プライマリデータベースを保存するアカウントとは異なる地域で実行されます。

-- Log into the AWS_US_EAST_1.MYACCOUNT2 account.

-- Query the set of primary and secondary databases in your organization.
-- In this example, the AWS_US_WEST_2.MYACCOUNT1 primary database is available to replicate.
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

-- Create a replica of the 'mydb1' primary database
CREATE DATABASE mydb1
  AS REPLICA OF aws_us_west_2.myaccount1.mydb1
  AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE;

-- Verify the secondary database
SHOW REPLICATION DATABASES;

+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                                  | snowflake_region | replication_allowed_to_accounts                                  | failover_allowed_to_accounts    |
|------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | MYACCOUNT1      | MYDB1    | NULL    | true       | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_WEST_2    | PUBLIC.AWS_US_EAST_1.MYACCOUNT2, PUBLIC.AWS_US_WEST_2.MYACCOUNT1 | PUBLIC.AWS_US_WEST_2.MYACCOUNT1 |
| AWS_US_EAST_1    | 2019-08-15 15:51:49.094 -0700 | MYACCOUNT2      | MYDB1    | NULL    | false      | PUBLIC.AWS_US_WEST_2.MYACCOUNT1.MYDB1    | AWS_US_EAST_1    |                                                                  |                                 |
+------------------+-------------------------------+-----------------+----------+---------+------------+------------------------------------------+------------------+------------------------------------------------------------------+---------------------------------+

各セカンダリデータベースの更新

このセクションの手順では、プライマリデータベースのスナップショットからセカンダリデータベースを更新する(ALTER DATABASE ... REFRESH を使用)方法について説明します。スナップショットには、オブジェクトとデータへの変更が含まれます。

セカンダリデータベースの所有者(データベースに対する OWNERSHIP 権限を持つロール)は、データベースの更新の結果として追加された新しいオブジェクトを所有していることに注意してください。

注釈

セカンダリデータベースを更新するには、操作の実行に使用されるロールに、データベースに対する OWNERSHIP 権限が必要です。

アカウントにログインした後に現在の地域を確認するには、 CURRENT_REGION 関数をクエリします。

ALTER DATABASE mydb1 REFRESH​;

ウェブインターフェイスでのセカンダリデータベースの更新

Snowflakeウェブインターフェイスは、セカンダリデータベース更新の現在の状態に関する視覚的表現を提供します。手順については、 データベース更新の進行状況をウェブインターフェイスでモニタリング (このトピック内)をご参照ください。

初期複製のステートメントタイムアウトの増加

データベースの複製では、独自の仮想ウェアハウスではなく、Snowflakeが提供する計算リソースを使用してオブジェクトとデータをコピーします。ただし、 STATEMENT_TIMEOUT_IN_SECONDS セッション/オブジェクトパラメーターは、ステートメントがキャンセルされるまでの実行時間を制御します。デフォルト値は 172800 (2日)です。非常に大規模なプライマリデータベースの 初期複製 の完了には2日以上かかる場合があるため(データベースのメタデータの量とデータベースオブジェクトのデータの量に応じて異なります)、複製操作を実行するセッションの STATEMENT_TIMEOUT_IN_SECONDS 値を 604800 (最大値の7日)に増やします。

同じセッションで ALTER DATABASE セカンダリデータベース名 REFRESH ス テートメントを実行する前に、次の ALTER SESSION ステートメントを実行します。

ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

STATEMENT_TIMEOUT_IN_SECONDS パラメーターは、セッション内のアクティブなウェアハウスにも適用されることに注意してください。このパラメーターは、セッションレベルまたはウェアハウスレベルで設定された 低い 値を優先します。現在のセッションでアクティブなウェアハウスがある場合は、このウェアハウスの STATEMENT_TIMEOUT_IN_SECONDS も 604800 に設定します( ALTER WAREHOUSE を使用)。

例:

-- determine the active warehouse in the current session (if any)
SELECT CURRENT_WAREHOUSE();

+---------------------+
| CURRENT_WAREHOUSE() |
|---------------------|
| MY_WH               |
+---------------------+

-- change the STATEMENT_TIMEOUT_IN_SECONDS value for the active warehouse

ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;

複製操作が完了した後、パラメーター値をデフォルトにリセットできます。

ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

スケジュールに基づいてセカンダリデータベースを更新する

ベストプラクティスとして、セカンダリデータベースの更新をスケジュールすることをお勧めします。このセクションでは、指定したスケジュールでデータベースの更新を自動的に開始する方法について説明します。

セカンダリデータベースを更新する頻度は、セカンダリデータベースのデータの目標復旧ポイント(RPO)によって異なります。たとえば、データに依存するアプリケーションが最大1時間のデータ損失を許容できる場合は、少なくとも1時間ごとにデータを更新する必要があります。データ損失許容値が5分である場合は、少なくとも5分ごとにセカンダリデータベースを更新します。

注釈

  • プライマリデータベースの初期複製を手動で実行し( ALTER DATABASE ... REFRESH を使用)、後続の更新のみをスケジュールすることをお勧めします。

  • タスクの1回の実行には、60分のデフォルトの制限があります。この制限は、終了しないタスクに対する保護手段として実装されました。非常に大きなデータベースを更新すると、まれにデフォルトのタスク実行制限を超える場合があります。これが発生したかどうかを判断するには、 TASK_HISTORY テーブル関数をクエリします。タスクが、タスクにスケジュールされたウィンドウを超えた場合、原因の大半はウェアハウスが小さすぎることです。ウェアハウスのサイズを確認して、スケジュールウィンドウまたは1時間の制限内に収まるようにサイズを増やすことを検討します。

    または、 ALTER TASK ... SET USER_TASK_TIMEOUT_MS = <数> を実行して、タスクのタイムアウトの制限を増やすことを検討します。

このセクションのステップを実行して、指定したスケジュールでデータベースの更新を自動的に開始します。

前提条件

セカンダリデータベースを保存するアカウントには、次のSnowflakeオブジェクトが必要です。

  • セカンダリデータベース。

  • このセクションで作成された新しいオブジェクトを保存する個別のデータベース。セカンダリデータベースはすぐに使用できるため、このデータベースはセカンダリデータベースとは別にする必要があります。このデータベースには、次のオブジェクトも含まれている必要があります。

    • スキーマ。 PUBLIC スキーマを使用するか、 CREATE SCHEMA を使用して新しいスキーマを作成します。

    • データベースを更新するための計算リソースを提供するウェアハウス。 CREATE WAREHOUSE を使用して新しいウェアハウスを作成します。

    • スケジュールに従ってセカンダリデータベースを更新するタスク。

必要な権限

このセクションのステップでは、ストアドプロシージャとタスクが作成されるアカウントに次の権限を持つロールが必要です。

オブジェクト型

オブジェクト

権限

メモ

アカウント

セカンダリデータベースを保存するアカウント

EXECUTE TASK

新しいタスクを実行するために必要です。

データベース

セカンダリデータベース

OWNERSHIP

セカンダリデータベースを更新するために必要です。

データベース

新しいタスクを保存するデータベース。

USAGE

スキーマ

新しいタスクを保存するスキーマ。

USAGE, CREATE TASK

タスク

OWNERSHIP

タスクを作成するロールは、デフォルトでオブジェクトを所有します。所有権は、 GRANT 権限 ... TO ROLE を使用して、別のロールに譲渡できます。

ウェアハウス

タスクの実行に使用されるウェアハウス

USAGE

ステップ

スケジュールに従って更新する各セカンダリデータベースについて、次のステップを実行します。

  1. スケジュールに従ってデータベースの更新を開始するタスクを作成します( CREATE TASK を使用)。

    構文
    CREATE [ OR REPLACE ] TASK [ IF NOT EXISTS ] <name>
      WAREHOUSE = <string>
      SCHEDULE = { <number> MINUTE | USING CRON <expr> <time_zone> } | AFTER <string>
    AS
      ALTER DATABASE <secondary_db_name> REFRESH;
    

    例えば、10分ごとに mydb1 という名前のセカンダリデータベースを更新する refresh_mydb1_task という名前のタスクを作成します。タスクは既存のウェアハウス mywh を使用して実行されます:

    CREATE TASK refresh_mydb1_task
      WAREHOUSE = mywh
      SCHEDULE = '10 minute'
    AS
      ALTER DATABASE mydb1 REFRESH;
    
  2. タスクは、作成時にデフォルトで一時停止されます。タスクを再開して、タスク定義で指定されたパラメーターに基づいて実行できるようにします。

ALTER TASK refresh_mydb1_task RESUME;

データベース更新の進行状況の監視

初期データベース複製または後続のセカンダリデータベース更新の現在の状況を判別するには、 DATABASE_REFRESH_PROGRESS , DATABASE_REFRESH_PROGRESS_BY_JOB 表関数( 情報スキーマ 内)をクエリします。

複製するデータの量によっては、データベースの更新操作を完了するまでに数時間以上かかる場合があります。

指定された日付範囲内の指定されたデータベースの複製履歴を表示するには、次のいずれかをクエリします。

mydb1 セカンダリデータベースの更新の進行状況をモニターします。

select *
  from table(information_schema.database_refresh_progress(mydb1));

データベース更新の進行状況をウェブインターフェイスでモニタリング

Snowflakeウェブインターフェイスでセカンダリデータベースの更新を手動で開始し、動的な進行状況バーに統計を伴う更新操作の現在のステータスを表示します。

セカンダリデータベースの更新操作を開始するには、

  1. Snowflakeウェブインターフェイスで、 Databases Databases tab タブ » Replication をクリックします。

  2. 更新するセカンダリデータベースを選択します。

  3. Refresh now ボタンをクリックします。 Refresh Database ダイアログが開きます。

  4. Refresh ボタンをクリックします。

Last Refresh Status 列には、現在の更新操作のステータスが表示されます。進行状況バーは動的に更新されます。

サイドウィンドウの Refresh History 統計には、現在の更新ステータス、更新開始時刻、転送バイト数、その他の統計も表示されます。

Secondary refresh operation in the Snowflake web interface

データベース更新履歴の表示

セカンダリデータベースの更新操作の履歴を表示するには、 DATABASE_REFRESH_HISTORY テーブル関数( 情報スキーマ 内)をクエリします。この関数は、過去14日間のデータベース更新アクティビティを返します。

または

REPLICATION_USAGE_HISTORY ビュー ビューをクエリします(共有Snowflakeデータベースの アカウントの使用 スキーマ内)。このビューは、過去365日(1年)内の複製使用状況アクティビティを返します。

mydb1 セカンダリデータベースの更新操作の履歴を表示します。

select *
  from table(information_schema.database_refresh_history(mydb1));

プライマリデータベースとセカンダリデータベースのデータセットの比較

オプションで HASH_AGG 関数を使用して、プライマリデータベースとセカンダリデータベースのテーブルのランダムセットの行を比較し、データの整合性を検証します。 HASH_AGG 関数は、入力行の(順序付けられていない)セットの署名付き64ビットハッシュ値の集合を返します。セカンダリデータベースとプライマリデータベースのテーブルのすべてまたはランダムなサブセット(プライマリデータベーススナップショットのタイムスタンプ時点)でこの関数をクエリし、出力を比較します。

  1. セカンダリデータベースで、 DATABASE_REFRESH_HISTORY テーブル関数( 情報スキーマ 内)をクエリします。最新の更新操作がいつ完了したかを示す行の END_TIME 列に注意してください。これは、プライマリデータベースの最新のスナップショットのタイムスタンプです。

  2. 指定されたテーブルの HASH_AGG 関数をクエリします。次のクエリは、 mytable テーブル内のすべての行のハッシュ値を返します。

    SELECT HASH_AGG( * ) FROM mytable;
    
  3. プライマリデータベースで、同じテーブルの HASH_AGG 関数をクエリします。Time Travelを使用して、セカンダリデータベースの最新のスナップショットが作成されたときのタイムスタンプを指定します。

    SELECT HASH_AGG( * ) FROM mytable AT(TIMESTAMP => <primary_snapshot_timestamp>);
    
  4. 2つのクエリの結果を比較します。出力は同一である必要があります。