TiProxy の概要

TiProxyはPingCAPの公式プロキシコンポーネントです。クライアントとTiDBサーバーの間に配置され、負荷分散、接続の持続性、サービス検出、その他のTiDB機能を提供します。

TiProxy はオプションのコンポーネントです。サードパーティ製のプロキシコンポーネントを使用することも、プロキシを使用せずに TiDBサーバーに直接接続することもできます。

次の図は、TiProxy のアーキテクチャを示しています。

主な特徴

TiProxy は、接続の移行、フェイルオーバー、サービスの検出、および迅速な展開を提供します。

接続の移行

TiProxy は、クライアント接続を切断することなく、ある TiDBサーバーから別の TiDB サーバーに接続を移行できます。

下図に示すように、クライアントは当初TiProxyを介してTiDB 1に接続します。接続の移行後、クライアントは実際にはTiDB 2に接続します。TiDB 1がオフラインになりそうになった場合、またはTiDB 1とTiDB 2の接続比率が設定されたしきい値を超えた場合、接続の移行がトリガーされます。クライアントは接続の移行を認識しません。

接続の移行は通常、次のシナリオで発生します。

TiDBサーバーがスケールイン、ローリングアップグレード、またはローリングリスタートを実行する場合、TiProxy はオフラインになる予定の TiDBサーバーから他の TiDB サーバーへの接続を移行して、クライアント接続を維持できます。
TiDBサーバーがスケールアウトを実行すると、TiProxy は既存の接続を新しい TiDBサーバーに移行し、クライアント接続プールをリセットせずにリアルタイムの負荷分散を実現できます。

フェイルオーバー

TiDBサーバーがメモリ不足 (OOM) になる危険がある場合、または PD または TiKV に接続できない場合、TiProxy は問題を自動的に検出し、接続を別の TiDBサーバーに移行して、継続的なクライアント接続を確保します。

サービス検出

TiDBサーバーがスケールインまたはスケールアウトを実行する際、共通のロードバランサーを使用している場合は、TiDBサーバーリストを手動で更新する必要があります。しかし、TiProxyは手動操作なしでTiDBサーバーリストを自動的に検出します。

迅速な展開

TiProxy はTiUP 、 TiDB Operator 、 TiDBダッシュボード、およびグラファナに統合されており、組み込みの仮想 IP 管理をサポートしているため、導入、運用、および管理のコストが削減されます。

ユーザーシナリオ

TiProxy は次のシナリオに適しています。

接続の持続性：TiDBサーバーがスケールイン、ローリングアップグレード、またはローリングリスタートを実行すると、クライアント接続が切断され、エラーが発生します。クライアントに冪等なエラーリトライメカニズムがない場合、手動でエラーを確認して修正する必要があり、人件費が大幅に増加します。TiProxyはクライアント接続を維持できるため、クライアントはエラーを報告しません。
頻繁なスケールインとスケールアウト：アプリケーションのワークロードは定期的に変化する可能性があります。コスト削減のため、TiDBをクラウドにデプロイし、ワークロードに応じてTiDBサーバーを自動的にスケールインおよびスケールアウトすることができます。ただし、スケールインはクライアントの接続を切断する可能性があり、スケールアウトは負荷の不均衡を引き起こす可能性があります。TiProxyはクライアント接続を維持し、負荷分散を実現します。
CPU負荷の不均衡：バックグラウンドタスクが大量のCPUリソースを消費したり、接続間のワークロードが大きく変動してCPU負荷の不均衡が生じたりした場合、TiProxyはCPU使用率に基づいて接続を移行することで負荷分散を実現します。詳細については、 CPUベースの負荷分散参照してください。
TiDBサーバーのメモリ不足：クエリの暴走によってTiDBサーバーのメモリが不足した場合、TiProxyはOOMリスクを事前に検出し、他の正常な接続を別のTiDBサーバーに移行することで、クライアントの継続的な接続を確保します。詳細については、メモリベースの負荷分散参照してください。

TiProxy は次のシナリオには適していません。

パフォーマンスの影響を受けやすい：TiProxyのパフォーマンスはHAProxyや他のロードバランサよりも低いため、TiProxyを使用する場合は、同等のパフォーマンスレベルを維持するためにより多くのCPUリソースを予約する必要があります。詳細については、 TiProxy パフォーマンステストレポートを参照してください。
コストの影響を受けやすい：TiDB クラスターがハードウェアロードバランサー、仮想 IP、または Kubernetes が提供するロードバランサーを使用している場合、TiProxy を追加するとコストが増加します。さらに、クラウド上の複数のアベイラビリティゾーンに TiDB クラスターを展開する場合、TiProxy を追加するとアベイラビリティゾーン間のトラフィックコストも増加します。
予期せぬTiDBサーバーのダウンタイムに対するフェイルオーバー：TiProxyは、TiDBサーバーがオフラインの場合、または計画通りに再起動された場合にのみクライアント接続を維持できます。TiDBサーバーが予期せずオフラインになった場合、接続は依然として切断されます。

