フェイルオーバー

プライマリテナントが利用不能になった場合、スタンバイテナントをプライマリテナントに切り替えてサービスを継続できます。

使用上の制限

• フェイルオーバーを実行する際は、スタンバイテナントのすべてのログストリームのレプリカがオンラインである必要があります。そうでない場合は、対応するレプリカが永続的にオフラインになるのを待つ必要があります。

  スタンバイテナントまたはそのクラスタのsysテナントは、それぞれDBA_OB_LSビューまたはCDB_OB_LSビューを使用して、すべてのログストリームレプリカがオンラインかどうかを確認できます。ログストリームレプリカの詳細については、レプリカの紹介を参照してください。

• フェイルオーバーを実行する際、対応するプライマリテナントの状態はチェックされません。そのため、プライマリテナント障害によるディザスタリカバリ要件以外にも、特定の時点における独立したプライマリテナントのスナップショットを取得し、後の業務検証に利用するニーズシナリオでもフェイルオーバー操作を使用できます。

• サービス名で作成されたセッション内では、フェイルオーバーコマンドを実行することはできません。サービスに関する操作および説明については、サービスの作成を参照してください。

  注意

  フェイルオーバーを実行する際、フェイルオーバーコマンドを実行するテナントにサービス名が存在する場合、システムはそのテナントのサービス名を自動的に削除します。

背景

フェイルオーバー操作はログファイルにのみ変更を加え、データファイルには変更しません。

OceanBaseデータベースでは各テナントに複数のログストリームが存在するため、フェイルオーバー操作は実行完了後にデータの一貫性が保たれている状態でなければなりません。そのため、システムはすべてのログストリームの同期ポイントの中からSCNが最小の値をフェイルオーバーの実行ポイントとして選択します。フェイルオーバー操作を実行すると、テナント内のすべてのログストリームがこのポイントまで統一的にロールバックされます。

手順

1. 管理者ユーザーとして、スタンバイテナントまたはそのクラスタのsysテナントにログインします。

2. ACTIVATE STANDBY VERIFYコマンドを実行し、ACTIVATE STANDBYコマンドが正常に実行できるかどうかを確認します。

   • スタンバイが存在するクラスタのsysテナントでACTIVATE STANDBY VERIFYコマンドを実行する

     ALTER SYSTEM ACTIVATE STANDBY TENANT [=] tenant_name VERIFY;
     

     例：

     ALTER SYSTEM ACTIVATE STANDBY TENANT = mysql VERIFY;
     

   • スタンバイテナントでACTIVATE STANDBY VERIFYコマンドを実行する

     ALTER SYSTEM ACTIVATE STANDBY VERIFY;
     

     コマンド実行後、OKが返された場合は検証に合格し、次の手順に進むことができます。

     エラーが発生した場合は、表示されたメッセージに従い、ドキュメントSwitchoverまたはFailover関連の問題を参照して処理した後、再度このコマンドを実行してください。

3. 検証に合格したら、ACTIVATE STANDBYコマンドを実行して、スタンバイテナントをプライマリテナントに切り替えます。

   • スタンバイが存在するクラスタのsysテナントでスタンバイテナントをプライマリテナントに切り替える

     ALTER SYSTEM ACTIVATE STANDBY TENANT = tenant_name;
     

   • スタンバイテナントが自身をプライマリテナントに切り替える

     ALTER SYSTEM ACTIVATE STANDBY;
     

4. DBA_OB_TENANTS ビューをクエリし、スタンバイテナントがプライマリテナントに切り替わったかどうかを確認します。

   • スタンバイテナントが存在するクラスタの sys テナントでビューをクエリします。

     obclient [oceanbase]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
     

   • スタンバイテナントでビューをクエリします。

     MySQLモード：

     obclient [oceanbase]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM oceanbase.DBA_OB_TENANTS;
     

     Oracleモード：

     obclient [SYS]> SELECT TENANT_NAME, TENANT_TYPE, TENANT_ROLE, SWITCHOVER_STATUS FROM SYS.DBA_OB_TENANTS;
     

   クエリ結果の例は以下のとおりです。

   +-----------------+-------------+-------------+-------------------+
   | TENANT_NAME     | TENANT_TYPE | TENANT_ROLE | SWITCHOVER_STATUS |
   +-----------------+-------------+-------------+-------------------+
   | standby_tenant  | USER        | PRIMARY     | NORMAL            |
   +-----------------+-------------+-------------+-------------------+
   1 row in set
   

   クエリ結果によると、スタンバイテナントの TENANT_ROLE が PRIMARY に変わり、SWITCHOVER_STATUS が NORMAL であれば、スタンバイテナントのプライマリ切り替えは成功したことを意味します。

Failover後の注意事項

