データベース層の高可用性

OceanBaseデータベースは、高コストパフォーマンスな一般的なサーバーを基盤とし、Paxosプロトコルを採用しています。同一データを複数（>= 3）ノードの過半数以上に書き込むため、少数派ノードで障害が発生してもデータ損失は一切なく、RPO = 0が保証されます。リーダーレプリカに障害が発生した場合でも、残りのフォロワーレプリカが短期間で自動的に新しいリーダーを選出し、外部の介入なくサービスを継続提供するため、RTO < 8秒を保証し、強整合性と高可用性のバランスを実現します。ユーザーはまた、同都市三センター、二地域三センター、三地域五センターなど、柔軟なデプロイメントモデルを採用することで、同都市内ディザスタリカバリや地理的冗長性によるディザスタリカバリなど、各レベルでのロスレスディザスタリカバリ能力を実現できます。

Root Service

OceanBaseデータベースでは、Root Serviceがクラスタのノード管理を担当します。各OBServerは、ハートビートデータパケット（heartbeat）を介して、定期的に（2秒ごとに）Root Serviceに自身のプロセス状態を報告します。Root ServiceはOBServerのハートビートデータパケットを監視することで、現在のOBServerプロセスの動作状態を取得します。

OBServerのハートビート状態に関連する構成パラメータは以下の通りです：

• lease_time

  クラスタレベルの構成パラメータlease_timeは、ハートビートリース期間を設定するために使用されます。この構成パラメータのデフォルト値は10秒です。この構成パラメータの詳細については、lease_timeを参照してください。

  Root Serviceが累計でlease_time時間以上、特定のOBServerから任意のハートビートデータパケットを受信していない場合、Root Serviceはそのobserverプロセスが一時的に切断されたと判断し、そのOBServerサーバーのハートビート状態をlease_expiredとマークします。

• server_permanent_offline_time

  クラスタレベルの構成パラメータserver_permanent_offline_timeは、ノードのハートビート中断時間のしきい値を設定するために使用されます。つまり、ノードのハートビートが中断してからどの程度の時間が経過すると永久オフラインとみなされ、永久オフラインとなったノード上のデータレプリカを自動的に補完する必要があるかを示します。この構成パラメータのデフォルト値は3600秒です。この構成パラメータの詳細については、server_permanent_offline_timeを参照してください。

  Root Serviceが累計でserver_permanent_offline_time時間以上、特定のOBServerから任意のハートビートデータパケットを受信していない場合、Root Serviceはそのobserverプロセスが切断されたと判断し、そのOBServerのハートビート状態をpermanent_offlineとマークします。

Root Serviceはハートビートデータパケットから、OBServerの以下の動作状態を把握できます：

• OBServerのハートビートデータパケットが存在し、そのデータパケット内のOBServerのディスク状態が正常である場合。この状態では、Root ServiceはOBServerが正常に動作していると判断します。

• OBServerのハートビートデータパケットが存在するが、そのデータパケット内のOBServerのディスク状態が異常である場合。この状態では、Root Serviceはobserverプロセスは存在するがOBServerのディスクに障害が発生したと判断します。この状態では、Root ServiceはそのOBServer上のすべてのリーダーレプリカを切り離す試みを行います。

• OBServerのハートビートデータパケットが存在せず、そのデータパケットの欠落時間がまだ短く、OBServerのハートビート状態がlease_expiredである場合。この状態では、Root ServiceはOBServerの動作状態をinactiveに設定するのみで、他の処理は行いません。

• OBServerのハートビートデータパケットが存在せず、そのデータパケットの欠落時間がserver_permanent_offline_timeを超え、OBServerのハートビート状態がpermanent_offlineである場合。この場合、Root ServiceはそのOBServer上のデータレプリカを処理し、そのOBServer上に含まれるデータレプリカをPaxosメンバーグループから削除し、他の利用可能なOBServer上でデータを補完することで、データレプリカのPaxosメンバーグループの完全性を保証します。

ノードの隔離

ODPは、OBServerの異常な状態（例：stopped（ACTIVE状態でstop_timeフィールドが0より大きい）、INACTIVE状態など）を検知し、アプリケーショントラフィックを異常なノードにルーティングすることを回避します。

