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

接続

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としてリクエストの転送を行います。