アカウントオブジェクトのフェールオーバー

このトピックでは、障害復旧のために、異なる リージョン の複数のアカウントオブジェクトに複製されたデータベースをフェールオーバーするために必要なステップについて説明します。

For information about the purpose of the failover mechanism and when to use it, see ビジネス継続性と障害復旧の概要.

Prerequisites

  1. Enable replication in a set of accounts within the same organization, across multiple regions in one cloud service provider or across different cloud service providers.

  2. Create a primary failover group that defines the kinds of objects to replicate, and specifies the target accounts to which to replicate. You can optionally divide the replicated objects across multiple failover groups, for example if some databases should be replicated more frequently than others.

  3. Create at least one secondary failover group (replica) of each primary failover group in one or more secondary accounts.

  4. Refresh (synchronize) each replica with the latest updates to the objects in the failover group. Perform an initial refresh, and set up a schedule to regularly bring the latest changes to each secondary account.

For instructions, see アカウントオブジェクトとデータベースの複製.

ソースアカウントとして使用するターゲットアカウントの昇格

Snowsight または SQL を使用して、ターゲットアカウントをソースアカウントに昇格させることができます（フェールオーバー）。

For more information about the kinds of objects you can specify in a failover group, see 複製グループとフェールオーバーグループ.

Promote a target account to serve as the source account using Snowsight

注釈

Only account administrators can edit a replication or failover group using Snowsight (see 複製設定にSnowsightを使用する場合の制限事項).

For the most consistent and reliable failover experience, select all the applicable failover groups and connections and promote them all at the same time. We refer to this operation as a bulk failover.

To promote a target account to serve as the source account using Snowsight, follow these steps:

  1. Sign in to Snowsight. Make sure to sign in using the target account.

  2. ナビゲーションメニューで Admin » Accounts を選択します。

  3. Select Replication, then select Initiate failover. Doing so brings up a dialog where you make the remaining choices.

  4. Select any failover groups to promote. After the failover, the objects specified in those failover groups become writable on the newly promoted primary account. Those objects become read-only on the account that formerly was the primary and is now a secondary account.

  5. Select Next.

  6. Select any connections to promote. After the failover, those connections connect to the account that you're promoting to be the new primary account.

  7. Select Next.

  8. Select Fail over in the confirmation window.

  9. If any refresh operations are in progress for the failover groups you selected, you can wait for those refreshes to complete, or choose an alternative approach if your failover is urgent and should take priority.

    The default action is to wait for the refreshes to complete. That way, the primary and secondary systems are all in a consistent state when the bulk failover runs. Snowflake uses your currently selected warehouse to poll the status of the ongoing refreshes. If you don't have a selected warehouse, you select one now using the Select warehouse option.

    Or, you can proceed with the failover immediately by selecting Show advanced options.

    • To fail over only the failover groups that aren't currently being refreshed, select Exit with current progress. In that case, you perform additional refreshes later for the groups that were skipped during the bulk failover.

    • To cancel the refresh operations and continue the failover, select Cancel refreshes and force failover. In that case, you might need to clean up any inconsistencies on the secondary system from the interrupted refreshes.

If the failover operation didn't complete for all failover groups, you can perform another bulk failover. Or you can fail over the remaining failover groups one at a time, using the procedure in Promote a single failover group to serve as the primary using Snowsight.

Promote a single failover group to serve as the primary using Snowsight

注釈

Only account administrators can edit a replication or failover group using Snowsight (see 複製設定にSnowsightを使用する場合の制限事項).

To promote a single failover group to be the primary using Snowsight, follow these steps:

  1. Sign in to Snowsight. Make sure to sign in using the target account.

  2. ナビゲーションメニューで Admin » Accounts を選択します。

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

  4. 昇格させたいフェールオーバーグループを探し、行の最後の列にある More メニュー（...）を選択します。

  5. Fail over を選択し、確認ウィンドウで Fail over を選択します。

Tip

You typically use this procedure if you encounter a problem failing over one group, and you need to retry the failover only for that group. To promote an entire account to be the primary, select multiple failover groups and connections and perform a bulk failover. For more information, see Promote a target account to serve as the source account using Snowsight.

SQL を使用した、ソースアカウントとして使用するターゲットアカウントの昇格

To promote a target account to serve as the source account using SQL, you sign in to the target account and execute the ALTER FAILOVER GROUP ... PRIMARY command.

