複数のアカウント間でのデータベースの複製

このトピックでは、複数のSnowflakeアカウントにデータベースを複製し、データベースオブジェクトと保存データの同期を維持するために必要なステップについて説明します。データベースの複製は、同じまたは異なる リージョン のSnowflakeアカウント間で発生する可能性があります。

注釈

Snowflakeは、 アカウント複製機能 を使用してデータベースを複製することを推奨しています。 複製グループとフェールオーバーグループ を使用すると、グループ内にあるオブジェクトのポイントインタイムの一貫性を保ったまま、複数のデータベースと他のアカウントオブジェクトを複製できます。 機能の可用性サポートされているオブジェクト の完全なリストについては、 複数のアカウント間にわたる複製とフェールオーバーの概要 をご参照ください。

このトピックの内容:

データベース複製およびフェールオーバー/フェールバックのリージョンサポート

Amazon Web Services、Google Cloud Platform、およびMicrosoft Azure全般において、Snowflakeの全リージョンでデータベース複製とフェールオーバー/フェールバックをサポートするようになりました。

アカウントでは、 リージョングループ 間(たとえば、Virtual Private Snowflake(VPS)とマルチテナントリージョン間)でのデータベースの複製ができ、これらのリージョン間でのデータ共有とアカウントの移行が容易になります。この機能はデフォルトで無効になっています。アクセスを有効にするには、 Snowflakeサポート にお問い合わせください。

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

注意

Snowsight および Classic Console の複製とフェイルオーバー/フェイルバックの管理とモニターは、プライベート接続を使用しているアカウントでのみ利用できます。

その他のアカウントについては、 Snowsightを使用した複製をモニターする および アカウントオブジェクトとデータベースの複製 をご覧ください。

アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)は、 Snowsight または Classic Console で、複製とフェールオーバー/フェールバックのアクションを管理できます。

Snowsight

ナビゲーション:

Data » Databases

プライマリデータベースの管理

注意

プライベート接続を使用しているアカウントのみ利用可能。その他のアカウントについては、 Snowsightを使用した複製をモニターする および アカウントオブジェクトとデータベースの複製 をご覧ください。

  1. Snowsight にサインインして、プライマリデータベースを含むSnowflakeアカウントにサインインします。

  2. 左上(ログイン名の横) » Switch Role » ACCOUNTADMIN のドロップダウンメニューを選択します。

  3. 左側のナビゲーションペインから Data » Databases を選択します。データベースオブジェクトエクスプローラーでプライマリデータベースを選択します。データベースの詳細ページが開きます。

    あるいは、複製が有効になっているデータベースのみを表示するには、 Replication Status » Primary フィルターを使用してアカウント内のプライマリデータベースをリストします。リストからデータベースを選択し、詳細ページを開きます。

    注釈

    Replication Status フィルターは、アカウントがデータベース複製のソースアカウントまたはターゲットアカウントである場合にのみ使用できます。

  4. その他のオプション » Enable Replication を選択します。 Enable replication ダイアログが開きます。

    実行したいアクションを選択します。

    • フェールオーバーを有効にします。この機能には Business Critical Edition (またはそれ以上)が必要です。

    • 1つ以上のターゲットアカウントにセカンダリデータベースを作成。

      別のアカウント内のプライマリデータベースが現在のアカウントへ複製できるようになっている場合は、現在のアカウント内にセカンダリデータベースを作成できます。ターゲットアカウントを追加するには、ソースアカウントで ALTER DATABASE コマンドを使用してプライマリデータベースを更新します。

    • 各セカンダリデータベースの作成後に、それぞれを1回更新。

  5. このデータベースのターゲットアカウントごとに、セカンダリデータベースを作成して、データベースを更新するオプションをオンにします。

  6. そのアカウントで以前に ACCOUNTADMIN ロールを付与されたユーザーとして、ターゲットアカウントにサインインします。

    Snowflakeはリクエストされたアクションを実行し、成功ダイアログを表示します。

    データベースの詳細にある Replication タブから、このデータベースの複製を管理します。

セカンダリデータベースを管理する

注意

