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

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

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. テナントのZone、Server、ログストリームレプリカ情報を取得します。

   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
   

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