セカンダリフェールオーバーグループをプライマリフェールオーバーグループに昇格する

注釈

このセクションの例は、FAILOVER権限を持つロールによって実行する必要があります。

次の例では、現在の myorg 組織の myaccount2 を、フェールオーバーグループで指定されたオブジェクトの複製用ソースアカウントとして機能するように昇格します。

  1. ターゲットアカウント myaccount2 にサインインします。

  2. アカウント内のフェールオーバーグループを一覧表示します。

    SHOW FAILOVER GROUPS;
    Copy

  3. プライマリフェールオーバーグループとして機能するように昇格させたい各セカンダリフェールオーバーグループに対して、以下のステートメントを実行します。

    ALTER FAILOVER GROUP myfg PRIMARY;
    Copy

    注釈

    ソースリージョンで部分的な停止が発生しても、複製サービスは引き続き利用可能であり、ターゲットリージョンのセカンダリフェールオーバーグループをリフレッシュし続ける可能性があります。

    データの整合性を確保するため、Snowflakeはリフレッシュ操作が進行中の場合、フェールオーバーを防止します。つまり、セカンダリフェールオーバーグループが複製操作によってリフレッシュされている場合は、プライマリとして機能するようにセカンダリフェールオーバグループを昇格させることはできません。この場合、ALTER FAILOVER GROUP ... PRIMARY コマンドはエラーを返します。

進行中のリフレッシュ操作によるフェールオーバーステートメントの失敗の解決

昇格しようとしているセカンダリフェールオーバーグループに対して進行中のリフレッシュ操作がある場合、フェールオーバーステートメントでは以下のエラーが発生します。

Replication group "<GROUP_NAME>" cannot currently be set as primary because it is being
refreshed. Either wait for the refresh to finish or cancel the refresh and try again.

フェールオーバーを成功させるには、以下のステップを完了する必要があります。

  1. 以下のオプションのいずれかを選択し、完了します。

    重要

    SECONDARY_DOWNLOADING_METADATA または SECONDARY_DOWNLOADING_DATA フェーズでリフレッシュ操作を中断すると、ターゲットアカウントの状態が一貫しなくなることがあります。詳細については、 進行中のリフレッシュ操作の現在のフェーズの表示 をご参照ください。

    1. フェールオーバーグループの今後のリフレッシュ操作を中断します。進行中のリフレッシュ操作がある場合は、フェールオーバーする前にその操作が完了するまで待つ必要があります。

      ALTER FAILOVER GROUP myfg SUSPEND;
      Copy

    2. 今後のリフレッシュ操作を中断し、 また 現在進行中のスケジュールされたリフレッシュ操作（もしある場合）をキャンセルします。

      進行中のリフレッシュ操作が手動でトリガーされた場合は、 自動的にスケジュールされなかった、進行中のリフレッシュ操作をキャンセルします。 をご参照ください。

      ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE;
      Copy

      注釈

      ステートメントがリターンする時間と、リフレッシュ操作のキャンセルが終了する時間の間に、若干の遅延が発生する可能性があります。

  2. フェールオーバーグループ myfg のリフレッシュ操作が進行中でないことを確認します。次のクエリは結果を返しません：

    SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';
    Copy

    フェールオーバーグループ myfg のリフレッシュ操作のキャンセルを確認するには、以下のステートメントを実行します。

    SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name = 'CANCELED';
    Copy

  3. これで、セカンダリフェールオーバーグループ（myfg）をプライマリフェールオーバーグループに昇格できます。

    ALTER FAILOVER GROUP myfg PRIMARY;
    Copy

ターゲットアカウントでスケジュールされた複製を再開する

フェールオーバー時に、すべてのセカンダリフェールオーバーグループでスケジュールされた更新が中断されます。自動更新を再開するには、セカンダリフェールオーバーグループのある各 ターゲットアカウント で、 ALTER FAILOVER GROUP ... RESUME を実行する必要があります。

ALTER FAILOVER GROUP myfg RESUME;
Copy

進行中のリフレッシュ操作の現在のフェーズの表示

