OceanBaseにおけるOBProxyのアーキテクチャとルーティング戦略

OBProxyの実行環境

OBProxyを正常に動作させるための最低限の環境要件は以下の通りです：

  • OS: Linux Redhat 7u x86_64 以降
  • OSカーネル: 3.10 以降
  • CPU: 2コア以上
  • メモリ: 1GB以上
  • ディスク容量: 特に制限はありませんが、アプリケーションログの保存のため10GB以上を推奨

デプロイ方式には2つのパターンがあります：

  • 集中デプロイ: 複数のOBProxyを単一の管理ポイントで管理
  • クライアントデプロイ: 各クライアントマシンに分散してデプロイ（デーモンモードで稼働）

2つの起動モード

OBProxyには2つの起動モードが存在します：

テストモード

主に開発・デバッグ目的で使用され、ConfigServerへの依存は不要です。

  • ConfigServerはOCPプラットフォームが提供するOBクラスタの物理エントリポイント管理サービスです
  • テストモードでは、クラスタのRSList（IPリスト）を指定して起動します
  • OBProxyクラスタは、作成時に指定されたOceanBaseクラスタのみにアクセス可能です
  • OBProxyクラスタ作成後、接続可能なOBクラスタを追加することはできません

プロダクションモード

ConfigServerが提供するconfig_urlを指定してOBProxyを起動します。

  • ConfigServerサービスはクラスタの設定情報の取得を支援します
  • 単一のConfigServerで複数のOBクラスタのRSList情報を保持でき、OBProxyが複数のOBクラスタに同時にサービスを提供できます
  • OBProxyに接続する際のユーザー名は「root@sys#cluster」のような形式になります（rootがユーザー名、sysがテナント名、clusterがクラスタ名）

ルーティングの実現

OBProxyの実行フローは以下の通りです：

  1. SQL解析：簡易的なパースにより、SQLに関連するテーブル名、データベース名を解析
  2. ルーティングエントリの取得：ユーザーのテナント名、データベース名、テーブル名、パーティションIDに基づき、observerからパーティションのルーティングテーブルを取得
  3. ルーティングエントリのソート：関連する属性に基づいてルーティングテーブル内のIPをソート
    • 読み取り一貫性：強一貫性読み取りまたは弱一貫性読み取り
    • ターゲットサーバーの状態：マージ中か通常状態か
    • ルーティング精度：PS（パーティションレベル）またはTS（テナントレベル）
    • LDC（論理データセンター）のマッチング：ローカル、同じ都市、異なる都市
    • ゾーンのタイプ
    • 読み書き分離のob_route_policy設定値
  4. 混雑状態によるフィルタリング：ルーティングテーブルからIPを順に試し、ブラックリストでフィルタリング
  5. リクエストの転送：ユーザーリクエストをターゲットサーバーに転送

ルーティングに関連する基本概念

これらの基本概念はOBProxyのルーティングと密接に関連しており、設定に応じてOBProxyが総合的なルーティングソートを行います：

  • LDC（論理データセンター）設定：
    • ローカル：同じ都市・同じIDC（データセンター）
    • 同じ都市：同じ都市・異なるIDC（同じリージョン）
    • 異なる都市：異なるリージョン
  • Observerの状態：通常状態 vs マージ中
  • テナントのゾーンタイプ：読み書き型 vs 読み取り専用型
  • ルーティング精度：精度の高いものを優先
    • OBProxyにターゲットパーティションのルーティング情報がある場合（PS）
    • OBProxyにパーティションのルーティング情報がなく、テナントのみのルーティング情報がある場合（TS）

LDC（論理データセンター）概要

  • IDC：インターネットデータセンター、物理的なデータセンターと見なせる
  • LDC：Logical Data Center、IDCの論理的な分割
  • リージョン：地域情報、通常は都市を表し、1つまたは複数のIDCを含む。各IDCには1つまたは複数のゾーンが配置される。1つのOBクラスタは複数のリージョンを含み、各リージョンは複数のIDCを含む

OBProxyの配置例：

OBProxy 1             OBProxy 2                   OBProxy 3
    |                    |                           |
proxy_idc_name='idc1' proxy_idc_name='idc2'       proxy_idc_name='idc3'
    |                    |                           |
IDC1:ZONE1/ZONE2       IDC2:ZONE3                  IDC3:ZONE4/ZONE5

クラスタ構造例：

OBCLUSTER 
   |
  REGION (上海)
   |
  IDC    (浦东机房,浦西机房)
   |
  ZONE   (各データセンターには1つまたは複数のZONEが配置)

LDC設定：クラスタ側の設定

Proxyが都市/データセンター情報に基づいてobserverに近いルーティングを行うには、observerが自身のデータセンターと都市情報を設定し、proxyが自身のデータセンター情報を提供する必要があります。設定SQLは以下の通りです：

alter system modify zone "z1" set region = "SHANGHAI"; 
alter system modify zone "z1" set idc = "zue";

ObserverのLDC設定が有効になっているかを確認するには：

select * from __all_zone;

LDC設定：OBProxy側の設定