プライベート接続を使用しているアカウントのみ利用可能。その他のアカウントについては、 Snowsightを使用した複製をモニターする および アカウントオブジェクトとデータベースの複製 をご覧ください。

  1. Snowsight にサインインして、セカンダリデータベースを含むSnowflakeアカウントにサインインします。

  2. 左上(ログイン名の横) » Switch Role » ACCOUNTADMIN のドロップダウンメニューを選択します。

  3. 左側のナビゲーションペインから Data » Databases を選択します。

    次のアクションは、ページの右上隅にあるアクション(...)ボタンから使用できます。

    • セカンダリデータベースを作成します。

      注釈

      このオプションは、アカウントがデータベース福世氏のソースアカウントまたはターゲットアカウントである場合にのみ使用できます。

      別のアカウント内のプライマリデータベースが現在のアカウントへ複製できるようになっている場合は、現在のアカウント内にセカンダリデータベースを作成できます。ターゲットアカウントを追加するには、ソースアカウントで ALTER DATABASE コマンドを使用してプライマリデータベースを更新します。

  4. データベースオブジェクトエクスプローラーでセカンダリデータベースを選択します。データベースの詳細ページが開きます。

  5. Replication タブを選択します。

    次のアクションは、ページの右上隅にあるアクション(...)ボタンから使用できます。

    • セカンダリデータベースをプライマリデータベースとして機能するように昇格します。この機能にはBusiness Critical Edition(またはそれ以上)が必要です。

      注釈

      セカンダリデータベースをプライマリとして昇格させるには、プライマリデータベースで、セカンダリデータベースが配置されているターゲットアカウントへのフェールオーバーを有効にする必要があります。

      このオプションが使用できない場合は、ソースアカウントで ALTER DATABASE コマンドを使用して、プライマリデータベースのターゲットアカウントへのフェールオーバーを有効にできます。詳細については、 ステップ3: プライマリデータベースのフェールオーバーを有効にする をご参照ください。

    • セカンダリデータベースを更新します。

    • テンプレートをコピーして、スケジュールでセカンダリデータベースを更新するタスクを作成します。テンプレートをSnowsightワークシートに貼り付け、編集して目的のスケジュールを指定します。

従来のコンソール

注意

プライベート接続を使用しているアカウントのみ利用可能。その他のアカウントについては、 Snowsightを使用した複製をモニターする および アカウントオブジェクトとデータベースの複製 をご覧ください。

Classic Console の Databases データベースタブ タブの Replication 領域を使用して、以下のアクションを含む、データベース複製の構成と管理に関連するほとんどのアクションを実行できます。

  • ローカルデータベースの複製を有効化。これにより、データベースは、プライマリデータベースとして機能するように昇格されます。

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

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

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

    注釈

    セカンダリデータベースをプライマリとして昇格させることができるようにするには、プライマリデータベースで、セカンダリデータベースが配置されているターゲットアカウントへのフェールオーバーを有効にする必要があります。

    このオプションが利用できない場合は、

    1. プライマリデータベースのソースアカウントにサインインします。

    2. Databases エリアから、 Replication を選択します。

    3. Primary タブを選択し、プライマリデータベースをリストします。プライマリデータベースの行を選択します。

    4. フェールオーバーを有効にするターゲットアカウントを検索し、 Failover を選択します。

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

データベースの別のアカウントへの複製

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

重要

ターゲットアカウントでは、 Tri-Secret Secure またはSnowflakeサービスへのプライベート接続(AWS PrivateLink など)がデフォルトで有効になっていません。コンプライアンス、セキュリティ、またはその他の目的でSnowflakeサービスへのTri-Secret Secureまたはプライベート接続が必要な場合は、ターゲットアカウントでこれらの機能を構成して有効にする責任があります。

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

組織管理者(ORGADMIN ロール)は、データベースを複製する前に、ソースアカウントとターゲットアカウントの複製を有効にする必要があります。詳細な手順については、 前提条件: 組織内のアカウントの複製を有効にする をご参照ください。

データベースの複製とフェールオーバーを有効にし、セカンダリデータベースを更新する

注釈

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

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

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

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

SHOW REPLICATION ACCOUNTS;

+------------------+---------------------------------+---------------+------------------+---------+-------------------+
| snowflake_region | created_on                      | account_name  | account_locator  | comment | organization_name |
|------------------+---------------------------------+---------------+------------------+---------+-------------------|
| AWS_US_WEST_2    | 2018-11-19 16:11:12.720 -0700   | ACCOUNT1      | MYACCOUNT1       |         | MYORG             |
| AWS_US_EAST_1    | 2019-06-02 14:12:23.192 -0700   | ACCOUNT2      | MYACCOUNT2       |         | MYORG             |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+
Copy

