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としてマークします。
説明
上記のクラスタレベルの構成パラメータの値は、SHOW PARAMETERSステートメントを使用して確認できます。例えば、SHOW PARAMETERS LIKE 'server_permanent_offline_time';と入力します。
Root Serviceは、ハートビートデータパケットに基づいて、OBServerの以下の稼働状態を取得できます：
OBServerのハートビートデータパケットが存在し、ハートビートデータパケット内のOBServerのディスク状態が正常です。この状態では、Root ServiceはOBServerが正常に稼働していると判断します。
OBServerのハートビートデータパケットが存在し、ハートビートデータパケット内のOBServerのディスク状態が異常です。この状態では、Root Serviceはobserverプロセスはまだ存在するものの、OBServerのディスクに障害が発生していると判断します。この状態では、Root ServiceはそのOBServer上のすべてのリーダーレプリカを切り替えようと試みます。
OBServerのハートビートデータパケットが存在せず、OBServerのハートビートデータパケットの損失時間が比較的短く、OBServerのハートビート状態が
lease_expiredの場合、Root ServiceはOBServerの稼働状態をinactiveに設定するのみで、他の処理は行いません。OBServerのハートビートデータパケットが存在せず、OBServerのハートビートデータパケットの損失時間が
server_permanent_offline_timeを超え、OBServerのハートビート状態がpermanent_offlineの場合、Root ServiceはそのOBServer上のデータレプリカを処理し、そのOBServer上に含まれるデータレプリカをPaxosメンバーグループから削除し、他の利用可能なOBServer上でデータを補完することで、データレプリカのPaxosメンバーグループの完全性を保証します。
ノードの隔離
ODPは、OBServerの異常な状態（例えば、ACTIVE状態でstop_timeフィールドが0より大きいstopped状態やINACTIVE状態など）を感知し、アプリケーショントラフィックを異常ノードにルーティングすることを防ぎます。
特定のノードが不安定な場合、時折サービスを提供する可能性があり、応答速度の低下などさまざまな異常が発生する可能性があります。クライアントがこのノードに接続されると、クライアント側で不安定さを感じることになります。OceanBaseデータベースでは、ノードを隔離するためにSTOP SERVERコマンドを提供しています。隔離後、そのノードは外部へのサービス提供を停止し、ODPもリクエストをそのノードにルーティングしません。これにより、診断・交換・修理などの作業を安全に行うことができ、運用保守および緊急時に非常に有効です。Stop Serverは、残りのすべてのレプリカが過半数を満たしているか、ログ同期が完了しているかを確認します。条件を満たしていない場合、Stop Server操作は失敗として返されます。条件を満たしている場合、障害ノード上のリーダーがすべて移行した後にシステムは成功を返します。Stop Serverが成功すると、Kill observerプロセスを含むあらゆる運用保守作業を実行できることを保証します。Stop Serverの詳細な操作については、ノードの隔離を参照してください。
ノードの隔離は、単一データセンターの障害シナリオに適用されます：
非切断型障害（例えば、NICのパケット損失によるマシンの不安定化）では、ノードの隔離に強く依存します。そうでない場合、繰り返しリーダーが切り替わり、アプリケーションに影響を与える可能性があります。
切断型障害（例えば、マシンの直接ダウン）では、ノードの隔離に強く依存しません。その代わりに、
oceanbase.DBA_OB_SERVERSビューでノードの状態をINACTIVEとしてマークし、アプリケーショントラフィックを隔離します。
ノードの隔離またはリーダーの障害が発生した場合、選出がトリガーされます。選出サービスの優先順位メカニズムは、ユーザー指定のPrimary Zoneやマシンの異常状態などを考慮し、より優れたレプリカをリーダーレプリカとして選択することを保証します。
手動でのリーダー切り替え
ノードを隔離する以外にも、ログストリームレプリカのプライマリ/フォロワーの役割を切り替えることで、能動的にリーダーを切り替えることができます。
能動的なリーダー切り替えの手順は以下のとおりです：
rootユーザーでクラスタのsysテナントにログインします。接続例は以下のとおりです。データベースへの接続時は、実際の環境に基づいてください。
obclient -h10.xx.xx.xx -P2883 -uroot@sys#obdemo -p***** -Aデータベースへの接続方法の詳細については、データベース接続の概要（MySQLモード）およびデータベース接続の概要（Oracleモード）を参照してください。
テナントのゾーン、サーバー、ログストリームレプリカ情報を取得します。
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 setCDB_OB_LS_LOCATIONSビューの詳細については、CDB_OB_LS_LOCATIONSを参照してください。以下のコマンドを実行してリーダーを切り替えます。
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;操作終了後、ビューを再度照会して、レプリカの役割が正常に変更されたかどうか確認します。
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
能動的なリーダー切り替えは、データセンター災害復旧や都市間災害復旧シナリオに適しています。リーダーを指定されたゾーンまたはリージョンに切り替えることで、アプリケーションのトラフィック分布により適合させることができます。