フェイルオーバー

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

使用上の制限

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

  スタンバイテナントまたはそのクラスタの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コマンドを実行してプライマリテナントに切り替わる際、そのテナントにサービス名が設定されている場合、システムは自動的にそのテナントのサービス名を削除します。ただし、元のプライマリテナントのサービス名は削除されません。

  例えば、サービス名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. 元のプライマリバックアップに基づいてスタンバイテナントを作成する

   • 新しいプライマリテナントのFailoverポイントを確認します。ビューDBA_OB_TENANTSからテナントのFLASHBACK_LOG_SCNを取得します。
   • 元のプライマリのバックアップとアーカイブからスタンバイテナントを復元し、復元ポイントを新しいプライマリテナントのFailoverポイントに指定します。

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

関連ドキュメント

• DBA_OB_TENANT_flashBACK_LOG_SCN
• CDB_OB_TENANT_flashBACK_LOG_SCN
• DBA_OB_TENANTS