地域 IDs の包括的なリストをご参照ください。

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

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

ローカルデータベース mydb1account1 アカウント内)を昇格してプライマリデータベースとして機能させ、 account2account3 の各アカウントが、このデータベースのレプリカを保存できるように指定します。

ALTER DATABASE mydb1 ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
Copy

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

注釈

フェールオーバー/フェールバックには、Business Critical(またはそれ以上)が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。

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

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

プライマリデータベース mydb1 のアカウント account2 および account3 へのフェールオーバーを有効にします。

-- Executed from primary account
ALTER DATABASE mydb1 ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Copy

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

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

注釈

レプリケーションコマンド(例えば、データベースをソースアカウントのプライマリデータベースにプロモートする)は、通常、リージョン間で操作をトリガーし、有効になるまでに数秒かかる場合があります。例えば、ソースアカウントでプライマリデータベースとして機能するようにデータベースをプログラムでプロモートし、ターゲットアカウントでセカンダリデータベースを作成する場合、セカンダリデータベースを作成できるようになるまでに数秒かかる場合があります。

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

重要

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

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

組織のプライマリデータベースとセカンダリデータベースのリストを表示するには、 SHOW REPLICATION DATABASES をクエリします。セカンダリデータベースが作成された後、アカウント管理者はデータベースの所有権を別のロールに譲渡できます(GRANT OWNERSHIP を使用)。

次の例では、 myorg.account2 アカウントに myorg.account1.mydb1 プライマリデータベースのレプリカを作成します。

-- Log into the ACCOUNT2 account.

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

+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+
| snowflake_region | created_on                    | account_name    | name     | comment | is_primary | primary                    | replication_allowed_to_accounts | failover_allowed_to_accounts | organization_name | account_locator |
|------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------|
| AWS_US_WEST_2    | 2019-11-15 00:51:45.473 -0700 | ACCOUNT1        | MYDB1    | NULL    | true       | MYORG.ACCOUNT1.MYDB1       | MYORG.ACCOUNT2, MYORG,ACCOUNT1  | MYORG.ACCOUNT1               | MYORG             | MYACCOUNT1      |
+------------------+-------------------------------+-----------------+----------+---------+------------+----------------------------+---------------------------------+------------------------------+-------------------+-----------------+

-- Create a replica of the 'mydb1' primary database
-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb1
  AS REPLICA OF myorg.account1.mydb1
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- Verify the secondary database
SHOW REPLICATION DATABASES;

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

ステップ5.各セカンダリデータベースを更新する

このセクションの手順では、プライマリデータベースのスナップショットからセカンダリデータベースを更新する(ALTER DATABASE ... REFRESH を使用)方法について説明します。スナップショットには、オブジェクトとデータへの変更が含まれます。非常に大規模なプライマリデータベースの初期複製では、 ステートメントのタイムアウトを増やす ことをお勧めします。

注釈

  • セカンダリデータベースを更新するには、操作の実行に使用されるロールがデータベースに対する OWNERSHIP 権限を持っているか、データベースに対する OWNERSHIP 権限を持つロールが付与されている必要があります。

  • 更新操作を実行するロールは、データベース更新の結果として追加された新しいオブジェクトを所有します。

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

ALTER DATABASE mydb1 REFRESH;
Copy

ウェブUIで、セカンダリデータベースを更新する こともできます。

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

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

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

注釈

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

  • タスクの1回の実行には、60分のデフォルトの制限があります。この制限は、終了しないタスクに対する保護手段として実装されました。非常に大きなデータベースを更新すると、まれにデフォルトのタスク実行制限を超える場合があります。これが発生したかどうかを判断するには、 TASK_HISTORY テーブル関数をクエリします。または、 ALTER TASK ... SET USER_TASK_TIMEOUT_MS = <数> を実行して、タスクのタイムアウトの制限を増やすことを検討します。

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

前提条件:

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

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

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

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

    • ウェアハウス。ここには、構文要件を満たすために任意のウェアハウスを提供できますが、データベースの更新には使用 されませんCREATE WAREHOUSE を使用して新しいウェアハウスを作成します。

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

必要な権限:

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

オブジェクト型