TiProxy が適しているシナリオでは TiProxy を使用し、アプリケーションがパフォーマンスに敏感な場合は HAProxy またはその他のプロキシを使用することをお勧めします。

インストールと使用方法

このセクションでは、 TiUPを使用して TiProxy をデプロイおよび変更する方法について説明します。TiProxy をスケールアウトすることで、 TiProxyで新しいクラスターを作成するまたは既存のクラスターで TiProxy を有効にするいずれかを実行できます。

注記：
TiUPが v1.16.1 以降であることを確認してください。

その他の展開方法については、次のドキュメントを参照してください。

TiDB Operatorを使用して TiProxy をデプロイするには、 TiDB Operatorドキュメントを参照してください。
TiUPを使用して TiProxy をローカルに素早く展開するには、 TiProxyをデプロイ参照してください。

TiProxyでクラスターを作成する

次の手順では、新しいクラスターを作成するときに TiProxy をデプロイする方法について説明します。

TiDB インスタンスを構成します。
TiProxyを使用する場合、TiDBにgraceful-wait-before-shutdown設定する必要があります。この値は、アプリケーションの最長トランザクションの所要時間より少なくとも10秒長く設定する必要があります。これにより、TiDBサーバーがオフラインになった場合にクライアント接続が中断されるのを回避できます。トランザクションの所要時間はTiDB モニタリングダッシュボードのトランザクションメトリックで確認できます。詳細については、制限事項参照してください。
設定例は次のとおりです。
```
server_configs:
  tidb:
    graceful-wait-before-shutdown: 30
```
TiProxy インスタンスを構成します。
TiProxy の高可用性を確保するには、少なくとも 2 つの TiProxy インスタンスを展開し、 ha.virtual-ipとha.interface設定して仮想 IP を構成し、使用可能な TiProxy インスタンスにトラフィックをルーティングすることをお勧めします。
次の点に注意してください。
- ワークロードの種類と最大QPSに基づいて、TiProxyインスタンスのモデルと数を選択してください。詳細については、 TiProxy パフォーマンステストレポート参照してください。
- 通常、TiProxyインスタンス数はTiDBサーバーインスタンス数よりも少ないため、TiProxyのネットワーク帯域幅がボトルネックになりやすくなります。例えばAWSでは、同シリーズのEC2インスタンスのベースラインネットワーク帯域幅はCPUコア数に比例しません。ネットワーク帯域幅がボトルネックになる場合は、TiProxyインスタンスをより多くの小さなインスタンスに分割することでQPSを向上させることができます。詳細はネットワーク仕様参照してください。
- トポロジ設定ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにtiup cluster upgrade実行した際にTiProxyが自動的にアップグレードされることがなくなり、TiProxyのアップグレードによってクライアント接続が切断されることを防ぐことができます。
TiProxy のテンプレートの詳細については、 TiProxyトポロジのシンプルなテンプレート参照してください。
TiDB クラスタトポロジファイル内の構成項目の詳細については、 TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル参照してください。
設定例は次のとおりです。
```
component_versions:
  tiproxy: "v1.3.2"
server_configs:
  tiproxy:
    ha.virtual-ip: "10.0.1.10/24"
    ha.interface: "eth0"
tiproxy_servers:
  - host: 10.0.1.11
    port: 6000
    status_port: 3080
  - host: 10.0.1.12
    port: 6000
    status_port: 3080
```
クラスターを起動します。
TiUPを使用してクラスターを起動するには、 TiUPドキュメント参照してください。
TiProxy に接続します。
クラスタがデプロイされると、TiDBサーバーポートとTiProxyポートが同時に公開されます。クライアントはTiDBサーバーに直接接続するのではなく、TiProxyポートに接続する必要があります。

既存のクラスターで TiProxy を有効にする

TiProxy がデプロイされていないクラスターの場合は、TiProxy インスタンスをスケールアウトすることで TiProxy を有効にすることができます。

TiProxy インスタンスを構成します。

tiproxy.tomlような別のトポロジファイルで TiProxy を構成します。

component_versions:
  tiproxy: "v1.3.2"
server_configs:
  tiproxy:
    ha.virtual-ip: "10.0.1.10/24"
    ha.interface: "eth0"
tiproxy_servers:
  - host: 10.0.1.11
    deploy_dir: "/tiproxy-deploy"
    port: 6000
    status_port: 3080
  - host: 10.0.1.12
    deploy_dir: "/tiproxy-deploy"
    port: 6000
    status_port: 3080

