データベース接続とルーティングの概要

接続

OBProxyは、ユーザーにデータベースへのアクセスとルーティング機能を提供します。ユーザーがOBProxyに接続すれば、OceanBaseデータベースを正常に利用できます。ユーザーがデータベース機能を使用する際、OBProxyとOBServer間でやり取りが行われますが、このやり取りのプロセスはユーザーにとって透過的です。接続管理は、このやり取りプロセスにおける重要なポイントの一つです。 データベース接続には、物理接続と論理接続が含まれます。物理接続とは主にネットワーク接続部分を指し、論理接続とはODPとOceanBaseデータベース間のセッション部分を指します。

特徴

OBProxyの接続管理には3つの特徴があります：

1. プロキシ特性：OBProxyはクライアントでありながらサーバーでもあり、また相互動作がMySQLプロトコル規範に適合することを保証する必要があります。
2. 機能特性：OBProxyは多くの接続機能特性を実装しており、異なるクラスタやテナントへのアクセス、フィジカル・スタンバイ・データベースのサポート、分散環境下でのPREPARE Statement機能、そしてkillやshow processlistなどのコマンドとの互換性を備えています。
3. 高可用性特性：OBProxyはタイムアウト、マシンの状態変化、ネットワークの状態変化などの問題を処理し、バックエンドの異常を隠蔽することで、ユーザーには一切気付かれないようにします。

接続マッピング関係

OceanBaseは単一のデータベースとは異なります。クライアントから単一のデータベースに接続を確立する場合、クライアントとデータベース間には物理的な接続が1つしか存在しません。以下の図を参照してください。

一方、OBProxyを介してOBServerに接続を確立する場合、クライアントとOBProxyの間に物理的な接続が1つあり、OBProxyとOBServerの間には複数の物理的な接続が存在する可能性があります。以下の図を参照してください。 ここで、ClientとOBProxyの接続をクライアント接続と呼び、OBProxyとOBServer間の接続をサーバー接続と呼びます。

クライアントがアクセスするデータが異なるOBServer上にある場合、OBProxyはクライアントに対してOBServerに複数の物理的な接続を確立し、これらの接続を管理・再利用します。クライアント側から見ると、論理的な接続は1つだけ存在します。この仕組みにより、OBProxyは読み書き分離、パーティションテーブルデータルーティング、分散PS、バックエンド異常の隠蔽など、多くの機能特性を提供できます。

接続機能特性

単一のデータベースとは異なり、OBProxyは接続のマッピング関係をM:Nに変更しているため、一部の接続機能では追加処理が必要です。 例を挙げると、ユーザーがshow processlistコマンドで接続数を確認する際、実際にはOBProxyとOBServerノード間の接続数ではなく、クライアントとOBProxy間の接続数を知りたいと考えています。

以下では、一般的な接続機能について詳しく説明します：

• 接続粘着性：OBProxyはまだすべての機能に対する状態同期を実装していません。例えば、トランザクション状態、一時テーブル状態、カーソル状態などです。これらの機能については、OBProxyは後続のリクエストをすべて状態が開始されたノードに送信するだけであり、状態同期を行う必要はありません。ただし、この方式では分散システムの利点を十分に活用できません。そのため、OBProxyは機能の重要性に応じて、徐々に関連機能の分散化をサポートしていきます。
• show processlistとkillコマンドの併用：show processlistコマンドはクライアントとサーバー間の接続を表示するために使用されますが、OBProxyにとっては、show processlistはクライアントとOBProxy間の接続のみを表示し、OBProxyとOBServerノード間の接続は表示しません。killコマンドはクライアント接続を終了させるために使用され、クライアント接続が閉じられると、OBProxyも対応するサーバー接続を閉じます。OBProxyのkillコマンドを使用するには、まず対応するIDを取得する必要があります（show processlistコマンドでIDを取得できます）。
• ロードバランシングの影響：OBProxyはshow processlistとkillコマンドに対して処理を行っているため、show processlistとkillコマンドは両方とも同一のOBProxyに送信されて初めて正常に動作します。パブリッククラウドなどの環境では、OBProxyの前にロードバランサーが配置され、そのロードバランサーの後ろに複数のOBProxyがマウントされています。この場合、show processlistとkillコマンドを実行する際に2つの異なる接続を使用すると、ロードバランシングコンポーネントがリクエストを異なるOBProxyに送信する可能性があります。このような状況では、関連するコマンドの使用は推奨されません。