オブジェクト

権限

メモ

アカウント

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

EXECUTE TASK

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

データベース

セカンダリデータベース

OWNERSHIP

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

データベース

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

USAGE

スキーマ

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

USAGE, CREATE TASK

タスク

OWNERSHIP

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

ウェアハウス

タスクの構成に使用されるウェアハウス

USAGE

タスクを構成するにはウェアハウスを指定する必要がありますが、ウェアハウスはタスクの実行や更新操作には使用 されません

ステップ:

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

  1. スケジュールに従ってデータベースの更新を開始するタスクを作成します( CREATE TASK を使用)。複製スケジュールを指定するための CREATETASK 構文にはウェアハウスが必要ですが、ウェアハウスは複製には使用 されません

    たとえば、4時間のタイムアウトで10分ごとに mydb1 という名前のセカンダリデータベースを更新する refresh_mydb1_task という名前のタスクを作成します。タスクは、既存のウェアハウス mywh を使用して構成されます。

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

ALTER TASK refresh_mydb1_task RESUME;
Copy

好みのSnowflakeクライアントで次の SQL ステートメントを実行して複製とフェールオーバーを有効にし、データベースの初期更新を実行して、スケジュールされた更新を設定します。

ソースアカウントからの実行
-- The commands below are executed from the source account

-- View replication enabled accounts
SHOW REPLICATION ACCOUNTS;

ALTER DATABASE mydb ENABLE REPLICATION TO ACCOUNTS myorg.account2, myorg.account3;
ALTER DATABASE mydb ENABLE FAILOVER TO ACCOUNTS myorg.account2, myorg.account3;
Copy
各ターゲットアカウントから実行
-- The commands below are executed from each target account

-- View replication enabled databases
-- Note the primary column of the source database for the CREATE DATABASE statement below
SHOW REPLICATION DATABASES;

-- If the primary database has the DATA_RETENTION_TIME_IN_DAYS parameter set to a value other than the default value,
-- set the same value for the parameter on the secondary database.
CREATE DATABASE mydb
  AS REPLICA OF myorg.account1.mydb
  DATA_RETENTION_TIME_IN_DAYS = 10;

-- Increase statement timeout for initial refresh
-- Optional but recommended for initial refresh of a large database
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- If you have an active warehouse in current session, update warehouse statement timeout
SELECT CURRENT_WAREHOUSE();
ALTER WAREHOUSE my_wh SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
-- Reset warehouse statement timeout after initial refresh
ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;

-- Refresh a secondary database
ALTER DATABASE mydb REFRESH;

-- Create task
-- Set up refresh schedule for each secondary database using a separate database
USE DATABASE my_db2;

-- Create a task and RESUME the task for each secondary database
-- Edit the task schedule and timeout for your specific use case
CREATE TASK my_refresh_task
  WAREHOUSE = my_wh
  SCHEDULE = '10 minute'
  USER_TASK_TIMEOUT_MS = 14400000
AS
  ALTER DATABASE mydb REFRESH;

-- Start task
ALTER TASK my_refresh_task RESUME;
Copy

従来のアカウントロケーターの使用

複製およびフェールオーバーのコマンドでアカウントを識別する場合、従来の snowflake_region.account_locator 形式が現在はサポートされていますが、将来的に機能しなくなる可能性があるため、使用はお勧めできません。

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

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

同じセッションで ALTER DATABASE secondary_db_name REFRESH ステートメントを実行する前に、次の ALTER SESSION ステートメントを実行します。

ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 604800;
Copy

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

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

ALTER WAREHOUSE my_wh UNSET STATEMENT_TIMEOUT_IN_SECONDS;
Copy

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

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

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

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

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

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

データベース更新の進行状況を従来のコンソールでモニタリング

Classic Console でセカンダリデータベースの更新を手動で開始し、動的な進行状況バーに統計をともなう更新操作の現在のステータスを表示します。

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

  1. Classic Console で、 Databases データベースタブ タブ » Replication を選択します。

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

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

  4. Refresh ボタンを選択します。

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

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

従来のコンソールでのセカンダリ更新操作

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

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

または

DATABASE_REPLICATION_USAGE_HISTORY ビュー (共有Snowflakeデータベースの Account Usage スキーマ内)をクエリします。このビューは、過去365日(1年)内におけるデータベース複製の使用状況のアクティビティを返します。

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

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