TiProxy をスケールアウトします。
tiup cluster scale-outコマンドを使用して TiProxy インスタンスをスケールアウトします。例:
```
tiup cluster scale-out <cluster-name> tiproxy.toml
```
TiProxyをスケールアウトすると、 TiUPはTiDB用の自己署名証明書security.session-token-signing-certとsecurity.session-token-signing-key自動的に構成します。この証明書は接続の移行に使用されます。
TiDB 構成を変更します。
TiProxyを使用する場合、TiDBにgraceful-wait-before-shutdown設定する必要があります。TiDBサーバーがオフラインになった際にクライアント接続が中断されるのを防ぐため、この値はアプリケーションの最長トランザクションの所要時間より少なくとも10秒長く設定する必要があります。トランザクションの所要時間はTiDB モニタリングダッシュボードのトランザクションメトリックで確認できます。詳細については、制限事項参照してください。
設定例は次のとおりです。
```
server_configs:
  tidb:
    graceful-wait-before-shutdown: 30
```
TiDB 構成を再読み込みします。
TiDBは自己署名証明書とgraceful-wait-before-shutdown設定されているため、設定を有効にするにはtiup cluster reloadコマンドを使用して設定を再読み込みする必要があります。設定を再読み込みすると、TiDBはローリング再起動を実行し、クライアント接続が切断されることに注意してください。
```
tiup cluster reload <cluster-name> -R tidb
```
TiProxy に接続します。
TiProxy を有効にすると、クライアントは TiDBサーバーポートではなく TiProxy ポートに接続する必要があります。

TiProxy構成の変更

TiProxy がクライアント接続を維持するには、必要な場合を除き TiProxy を再起動しないでください。そのため、TiProxy の設定項目のほとんどはオンラインで変更できます。オンライン変更をサポートする設定項目の一覧については、 TiProxyの設定参照してください。

TiUPを使用して TiProxy の設定を変更する場合、変更する構成項目がオンライン変更をサポートしている場合は、 --skip-restartオプションを使用して TiProxy の再起動を回避できます。

TiProxy をアップグレードする

TiProxy をデプロイする場合は、TiDB クラスターをアップグレードしても TiProxy がアップグレードされないように、TiProxy のバージョンを指定することをお勧めします。

TiProxy をアップグレードする必要がある場合は、アップグレードコマンドに--tiproxy-version追加して、TiProxy のバージョンを指定します。

tiup cluster upgrade <cluster-name> <version> --tiproxy-version <tiproxy-version>

注記：
このコマンドは、クラスターのバージョンが変更されない場合でも、TiDB クラスターをアップグレードして再起動します。

TiDBクラスタを再起動します

tiup cluster restart使用して TiDB クラスタを再起動すると、TiDB サーバはローリング再起動されず、クライアント接続が切断されます。したがって、このコマンドの使用は避けてください。

代わりに、 tiup cluster upgrade使用してクラスターをアップグレードするか、 tiup cluster reload使用して構成を再ロードすると、 TiDB サーバーがローリング再起動されるため、クライアント接続は影響を受けません。

他のコンポーネントとの互換性

TiProxy は TiDB v6.5.0 以降のバージョンのみをサポートします。
TiProxyのTLS接続にはTiDBと互換性のない機能があります。詳細についてはSecurity参照してください。
TiDB ダッシュボードと Grafana は、v7.6.0 から TiProxy をサポートしています。
TiUP はv1.14.1 から TiProxy をサポートし、 TiDB Operator はv1.5.1 から TiProxy をサポートします。
TiProxy のステータスポートによって提供されるインターフェイスは TiDBサーバーのインターフェイスとは異なるため、 TiDB Lightning使用してデータをインポートする場合、ターゲットデータベースは TiProxy のアドレスではなく、TiDBサーバーのアドレスにする必要があります。

Security

TiProxyはTLS接続を提供します。クライアントとTiProxy間のTLS接続は、以下のルールに従って有効化されます。

TiProxy のsecurity.server-tls構成が TLS 接続を使用しないように設定されている場合、クライアントが TLS 接続を有効にしているかどうかに関係なく、クライアントと TiProxy 間の TLS 接続は有効になりません。
TiProxy のsecurity.server-tlsの構成が TLS 接続を使用するように設定されている場合、クライアントと TiProxy 間の TLS 接続は、クライアントが TLS 接続を有効にした場合にのみ有効になります。

TiProxy と TiDBサーバー間の TLS 接続は、次のルールに従って有効化されます。