Proxyはクライアント＆集中デプロイをサポートするため、LDCのサポートはグローバルレベル＆セッションレベルの両方が可能です。グローバルにデフォルトのLDCを設定するか、各セッションで異なるLDCを指定できます。

グローバルレベル

設定項目proxy_idc_nameを使用してグローバルレベルの現在のIDC情報を制御します（デフォルトは空）。設定項目は起動パラメータ/ログイン時の変更/OCP設定項目更新で行えます。起動スクリプトで-i データセンター名を指定して起動するか、proxy稼働後に以下のように設定します：

alter proxyconfig set proxy_idc_name='データセンター名';

セッションレベル

ユーザー変数set @proxy_idc_name='xx'を使用してセッションレベルの現在のデータセンター情報を制御します。デフォルトでは指定せず、ユーザーが設定できます。

優先順位

セッション変数 > 設定項目。ユーザーがセッション変数proxy_idc_nameを指定した場合、グローバルproxy_idc_name設定を上書きします。

LDC設定：IDC設定とLDCマッチ状況の確認

OBProxyのデータセンター名設定方法：

初回起動時の起動パラメータ（推奨）

./bin/obproxy -p2883 -e -o 
obproxy_config_server_url='ocp_config_server_url',proxy_idc_name='hz001' -n trade

Proxy設定項目の変更

mysql> alter proxyconfig set proxy_idc_name='hz001';

内部コマンド「show proxyinfo idc;」を実行することで、proxy内部で認識しているLDC配置状況を確認できます。

OBProxyの主なルーティング戦略

書き込みリクエスト

書き込みリクエストはReadWriteゾーンの主レプリカにルーティングされます。

読み取りリクエスト

強一貫性読み取り

  • デフォルトのルーティング戦略は強一貫性読み取りルーティング戦略です
  • パーティションのリーダーレプリカのデータを読み取る必要があり、SQLは関連パーティションのリーダーサーバーに転送して実行される必要があります。これにより、リアルタイムの最新データを取得できます
  • 強一貫性読み取りは読み書きの一貫性が高い要件があるシナリオに適しています

弱一貫性読み取り

  • 主従バランスルーティング戦略（デフォルト）
  • フォロワー優先読み取り戦略
  • 読み書き分離戦略

弱一貫性読み取り：設定方法

OceanBaseデータベースでは、ob_read_consistencyパラメータを設定することで一貫性読み取りを設定できます。

グローバルレベル

ユーザーが現在のテナントのグローバルシステムセッション変数を設定します：

set global ob_read_consistency='weak';

これは現在のテナントのすべてのセッションに有効になります（現在のセッションは有効になりません）。

セッションレベル

  • set ob_read_consistency='weak'を設定することで、現在接続中のセッションのみに有効になります
  • SQL Hint：selectに/*+ read_consistency(weak)*/のHintを追加すると、そのステートメントのみ有効になります

弱一貫性読み取り：主従バランスルーティング戦略（デフォルト）

OBProxyのデフォルトのルーティング方式は主従バランスルーティングです。

  • まずリージョンを考慮し、同じリージョンのOBServerが異なるリージョンのOBServerよりも優先されます
  • 次にマージ状態を考慮し、マージ状態ではないOBServerがマージ状態のOBServerよりも優先されます
  • 最後にIDC関係を考慮し、同じIDCのOBServerが異なるIDCのOBServerよりも優先されます

詳細なルーティング順序：

  1. 同じリージョン、同じIDCでマージ状態ではないOBServer
  2. 同じリージョン、異なるIDCでマージ状態ではないOBServer
  3. 同じリージョン、同じIDCでマージ状態のOBServer
  4. 同じリージョン、異なるIDCでマージ状態のOBServer
  5. 異なるリージョンでマージ状態ではないOBServer
  6. 異なるリージョンでマージ状態のOBServer

弱一貫性読み取り：フォロワー優先読み取り戦略

OBProxyはフォロワー優先読み取りルーティング戦略をサポートしており、ユーザーレベルのシステム変数proxy_route_policyで制御します。フォロワー優先読み取りは弱一貫性読み取り時にのみ有効で、主従バランス選択ではなくフォロワーの読み取りを優先します。

rootユーザーでクラスタのsysテナントにログイン後、以下のコマンドでユーザーシステム変数proxy_route_policyを設定します：

設定コマンド

SET @proxy_route_policy='[ポリシー]';

確認コマンド

select @proxy_route_policy;｜show proxysession variables;

follower_firstの場合

ルーティングロジックはフォロワーを優先（クラスタがマージ状態でも）：

  1. 同じデータセンターでマージ状態ではないフォロワー
  2. 同じ都市で異なるデータセンターでマージ状態ではないフォロワー
  3. 同じデータセンターでマージ状態のフォロワー
  4. 同じ都市で異なるデータセンターでマージ状態のフォロワー
  5. 同じデータセンターでマージ状態ではないプライマリ
  6. 同じ都市で異なるデータセンターでマージ状態ではないプライマリ
  7. 異なる都市でマージ状態ではないフォロワー
  8. 異なる都市でマージ状態のフォロワー
  9. 異なる都市でマージ状態ではないプライマリ
  10. 異なる都市でマージ状態のプライマリ