リフレッシュ操作は、リフレッシュ操作のほとんどの段階で安全にキャンセルすることができます。ただし、 SECONDARY_DOWNLOADING_METADATA または SECONDARY_DOWNLOADING_DATA フェーズでリフレッシュ操作をキャンセルすると、ターゲットアカウントの状態が一貫しなくなる可能性があります。 リフレッシュ操作がこれらのフェーズのいずれかを開始した場合、ソースアカウントの可用性に関係なく、完了まで進みます。フェールオーバーする前にフェーズを完了させることで、レプリカが一貫した状態になるようにします。レプリカが一貫性のある状態になったら、インジェストおよび変換パイプラインを再開または再生して、レプリカを現在の状態に更新できます。

フェールオーバーグループの進行中のリフレッシュ操作の現在のフェーズを表示するには、Information Schema REPLICATION_GROUP_REFRESH_PROGRESS, REPLICATION_GROUP_REFRESH_PROGRESS_BY_JOB, REPLICATION_GROUP_REFRESH_PROGRESS_ALL テーブル関数を使用します。

例えば、フェールオーバーグループ myfg の進行中のリフレッシュ操作の現在のフェーズを表示するには、以下の文を実行します。

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

リフレッシュ操作のフェーズのリストについては、その関数の 使用上の注意 をご参照ください。

自動的にスケジュールされなかった、進行中のリフレッシュ操作をキャンセルします。

複製スケジュールによって自動的にトリガーされなかった進行中のリフレッシュ操作をキャンセルするには、 SYSTEM$CANCEL_QUERY 関数を使用する必要があります。

  1. 以下のオプションのいずれかを使用して、リフレッシュ処理を実行するクエリIDまたはJOB_UUIDを検索します。

    1. 実行中のすべてのリフレッシュ操作のクエリIDsを検索します。

      SELECT query_id, query_text
  FROM TABLE(INFORMATION_SCHEMA.QUERY_HISTORY())
  WHERE query_type = 'REFRESH REPLICATION GROUP'
  AND execution_status = 'RUNNING'
  ORDER BY start_time;
      Copy

      QUERY_TEXT列を使用して、リストからフェールオーバーグループのリフレッシュ操作用のQUERY_IDを識別します。

    2. 特定のフェールオーバーグループ myfg の進行中のリフレッシュ操作の JOB_UUID を検索します。

      SELECT phase_name, start_time, job_uuid
  FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg'))
  WHERE phase_name <> 'COMPLETED' and phase_name <> 'CANCELED';
      Copy

  2. SYSTEM$CANCEL_QUERY 関数と QUERY_ID または JOB_UUID を使用して、リフレッシュ操作をキャンセルします。

    SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>');
    Copy

    次の出力を返します。

    query [<QUERY_ID>] terminated.

  3. 進行中のリフレッシュ操作をキャンセルしたら、 次のステップ に進みます。

Snowpipe Streamingのためのアクティブチャネルを新しく昇格したソースアカウントで再度開く

Snowpipe Streamingによって 投入されたプライマリデータベースのテーブルは、セカンダリデータベースに複製されます。フェールオーバー後、テーブルのアクティブなSnowpipe Streamingチャネルを再度開き、チャネルの不足しているデータ行を再挿入します。

  1. openChannel API を呼び出して、テーブルのアクティブチャネルを再度開きます。

  2. オフセットトークンをフェッチします。

    1. getLatestCommittedOffsetToken API を呼び出す、 または

    2. SHOW CHANNELS コマンドを実行し、テーブルのアクティブチャネルのリストを取得します。

  3. フェッチしたオフセットトークンからチャネルのデータ行を再挿入します。

注釈

これらの手順は、Snowflake Ingest SDK を使用したSnowpipe Streamingにのみ適用され、Kafkaコネクタを使用したSnowpipe Streamingには適用されません。フェールオーバー後にKafkaコネクタを再起動するには、 以下の手順 に従います。

Snowpipe StreamingとKafkaコネクタ

KafkaコネクタとSnowpipe Streamingを使用している場合は、フェールオーバー後に以下のステップに従います。

  1. Kafkaコネクタの構成を更新して、新しく昇格したソースアカウントをポイントするようにします。

  2. SHOW CHANNELS コマンドを実行して、アクティブチャネルのリストとオフセットトークンを取得します。各チャネルはKafkaトピックの単一のパーティションに属します。

  3. これらの各パーティション（チャネル）用に、Kafkaトピックでオフセットを手動でリセットします。

  4. Kafkaコネクタを再起動します。

For more information, see:

言語: 日本語