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

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

このトピックの内容:

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

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

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

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

アカウント管理者(ACCOUNTADMIN ロールを持つユーザー)は、新しいウェブインターフェイスまたは従来のウェブインターフェイスのいずれかで、複製とフェールオーバー/フェールバックのアクションを管理できます。

新しいウェブインターフェイス

ナビゲーション:

Data » Databases

ローカルデータベースの昇格

  1. 1つ以上の他のアカウントに複製する、ローカルデータベースを含んだSnowflakeアカウントにログインします。

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

  3. Databases ページの左側で、データベースオブジェクトエクスプローラーのローカルデータベースをクリックします。データベースの詳細ページが開きます。

  4. ページ » Enable Replication の右上隅にあるアクション(...)ボタンをクリックします。 Enable replication ダイアログが開きます。

    このダイアログでは、次のアクションを実行できます。

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

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

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

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

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

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

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

セカンダリデータベースの管理

  1. セカンダリデータベースを含むアカウントにログインします。

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

  3. Databases ページの左側で、データベースオブジェクトエクスプローラーのセカンダリデータベースをクリックします。データベースの詳細ページが開きます。

  4. Replication タブをクリックします。

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

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

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

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

従来のウェブインターフェイス

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

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

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

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

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

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

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

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

重要

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

複製およびフェールオーバー SQL コマンドのアカウント識別子

以下の手順にある SQL ステートメントの例では、 アカウント識別子組織名.アカウント名 の形式で使用しています。ただし、 Snowflakeリージョン.アカウントロケーター の形式のアカウント識別子はサポートされています。

詳細については、 複製およびフェールオーバーのアカウント識別子 をご参照ください。

前提条件: アカウントで複製を有効にする

組織内の2つ以上のアカウントで複製を有効にする必要があります。アカウントで 組織 機能が有効になっている場合、 ORGADMIN ロールを持つユーザーは複製を有効にできます。詳細については、このトピック内の 組織内にあるアカウントの複製の有効化 をご参照ください。組織を有効にしていない場合は、 Snowflakeサポート に連絡して、アカウントの複製を有効にすることができます。

組織内にあるアカウントの複製の有効化

ORGADMIN ロールを持つユーザーは、 ORGADMIN アカウントから ENABLE_ACCOUNT_DATABASE_REPLICATION パラメーターを true に設定することで、アカウントの複製を有効にできます。

注釈

異なるリージョンに同じ アカウントロケーター を持つ複数のアカウントがある場合で複製を有効にするには、 Snowflakeサポート にお問い合わせください。

-- Assume the ORGADMIN role
use role orgadmin;

-- View the list of the accounts in your organization
-- Note the account_locator 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('<account_locator>',
'ENABLE_ACCOUNT_DATABASE_REPLICATION', 'true');

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

注釈

注記がない限り、アカウント管理者(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             |
+------------------+---------------------------------+---------------+------------------+---------+-------------------+

Snowflakeリージョン IDs の包括的なリストをご参照ください。

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

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

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

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

ステップ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;

ステップ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      |
+------------------+-------------------------------+---------------+----------+---------+------------+-------------------------+---------------------------------+------------------------------+-------------------+-----------------+

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

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

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

注釈

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

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

ALTER DATABASE mydb1 REFRESH;

ウェブ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 権限 ... 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;
    
  2. タスクは、作成時にデフォルトで一時停止されます。タスクを再開して、タスク定義で指定されたパラメーターに基づいて実行できるようにします。

ALTER TASK refresh_mydb1_task RESUME;

好みの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;
各ターゲットアカウントから実行
-- 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;

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

データベースの複製では、独自の仮想ウェアハウスではなく、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;

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

初期データベース複製または後続のセカンダリデータベース更新の現在の状況を判別するには、 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_PROGRESS テーブル関数(情報スキーマ 内)をクエリします。 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';
    
  2. 指定されたテーブルの HASH_AGG 関数をクエリします。次のクエリは、 mytable テーブル内にあるすべての行のハッシュ値を返します。

    SELECT HASH_AGG( * ) FROM mytable;
    

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

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

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