データベース複製コストのモニター

データベース複製 を使用して個別のデータベースを複製する場合、 ACCOUNTADMIN ロールを持つユーザーは、 Snowsight、 Classic Console、または SQL を使用して、指定された日付範囲内のSnowflakeアカウントの複製データ転送量(バイト単位)を表示できます。

アカウントのデータ転送量を表示するには、

Snowsight:

Select Admin » Cost Management

Classic Console:

Account アカウントタブ » Billing & Usage をクリックします。

複製の使用率は、特別なSnowflake提供の 青のSnowflakeのロゴ(テキストなし) REPLICATION という名前のウェアハウスとして表示されます。 Data Transfer ボタンをクリックして、データ転送コストを表示します。ウェブインターフェイスは、複製のデータ転送コストを分割しないことに注意してください。

SQL:

次のいずれかをクエリします。

  • DATABASE_REPLICATION_USAGE_HISTORY テーブル関数( Snowflake Information Schema 内)。この関数は、過去14日以内におけるデータ複製の使用状況のアクティビティを返します。

  • DATABASE_REPLICATION_USAGE_HISTORY ビュー ビュー( Account Usage 内)。このビューは、過去365日(1年)内におけるデータベース複製の使用状況のアクティビティを返します。

    DATABASE_REPLICATION_USAGE_HISTORY ビューに対して次のクエリを実行できます。

    クエリ: 複製のコスト履歴(日別、オブジェクト別)

    このクエリは、複製されたデータベースの包括的リストと、過去30日間に複製サービスを介して消費したクレジット量を日別に表示します。クレジットの消費に不規則性があるか、一貫して消費量が多い場合は、さらに調査する必要があることを表します。

    SELECT TO_DATE(start_time) AS date,
      database_name,
      SUM(credits_used) AS credits_used
    FROM snowflake.account_usage.database_replication_usage_history
    WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP())
    GROUP BY 1,2
    ORDER BY 3 DESC;
    
    Copy

    クエリ: 複製履歴およびm日平均

    このクエリは、複製によって消費された1日の平均クレジットを、前年の週ごとにグループ化して表示します。これは、日次平均の異常を特定して、消費量の急増や変化を調査するために役立ちます。

    WITH credits_by_day AS (
      SELECT TO_DATE(start_time) AS date,
        SUM(credits_used) AS credits_used
      FROM snowflake.account_usage.database_replication_usage_history
      WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP())
      GROUP BY 1
      ORDER BY 2 DESC
    )
    
    SELECT DATE_TRUNC('week',date),
      AVG(credits_used) AS avg_daily_credits
    FROM credits_by_day
    GROUP BY 1
    ORDER BY 1;
    
    Copy

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

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

セカンダリデータベースでの実行

  1. セカンダリデータベースで、 DATABASE_REFRESH_PROGRESS テーブル関数(Snowflake Information Schema 内)をクエリします。 PRIMARY_UPLOADING_DATA フェーズの DETAILS 列にある snapshot_transaction_timestamp に注意してください。これは、プライマリデータベースの最新スナップショットのタイムスタンプです。

    select parse_json(details)['snapshot_transaction_timestamp']
    from table(information_schema.database_refresh_progress(mydb))
    where phase_name = 'PRIMARY_UPLOADING_DATA';
    
    Copy
  2. 指定されたテーブルの HASH_AGG 関数をクエリします。次のクエリは、 mytable テーブル内にあるすべての行のハッシュ値を返します。

    SELECT HASH_AGG( * ) FROM mytable;
    
    Copy

プライマリデータベースでの実行

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

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

セカンダリデータベースの削除

DROP DATABASE コマンドを使用して、いつでもセカンダリデータベースを削除できます。データベースを削除できるのは、データベース所有者(つまり、データベースに対する OWNERSHIP 権限を持つロール)のみです。

プライマリデータベースの削除

データベースの1つ以上のレプリカ(つまり、セカンダリデータベース)が存在する場合、プライマリデータベースは削除できません。プライマリデータベースを削除するには、まずセカンダリデータベースをプライマリデータベースとして昇格させてから、以前のプライマリデータベースを削除します。または、プライマリデータベースのセカンダリデータベースをすべて削除してから、プライマリデータベースを削除します。

データベースを削除できるのはデータベース所有者のみであることに注意してください。