ルーティング

ルーティングはOceanBase分散データベースにおける重要な機能であり、分散アーキテクチャの下で迅速なデータアクセスを実現するための強力な手段です。

パーティションはOceanBaseデータストレージの基本単位です。テーブルを作成すると、テーブルとパーティションのマッピングが存在します。パーティションテーブルでは、プライマリ/スタンバイ構成を考慮しない場合、1つのテーブルが1つのパーティションに対応します。一方、パーティションテーブルでは、1つのテーブルが複数のパーティションに対応します。

ルーティングは、OBServerのデータ分布に基づいて、データが存在するマシンへの正確なアクセスを実現します。また、一定のポリシーに基づいて、一貫性要件が低い読み取りリクエストをレプリカマシンに送信し、マシンのリソースを最大限に活用することも可能です。ルーティングの選択には、ユーザーのSQL、ユーザー設定ルール、およびOBServerの状態が入力され、出力されるのは利用可能なOBServerのアドレスです。そのルーティングロジックは以下の図に示されています：

SQL解析モジュールでは、OBProxy独自のカスタムParserモジュールが使用され、DML文のデータベース名、テーブル名、Hintのみを解析すればよく、他の複雑な式による推論は不要です。

ルートルール決定モジュールでは、OBProxyは異なる状況に応じて最適なルートルールを決定する必要があります。例えば、強い一貫性を求める読み取りのDMLリクエストは、パーティションが属するログストリームのリーダーレプリカOBServerに送信されることを期待していますが、弱い一貫性を求める読み取りのDMLリクエストやその他のリクエストでは、リーダーレプリカとスレーブレプリカの負荷分散が求められるだけです。OceanBaseクラスタが複数の地域にデプロイされている場合、OBProxyはLDCルーティングも提供しており、同一データセンター内のOBServerに優先的に送信し、次に同一都市内のOBServer、最後に他の都市のOBServerとなります。OceanBaseクラスタが読み書き分離でデプロイされている場合、OBProxyは読み取りゾーン優先、読み取り専用ゾーン、非コンパクション優先などのルールを提供しており、業務側が自身の特性に合わせて設定できます。上記の各ケースはルーティング選択において組み合わせ関係にあり、出力されるのは1つの確定したルートルールです。

ルートテーブルの取得とは、ユーザーのリクエストSQLに基づいて、そのSQLが関与するレプリカの位置を取得することを指します。OBProxyは毎回まずローカルスレッドキャッシュからルートテーブルを取得しようと試み、次にグローバルキャッシュ、最後に非同期タスクを開始してOBServerにルートテーブルの照会を行います。ルートテーブルの更新については、OBProxyはトリガー更新メカニズムを採用しています。OBProxyがルートテーブルに基づいてOBServerに転送するリクエストについて、OBServerがローカルで実行できない場合、応答パケットでOBProxyにフィードバックします。OBProxyはこのフィードバックに基づいて、次回ローカルキャッシュのルートテーブルを強制的に更新するかどうかを決定します。通常、OBServerのコンパクションやロードバランシングによるプライマリ切り替え時にのみ、ルートテーブルが変更されます。

ターゲットOBServerの選択とは、決定されたルートルールに基づいて前のステップで取得したルートテーブルから最適なOBServerを選択し、ブラックリストやグレーアウトリストのチェックを通過した後、最終的なターゲットOBServerとしてリクエストの転送を行うことを指します。