アカウントオブジェクトのフェールオーバー¶
このトピックでは、障害復旧のために、異なる リージョン の複数のアカウントオブジェクトに複製されたデータベースをフェールオーバーするために必要なステップについて説明します。
前提条件¶
- アカウントのセットでプライマリフェールオーバーグループの複製を有効にします。 
- 1つ以上のアカウントでプライマリフェールオーバーグループの少なくとも1つのセカンダリフェールオーバーグループ(レプリカ)を作成し、フェールオーバーグループ内のオブジェクトに対する最新の更新でレプリカを定期的にリフレッシュ(同期)します。 
手順については、 複数のアカウント間にわたるデータベースとアカウントオブジェクトの複製 をご参照ください。
ソースアカウントとして使用するターゲットアカウントの昇格¶
Snowsight または SQL を使用して、ターゲットアカウントをソースアカウントに昇格させることができます(フェールオーバー)。
フェールオーバーの詳細情報については、 複製グループとフェールオーバーグループ をご覧ください。
Snowsightを使用した、ソースアカウントとして使用するターゲットアカウントの昇格¶
注釈
アカウント管理者のみが、 Snowsight を使用して複製グループまたはフェイルオーバーグループを編集できます (複製設定にSnowsightを使用する場合の制限事項 を参照)。
ターゲットアカウントをソースアカウントとして昇格させるには、ターゲットアカウントにサインインしている必要があります。
- Snowsight にサインインします。 
- ナビゲーションメニューで Admin » Accounts を選択します。 
- Replication を選択してから、 Groups を選択します。 
- 昇格させたいフェールオーバーグループを探し、行の最後の列にある More メニュー(...)を選択します。 
- Fail over を選択し、確認ウィンドウで Fail over を選択します。 
SQL を使用した、ソースアカウントとして使用するターゲットアカウントの昇格¶
SQL を使用してターゲットアカウントをソースアカウントとして昇格させるには、ターゲットアカウントにサインインして ALTER FAILOVER GROUP ... PRIMARY コマンドを実行する必要があります。
セカンダリフェールオーバーグループをプライマリフェールオーバーグループに昇格する¶
注釈
このセクションの例は、FAILOVER権限を持つロールによって実行する必要があります。
次の例では、現在の myorg 組織の myaccount2 を、フェールオーバーグループで指定されたオブジェクトの複製用ソースアカウントとして機能するように昇格します。
- ターゲットアカウント - myaccount2にサインインします。
- アカウント内のフェールオーバーグループを一覧表示します。 - SHOW FAILOVER GROUPS; 
- プライマリフェールオーバーグループとして機能するように昇格させたい各セカンダリフェールオーバーグループに対して、以下のステートメントを実行します。 - ALTER FAILOVER GROUP myfg PRIMARY; - 注釈 - ソースリージョンで部分的な停止が発生しても、複製サービスは引き続き利用可能であり、ターゲットリージョンのセカンダリフェールオーバーグループをリフレッシュし続ける可能性があります。 - データの整合性を確保するため、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.
フェールオーバーを成功させるには、以下のステップを完了する必要があります。
- 以下のオプションのいずれかを選択し、完了します。 - 重要 - SECONDARY_DOWNLOADING_METADATA または SECONDARY_DOWNLOADING_DATA フェーズでリフレッシュ操作を中断すると、ターゲットアカウントの状態が一貫しなくなることがあります。詳細については、 進行中のリフレッシュ操作の現在のフェーズの表示 をご参照ください。 - フェールオーバーグループの今後のリフレッシュ操作を中断します。進行中のリフレッシュ操作がある場合は、フェールオーバーする前にその操作が完了するまで待つ必要があります。 - ALTER FAILOVER GROUP myfg SUSPEND; 
- 今後のリフレッシュ操作を中断し、 また 現在進行中のスケジュールされたリフレッシュ操作(もしある場合)をキャンセルします。 - 進行中のリフレッシュ操作が手動でトリガーされた場合は、 自動的にスケジュールされなかった、進行中のリフレッシュ操作をキャンセルします。 をご参照ください。 - ALTER FAILOVER GROUP myfg SUSPEND IMMEDIATE; - 注釈 - ステートメントがリターンする時間と、リフレッシュ操作のキャンセルが終了する時間の間に、若干の遅延が発生する可能性があります。 
 