• テナントがFailoverコマンドを実行してプライマリテナントに切り替わる過程で、そのテナントにサービス名が設定されている場合、システムは自動的にそのテナントのサービス名を削除します。ただし、元のプライマリテナントのサービス名は削除されません。

  例えば、サービス名 service1 の下にプライマリテナント tenantA と対応するスタンバイテナント tenantB がある場合、テナント tenantB でFailoverコマンドを実行してプライマリテナントに切り替えると、元のプライマリ/スタンバイ関係から外れるため、tenantB のサービス名 service1 はシステムによって削除されますが、tenantA のサービス名 service1 は保持されます。

• Failover操作は、すべてのログストリームで同期されたデータを一貫性ポイントまで復元し、そのポイント以前のすべてのログストリームのデータが完全であることを保証します。そのため、Failover操作を実行した後は：

  • 元のプライマリテナントがスタンバイに降格した後、新しいプライマリテナントとして接続することはサポートされません。

次のステップ：元のプライマリテナントのスタンバイテナントを新しいプライマリテナントに接続する

OceanBaseは、フェイルオーバー後、スタンバイテナントのログを指定されたポイントまで切り詰める運用保守コマンドを使用して、元のプライマリテナントのスタンバイテナントを新しいプライマリテナントに接続することをサポートしています。

• 接続するスタンバイテナントは、元のプライマリテナントがダウンする前から存在しているものでもかまいません。
• 元のプライマリテナントがダウンした後、元のプライマリテナントの物理バックアップから復元されたものでもかまいません。

構文

スタンバイテナントログ切り詰め運用保守コマンドは、スタンバイテナントのログを指定されたポイントまで切り詰めることをサポートしており、この指定されたポイントはスタンバイテナントの同期ポイント以上である必要があります。

ALTER SYSTEM FLASHBACK STANDBY LOG TO SCN = $flashback_log_scn [TENANT = 'tenant_name'];

パラメータの説明は以下のとおりです：

• flashback_log_scn：スタンバイテナントのログを切り詰める指定されたポイント。
• tenant_name：指定するテナントのテナント名。テナントに直接接続してログインする場合は、この部分を省略できます。

注意事項

次のステップを実行する前に、以下の条件を確認する必要があります：

• このコマンドを使用する前に、スタンバイテナントの同期が停止し、復元ソースが空に戻っていることを確認する必要があります。
• テナントがオフラインのマシン上に有効なレプリカを保持することは許可されません。
• スタンバイテナントでのみログ切り詰め操作が許可されます。テナントのSTATUSおよびSWITCHOVER_STATUSはどちらもNORMALでなければなりません。SWITCHOVER_STATUSはFLASHBACK_AND_STAY_STANDBY_STATUSでも構いません。
• 設定するログ切り詰めポイントは、テナントの同期ポイント以上である必要があります。
• このコマンドは、テナントのサービス名（存在する場合）を自動的に削除します。
• テナントのSWITCHOVER_STATUSがFLASHBACK_AND_STAY_STANDBY_STATUSの場合、テナントの同期を継続したり、テナントの復元ソースを変更したりすることは許可されません。

手順

1. スタンバイテナントの同期を停止し、テナントのSYNC_SCNがRECOVERY_UNTIL_SCNと等しいことを確認します。

   ALTER SYSTEM RECOVER STANDBY [TENANT [=] tenant_name] CANCEL;
   
   SELECT TENANT_ID, SYNC_SCN, RECOVERY_UNTIL_SCN
   FROM DBA_OB_TENANTS WHERE TENANT_ID=xxxx;
   

2. スタンバイテナントの復元ソースを空に設定し、ビューCDB_OB_LOG_RESTORE_SOURCEをクエリして変更が成功したことを確認します。

   ALTER SYSTEM SET LOG_RESTORE_SOURCE = '' [TENANT [=] tenant_name];
   
   SELECT * FROM CDB_OB_LOG_RESTORE_SOURCE WHERE TENANT_ID = xxxx;
   -- またはユーザーテナントでクエリする
   SELECT * FROM DBA_OB_LOG_RESTORE_SOURCE;
   

3. ログ切り詰めポイントを確認します。運用保守コマンドはログ切り詰めポイントについて、テナントの同期ポイント以上であるという1つの要件のみを持っています。意味のある値の設定方法については、以下の「シナリオにおけるベストプラクティス」セクションを参照してください。ここでの手順は、ログ切り詰めポイントがテナントの同期ポイント以上の任意の値であると仮定して説明しています。

