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

接続

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間の接続数であり、OBProxyとOBServerノード間の接続数ではありません。

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

• 接続粘着性：OBProxyはまだすべての機能の状態同期を実装していません。例えば、トランザクション状態、一時テーブル状態、cursor状態などです。これらの機能については、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つの確定したルーティングルールとなります。

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

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