unmerge_follower_firstの場合

ルーティングロジックはマージ状態ではないフォロワー（フォロワーノード）を優先：

  1. 同じデータセンターでマージ状態ではないフォロワー
  2. 同じ都市で異なるデータセンターでマージ状態ではないフォロワー
  3. 同じデータセンターでマージ状態ではないプライマリ
  4. 同じ都市で異なるデータセンターでマージ状態ではないプライマリ
  5. 同じデータセンターでマージ状態のフォロワー
  6. 同じ都市で異なるデータセンターでマージ状態のフォロワー
  7. 異なる都市でマージ状態ではないフォロワー
  8. 異なる都市でマージ状態ではないプライマリ
  9. 異なる都市でマージ状態のフォロワー
  10. 異なる都市でマージ状態のプライマリ

注：他の値が指定された場合、通常の弱一貫性読み取りの主従バランスルーティングロジックに退化します。

弱一貫性読み取り：読み書き分離戦略

読み書き分離デプロイでは、クライアントは書き込みリクエストをReadWriteゾーンの主レプリカにルーティングし、弱一貫性読み取りリクエストをReadOnlyゾーンにルーティングする必要があります。

rootユーザーでクラスタのビジネステナントにログインし、以下のコマンドでグローバルレベルのシステム変数ob_route_policyを対応する値に設定します（デフォルト値はreadonly_zone_first）：

設定コマンド

set @@global.ob_route_policy=readonly_zone_first;

値/ルーティング戦略/説明

値 ルーティング戦略 説明
readonly_zone_first 1.ローカル通常状態読み取り庫PS
2.同じ都市通常状態読み取り庫PS
3.ローカルマージ状態読み取り庫PS
4.同じ都市マージ状態読み取り庫PS		 デフォルト値、読み取り庫を優先してアクセス
優先順位: ゾーンタイプ > マージ状態 > IDC状態
only_readonly_zone 1.ローカル通常状態読み取り庫PS
2.同じ都市通常状態読み取り庫PS
3.ローカルマージ状態読み取り庫PS
4.同じ都市マージ状態読み取り庫PS
5.ローカル通常状態読み取り庫TS		 読み取り庫のみにアクセス
優先順位: マージ状態 > IDC状態
unmerge_zone_first 1.ローカル通常状態読み取り庫PS
2.同じ都市通常状態読み取り庫PS
3.ローカル通常状態書き込み庫PS
4.同じ都市通常状態書き込み庫PS		 マージ状態ではないゾーンを優先してアクセス
優先順位：マージ状態 > ゾーンタイプ > IDC状態

OBProxyの使用制限

ProxyのパーサーがSQLに基づいてサーバーを選択する際には、以下の特別なロジックがあります：

  • ProxyのパーサーはBegin/START/TRANSACTON/SET/その他DMLのみを解析し、他の単語で始まるステートメントがあれば、パーサーは直接スキップし、そのステートメントにテーブル名が含まれていないと判断します
  • Proxyのパーサーは最初の実体テーブル名を含むステートメントに基づいてルーティングし、ステートメント全体にテーブル名が含まれていない場合、リクエストを前のSQLが送信されたサーバーに送信します

Observerは実行計画のタイプに基づき、Proxyがリクエストを正しいサーバーにルーティングしたかどうかを判断し、ルーティングに失敗した場合、Proxyはlocationを更新します。現在のフィードバックメカニズムは以下の通りです：

  • サーバーは最初のDMLのヒット状況を返します

使用例 - 推奨される使用方法

以下のいくつかの場合（selectはupdate/delete/replace/insertと同等に扱えます）、Proxyはリクエストを正しいサーバーに送信でき、サーバーはProxyのヒット状況に基づいてフィードバックできます：

  • begin; select * from t1; commit;
  • set @@autocommit = 1; insert into t1 values(); set @@autocommit = 0;
  • select * from t1; insert into t2 values;
  • set @@ob_trx_timeout = 10000000; begin; select * from t1; commit;

以下の場合、Proxyはリクエストを前のSQLで使用されたサーバーに送信します：

  • create table t1 (id int primary key); create table t2 (id int primary key);

推奨されない使用例

以下のいくつかの場合（最初のDMLが実体テーブルではない）、Proxyはリクエストを正しいサーバーに送信できますが、サーバーからのフィードバックが不正確な可能性があるため、推奨されません：

  • select '1'; select * from t1;
  • select '1' from dual; select * from t1;

以下の場合、Proxyはリクエストを正しいサーバーにルーティングできる可能性がありますが、サーバー側のフィードバックが不正確な可能性があるため、推奨されません：

  • create table t1 (id int primary key); insert into t1 values();

以下のいくつかの場合、Proxyはリクエストを前回使用したサーバーに強制ルーティングし、サーバー側のフィードバックが不正確な可能性があるため、推奨されません：

  • show warnings; select * from t1;
  • show count(*) errors; select * from t1;

タグ: OceanBase OBProxy データベースルーティング 論理データセンター 読み書き分離

7月2日 17:58 投稿

ホットタグ

©2026 異端開発室