4. ビューDBA_OB_TENANTSをクエリします。

   • 設定しようとしているログトリミングのシナリオポイントがスタンバイテナントの SYNC_SCN 以上であることを確認します。
   • スタンバイテナントの STATUS が NORMAL、SWITCHOVER_STATUS が NORMAL または FLASHBACK_AND_STAY_STANDBY_STATUS であることを確認します。

   SELECT TENANT_ID, SYNC_SCN, STATUS, SWITCHOVER_STATUS
   FROM DBA_OB_TENANTS WHERE TENANT_ID=xxxx;
   

5. テナントの合法的なレプリカがオフライン状態のマシン上に存在することは許可されません。

   SELECT COUNT(*)
   -> FROM CDB_OB_LS_LOCATIONS
   -> WHERE (SVR_IP, SVR_PORT) IN (
   ->     SELECT SVR_IP, SVR_PORT
   ->     FROM DBA_OB_SERVERS
   ->     WHERE STATUS = 'INACTIVE'
   -> )
   -> AND TENANT_ID = xxxx;
   /* 結果が0の場合、オフライン状態のマシン上に合法的なレプリカは存在しないことを意味します */
   

6. スタンバイテナントのログトリミング運用コマンドを実行します。

   ALTER SYSTEM FLASHBACK STANDBY LOG TO SCN = $flashback_log_scn [TENANT = 'tenant_name'];
   

シナリオにおけるベストプラクティス

このセクションでは、Failover操作におけるいくつかのシナリオベストプラクティスについて説明します。

新しいプライマリテナントの選択と他のスタンバイテナントの切り替え

一プライマリ・マルチスタンバイ構成では、同期シナリオポイントが最大のスタンバイテナントを特定し、それをプライマリテナントにFailoverします。その後、残りのスタンバイテナントを新しいプライマリテナントに接続します。これにより、新しいプライマリテナントができた後、元のプライマリテナントの他のスタンバイテナントが無効になるのを防ぎます。具体的には、以下の2つの操作を実行する必要があります：

1. 新しいプライマリテナントの選出

   • 元のプライマリテナントのすべてのスタンバイテナントに対して、同期停止コマンドを送信します。
   • プライマリテナント下のすべてのスタンバイテナントの LOG_RESTORE_SOURCE を空に設定します。
   • すべてのスタンバイテナントの同期シナリオポイントを読み取り、同期シナリオポイントが最大のスタンバイテナントを特定し、それをプライマリテナントにFailoverします。特定のスタンバイテナントを新しいプライマリテナントとして指定する必要がある場合、その新しいプライマリテナントよりも同期シナリオポイントが大きいスタンバイテナントは、新しいプライマリテナントに接続できません。

2. スタンバイテナントのFLASHBACKによる新しいプライマリデータベースへの接続

   • 新しいプライマリテナントのFailoverシナリオポイントを確認します。ビュー DBA_OB_TENANTS から新しいプライマリテナントの FLASHBACK_LOG_SCN を取得します。
   • 残りのスタンバイテナントに FLASHBACK コマンドを送信し、その FLASHBACK_SCN を新しいプライマリのFailoverシナリオポイントに設定します。
   • 残りのスタンバイテナントの LOG_RESTORE_SOURCE を新しいプライマリに設定します。
   • スタンバイテナントの復元終点を UNLIMITED に設定します。
   • スタンバイテナントに新しいプライマリテナントと同じサービス名（該当する場合）を設定します。

元のプライマリテナントの物理バックアップを利用して新しいプライマリテナントのスタンバイテナントを作成する

既存のプライマリテナントの物理バックアップを利用して、新しいプライマリテナントのスタンバイテナントを作成します。これにより、新しいプライマリテナントがスタンバイテナントを作成する前に物理バックアップの完了を待つ必要がなくなり、既存のプライマリテナントの物理バックアップが消費されなくなることを防ぎます。プライマリテナントにスタンバイテナントを構築する際に、新たに「既存のプライマリテナントのバックアップからスタンバイテナントを復元する」というオプションが追加されました。このシナリオは実際には前述のシナリオと同じですが、スタンバイテナントの作成時期が異なります。以下の2つの操作を完了する必要があります：

1. 既存のプライマリテナントのバックアップからスタンバイテナントを作成する

   • 新しいプライマリテナントのフェイルオーバー・ポイントを確認します。ビューDBA_OB_TENANTSからテナントのFLASHBACK_LOG_SCNを取得します。
   • 既存のプライマリテナントのバックアップおよびアーカイブからスタンバイテナントを復元し、復元ポイントを新しいプライマリテナントのフェイルオーバー・ポイントに指定します。

2. 前のシナリオの2番目の手順を実行します：スタンバイテナントをFLASHBACKで新しいプライマリテナントに接続します。

関連ドキュメント

• DBA_OB_TENANT_flashBACK_LOG_SCN
• CDB_OB_TENANT_flashBACK_LOG_SCN
• DBA_OB_TENANTS