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

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

前提条件

  1. アカウントのセットでプライマリフェールオーバーグループの複製を有効にします。

  2. 1つ以上のアカウントで、プライマリフェールオーバーグループの少なくとも1つのセカンダリフェールオーバーグループ（つまり、レプリカ）を作成し、フェールオーバーグループ内のオブジェクトに対する最新の更新をオブジェクトに反映するよう、定期的にレプリカを更新（つまり、同期）します。

手順については、 複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製 をご参照ください。

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

ターゲットアカウントをソースアカウントとして昇格させるには、新しいソースアカウントとして昇格させたいターゲットアカウントにサインインして、 ALTER FAILOVER GROUP ... PRIMARY コマンドを実行する必要があります。

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

注釈

このセクションの例は、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 テーブル関数を使用します。

例えば、フェールオーバーグループ 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. フェッチしたオフセットトークンからチャネルのデータ行を再挿入します。

Snowpipe StreamingとKafkaコネクタ

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

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

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

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

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

詳細については、次をご参照ください。

言語: 日本語