特定のノードが不安定な場合、時折サービスを提供するものの、応答が遅くなるなど様々な異常が発生する可能性があります。クライアントがそのノードに接続すると、不安定性を感じることになります。OceanBaseデータベースは、ノードを隔離するためのSTOP SERVERコマンドを提供しています。隔離後、そのノードは外部にサービスを提供せず、ODPもそのノードにリクエストをルーティングしないため、診断・交換・修理などの操作を安全に実施できます。これは運用保守および緊急時対応における強力なツールです。Stop Serverは、残りのすべてのレプリカが多数派を満たしているか、ログ同期が完了しているかをチェックします。条件を満たさない場合、Stop Server操作は失敗として返されます。条件を満たす場合、障害ノード上のリーダーがすべて切り離されるのを待って、システムは成功を返します。Stop Serverが成功すると、Kill observerプロセスを含む任意の運用保守操作を実施できることが保証されます。Stop Serverの詳細な操作については、ノードの隔離を参照してください。

ノード分離は、単一データセンター障害シナリオに適用されます：

• 非切断型障害（例：NICのパケットロスによるマシンの不安定）はノード分離に強く依存しており、そうでなければ反復的なリーダー切り替えが発生し、アプリケーションに影響を与えます。

• 切断型障害（例：マシンの直接ダウン）はノード分離に強く依存していません。この場合、oceanbase.DBA_OB_SERVERS ビューでノード状態を INACTIVE とマークし、アプリケーショントラフィックを分離します。

ノード分離またはリーダーに障害が発生すると、選挙がトリガーされます。選挙サービスの優先順位メカニズムは、ユーザーが指定したプライマリゾーンやマシンの異常状態などを考慮し、より優れたレプリカをプライマリレプリカとして選択することを保証します。

手動でのリーダー切り替え

ノードを分離する以外に、ログストリームレプリカのプライマリ/フォロワー役割を切り替えるために、手動でリーダーを切り替えることもできます。

手動でリーダーを切り替える操作手順は以下のとおりです：

1. root ユーザーでクラスタの sys テナントにログインします。

   接続例は以下のとおりですが、データベースへの接続時は実際の環境に準じてください。

   obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -A
   

   データベース接続の詳細な操作手順については、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。

2. テナントのゾーン、サーバー、ログストリームレプリカ情報を取得します。

   obcllient [(none)]> SELECT a.TENANT_ID,a.LS_ID,a.SVR_IP,a.SVR_PORT,a.ZONE,a.role,b.TENANT_NAME,b.TENANT_TYPE FROM oceanbase.CDB_OB_LS_LOCATIONS a, oceanbase.DBA_OB_TENANTS b WHERE a.TENANT_ID=b.TENANT_ID;
   +-----------+-------+----------------+----------+-------+----------+-------------+-------------+
   | TENANT_ID | LS_ID | SVR_IP         | SVR_PORT | ZONE  | role     | TENANT_NAME | TENANT_TYPE |
   +-----------+-------+----------------+----------+-------+----------+-------------+-------------+
   |         1 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | sys         | SYS         |
   |         1 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | sys         | SYS         |
   |         1 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | sys         | SYS         |
   |      1001 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | META$1002   | META        |
   |      1001 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | META$1002   | META        |
   |      1001 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | META$1002   | META        |
   |      1002 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | mysql001    | USER        |
   |      1002 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | mysql001    | USER        |
   |      1002 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | mysql001    | USER        |
   |      1002 |  1001 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | mysql001    | USER        |
   |      1002 |  1001 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | mysql001    | USER        |
   |      1002 |  1001 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | mysql001    | USER        |
   |      1009 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | META$1010   | META        |
   |      1009 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | META$1010   | META        |
   |      1009 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | META$1010   | META        |
   |      1010 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | oracle001   | USER        |
   |      1010 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | oracle001   | USER        |
   |      1010 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | oracle001   | USER        |
   |      1010 |  1001 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | oracle001   | USER        |
   |      1010 |  1001 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | oracle001   | USER        |
   |      1010 |  1001 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | oracle001   | USER        |
   |      1035 |     1 | xx.xx.xx.218   |     2882 | zone3 | FOLLOWER | META$1036   | META        |
   |      1035 |     1 | xx.xx.xx.237   |     2882 | zone1 | LEADER   | META$1036   | META        |
   |      1035 |     1 | xx.xx.xx.238   |     2882 | zone2 | FOLLOWER | META$1036   | META        |
   +-----------+-------+----------------+----------+-------+----------+-------------+-------------+
   24 rows in set
   

   CDB_OB_LS_LOCATIONS ビューの詳細については、CDB_OB_LS_LOCATIONSを参照してください。