TiProxyのsecurity.require-backend-tls trueに設定されている場合、クライアントがTLS接続を有効にしているかどうかに関係なく、TiProxyとTiDBサーバーは常にTLS接続を有効にします。TiProxyのsecurity.sql-tls TLSを使用しないように設定されているか、TiDBサーバーがTLS証明書を設定していない場合、クライアントはエラーを報告します。
TiProxy のsecurity.require-backend-tls falseに設定され、TiProxy のsecurity.sql-tls TLS で構成され、TiDBサーバーがTLS 証明書で構成されている場合、TiProxy と TiDBサーバーは、クライアントが TLS 接続を有効にした場合にのみ TLS 接続を有効にします。
TiProxy のsecurity.require-backend-tls falseに設定されている場合、TiProxy のsecurity.sql-tls TLS を使用しないように設定されているか、TiDBサーバーがTLS 証明書を構成していない場合、TiProxy と TiDBサーバーはTLS 接続を有効にしません。

TiProxy には、TiDB と互換性のない次の動作があります。

STATUSとSHOW STATUSステートメントは異なるTLS情報を返す可能性があります。5 STATUSステートメントはクライアントとTiProxy間のTLS情報を返し、 SHOW STATUSステートメントはTiProxyとTiDBサーバー間のTLS情報を返します。
TiProxy は証明書ベースの認証サポートしていません。そうでない場合、クライアントと TiProxy 間の TLS 証明書が TiProxy と TiDBサーバー間の TLS 証明書と異なるため、クライアントがログインに失敗する可能性があります。TiDBサーバーはTiProxy 上の TLS 証明書に基づいて TLS 証明書を検証します。

制限事項

次のシナリオでは、TiProxy はクライアント接続を維持できません。

TiDB が予期せずオフラインになりました。TiProxy は、TiDBサーバーがオフラインの場合、または計画どおりに再起動された場合にのみクライアント接続を維持し、TiDBサーバーのフェイルオーバーをサポートしません。
TiProxy はスケールイン、アップグレード、または再起動を実行します。TiProxy がオフラインになると、クライアント接続は切断されます。
TiDBは接続を積極的に切断します。例えば、セッションがwait_timeout以上リクエストを送信しない場合、TiDBは接続を積極的に切断し、TiProxyもクライアント接続を切断します。

TiProxy は次のシナリオでは接続を移行できないため、クライアント接続が中断されたり、負荷分散が失敗したりします。

長時間実行される単一のステートメントまたは単一のトランザクション: 実行時間が、TiDBサーバーで構成された値graceful-wait-before-shutdownから 10 秒を引いた値を超えています。
カーソルを使用していて、時間内に完了しない: セッションはカーソルを使用してデータを読み取りますが、TiDBサーバーで構成された値graceful-wait-before-shutdownから 10 秒を引いた時間が経過してもデータの読み取りが完了しないか、カーソルが閉じられません。
セッションはローカル一時テーブルを作成します。
セッションはユーザーレベルロックを開催します。
セッションはテーブルロックを開催します。
セッションでプリペアドステートメントが作成されましたが、プリペアドステートメントは無効です。例えば、プリペアドステートメントの作成後に、そのプリペアドステートメントに関連するテーブルが削除された場合などです。
セッションはセッションレベル実行プランのバインディングを作成しましたが、バインディングが無効です。例えば、バインディングの作成後に、バインディングに関連するテーブルが削除されています。
セッションが作成された後、セッションで使用されたユーザーが削除されるか、ユーザー名が変更されます。

サポートされているコネクタ

TiProxy では、クライアントが使用するコネクタが認証プラグインサポートしている必要があります。そうでない場合、接続に失敗する可能性があります。

次の表に、サポートされているコネクタの一部を示します。

言語	コネクタ	サポートされる最小バージョン
Java	MySQL コネクタ/J	5.1.19
C	libmysqlクライアント	5.5.7
行く	Go SQLDriver	1.4.0
JavaScript	MySQL コネクタ/Node.js	1.0.2
JavaScript	mysqljs/mysql	2.15.0
JavaScript	ノード-mysql2	1.0.0-rc-6
PHP	mysqlnd	5.4
パイソン	MySQL コネクタ/Python	1.0.7
パイソン	パイMySQL	0.7

一部のコネクタはデータベース接続に共通ライブラリを呼び出しますが、これらのコネクタは表に記載されていません。対応するライブラリの必要なバージョンについては、上記の表を参照してください。例えば、MySQL/Rubyはデータベース接続にlibmysqlclientを使用するため、MySQL/Rubyが使用するlibmysqlclientのバージョンは5.5.7以降である必要があります。

TiProxyリソース

TiProxy リリースノート
TiProxy の問題 : TiProxy GitHub の問題を一覧表示します