- フェールオーバーグループ - 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'; - フェールオーバーグループ - myfgのリフレッシュ操作のキャンセルを確認するには、以下のステートメントを実行します。- SELECT phase_name, start_time, job_uuid FROM TABLE(INFORMATION_SCHEMA.REPLICATION_GROUP_REFRESH_HISTORY('myfg')) WHERE phase_name = 'CANCELED'; 
- これで、セカンダリフェールオーバーグループ( - myfg)をプライマリフェールオーバーグループに昇格できます。- ALTER FAILOVER GROUP myfg PRIMARY; 
ターゲットアカウントでスケジュールされた複製を再開する¶
フェールオーバー時に、すべてのセカンダリフェールオーバーグループでスケジュールされた更新が中断されます。自動更新を再開するには、セカンダリフェールオーバーグループのある各 ターゲットアカウント で、 ALTER FAILOVER GROUP ... RESUME を実行する必要があります。
ALTER FAILOVER GROUP myfg RESUME;
進行中のリフレッシュ操作の現在のフェーズの表示¶
リフレッシュ操作は、リフレッシュ操作のほとんどの段階で安全にキャンセルすることができます。ただし、 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')
  );
リフレッシュ操作のフェーズのリストについては、その関数の 使用上の注意 をご参照ください。
自動的にスケジュールされなかった、進行中のリフレッシュ操作をキャンセルします。¶
複製スケジュールによって自動的にトリガーされなかった進行中のリフレッシュ操作をキャンセルするには、 SYSTEM$CANCEL_QUERY 関数を使用する必要があります。
- 以下のオプションのいずれかを使用して、リフレッシュ処理を実行するクエリIDまたはJOB_UUIDを検索します。 - 実行中のすべてのリフレッシュ操作のクエリ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; - QUERY_TEXT列を使用して、リストからフェールオーバーグループのリフレッシュ操作用のQUERY_IDを識別します。 
- 特定のフェールオーバーグループ - 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'; 
 
- SYSTEM$CANCEL_QUERY 関数と QUERY_ID または JOB_UUID を使用して、リフレッシュ操作をキャンセルします。 - SELECT SYSTEM$CANCEL_QUERY('<QUERY_ID | JOB_UUID>'); - 次の出力を返します。 - query [<QUERY_ID>] terminated.
- 進行中のリフレッシュ操作をキャンセルしたら、 次のステップ に進みます。 
Snowpipe Streamingのためのアクティブチャネルを新しく昇格したソースアカウントで再度開く¶
Snowpipe Streamingによって 投入されたプライマリデータベースのテーブルは、セカンダリデータベースに複製されます。フェールオーバー後、テーブルのアクティブなSnowpipe Streamingチャネルを再度開き、チャネルの不足しているデータ行を再挿入します。
- openChannel API を呼び出して、テーブルのアクティブチャネルを再度開きます。 
- オフセットトークンをフェッチします。 - getLatestCommittedOffsetToken API を呼び出す、 または 
- SHOW CHANNELS コマンドを実行し、テーブルのアクティブチャネルのリストを取得します。 
 
- フェッチしたオフセットトークンからチャネルのデータ行を再挿入します。 
注釈
これらの手順は、Snowflake Ingest SDK を使用したSnowpipe Streamingにのみ適用され、Kafkaコネクタを使用したSnowpipe Streamingには適用されません。フェールオーバー後にKafkaコネクタを再起動するには、 以下の手順 に従います。
Snowpipe StreamingとKafkaコネクタ¶
KafkaコネクタとSnowpipe Streamingを使用している場合は、フェールオーバー後に以下のステップに従います。
- Kafkaコネクタの構成を更新して、新しく昇格したソースアカウントをポイントするようにします。 
- SHOW CHANNELS コマンドを実行して、アクティブチャネルのリストとオフセットトークンを取得します。各チャネルはKafkaトピックの単一のパーティションに属します。 
- これらの各パーティション(チャネル)用に、Kafkaトピックでオフセットを手動でリセットします。 
- Kafkaコネクタを再起動します。 
詳細については、次をご参照ください。