3. 以下のコマンドを実行してリーダーを切り替えます。

   ALTER SYSTEM SWITCH REPLICA role LS [=] ls_id SERVER [=] 'ip:port' TENANT = tenant_name;
   

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

   • role：レプリカの役割を指定します。ログストリームレプリカの役割をLEADERまたはFOLLOWERに設定します。

   • ls_id：変更対象のログストリームレプリカのIDです。

   • ip:port：変更対象のログストリームレプリカが存在するホストのIPアドレスとRPCポートです。

   • tenant_name：変更対象のログストリームレプリカが属するテナントです。

   例：

   obclient [(none)]> ALTER SYSTEM SWITCH REPLICA LEADER LS = 1001 SERVER = 'xx.xx.xx.218:2882' TENANT = oracle001;
   

4. 操作終了後、ビューを再度クエリして、レプリカの役割が正常に変更されたか確認できます。

   obclient [(none)]> SELECT * FROM oceanbase.CDB_OB_LS_LOCATIONS WHERE TENANT_ID = 1010;
   +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+
   | CREATE_TIME                | MODIFY_TIME                | TENANT_ID | LS_ID | SVR_IP         | SVR_PORT | SQL_PORT | ZONE  | ROLE     | MEMBER_LIST                                                       | PAXOS_REPLICA_NUMBER | REPLICA_TYPE |
   +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+
   | 2022-12-26 18:28:49.389751 | 2023-01-11 12:02:38.275763 |      1010 |     1 | xx.xx.xx.218   |     2882 |     2881 | zone3 | FOLLOWER | NULL                                                              |                 NULL | FULL         |
   | 2022-12-26 18:28:49.389601 | 2022-12-26 18:28:54.441143 |      1010 |     1 | xx.xx.xx.237   |     2882 |     2881 | zone1 | LEADER   | xx.xx.xx.218:2882:1,xx.xx.xx.237:2882:1,xx.xx.xx.238:2882:1       |                    3 | FULL         |
   | 2022-12-26 18:28:49.390567 | 2023-01-11 12:02:37.970540 |      1010 |     1 | xx.xx.xx.238   |     2882 |     2881 | zone2 | FOLLOWER | NULL                                                              |                 NULL | FULL         |
   | 2022-12-26 18:29:01.334732 | 2023-01-11 11:59:31.899581 |      1010 |  1001 | xx.xx.xx.218   |     2882 |     2881 | zone3 | LEADER   | xx.xx.xx.218:2882:1,xx.xx.xx.237:2882:1,xx.xx.xx.238:2882:1       |                    3 | FULL         |
   | 2022-12-26 18:29:01.335629 | 2023-01-11 12:02:37.709677 |      1010 |  1001 | xx.xx.xx.237   |     2882 |     2881 | zone1 | FOLLOWER | NULL                                                              |                 NULL | FULL         |
   | 2022-12-26 18:29:01.335822 | 2023-01-11 12:02:37.970540 |      1010 |  1001 | xx.xx.xx.238   |     2882 |     2881 | zone2 | FOLLOWER | NULL                                                              |                 NULL | FULL         |
   +----------------------------+----------------------------+-----------+-------+----------------+----------+----------+-------+----------+-------------------------------------------------------------------+----------------------+--------------+
   6 rows in set
   

能動的リーダー切り替えは、データセンター災害復旧および都市単位の災害復旧シナリオに適しています。リーダーを指定したゾーンまたはリージョンに切り替えることで、アプリケーションのトラフィック分布により適合させることができます。