TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiProxy の概要

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

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

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

TiProxy アーキテクチャ

主な特徴

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

接続の移行

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

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

TiProxy接続の移行

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

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

サービス検出

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

迅速な展開

TiProxy はTiUP 、 TiDB Operator 、 TiDBダッシュボード 、およびグラファナに統合されており、導入、運用、および管理のコストが削減されます。

ユーザーシナリオ

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

  • 接続の永続性: TiDBサーバーがスケールイン、ローリング アップグレード、またはローリング リスタートを実行すると、クライアント接続が切断され、エラーが発生します。クライアントにべき等エラー再試行メカニズムがない場合は、手動でエラーを確認して修正する必要があり、人件費が大幅に増加します。TiProxy はクライアント接続を維持できるため、クライアントはエラーを報告しません。
  • 頻繁なスケールインとスケールアウト: アプリケーションのワークロードは定期的に変化する可能性があります。コストを節約するために、クラウドに TiDB をデプロイし、ワークロードに応じて TiDB サーバーを自動的にスケールインおよびスケールアウトすることができます。ただし、スケールインによってクライアントが切断される可能性があり、スケールアウトによって負荷が不均衡になる可能性があります。TiProxy はクライアント接続を維持し、負荷分散を実現できます。

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

  • パフォーマンスに敏感: TiProxy のパフォーマンスは HAProxy や他のロードバランサーに比べて低いため、TiProxy を使用すると QPS が低下します。詳細についてはTiProxy パフォーマンス テスト レポートを参照してください。
  • コストに敏感: TiDB クラスターがハードウェア ロード バランサー、仮想 IP、または Kubernetes が提供するロード バランサーを使用している場合、TiProxy を追加するとコストが増加します。さらに、クラウド上のアベイラビリティ ゾーン全体に TiDB クラスターを展開する場合、TiProxy を追加するとアベイラビリティ ゾーン全体のトラフィック コストも増加します。
  • TiDBサーバーのフェイルオーバー: TiProxy は、TiDBサーバーがオフラインの場合、または計画どおりに再起動された場合にのみクライアント接続を維持できます。TiDBサーバーが予期せずオフラインになった場合、接続は切断されたままになります。

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

インストールと使用方法

このセクションでは、 TiUP を使用して TiProxy をデプロイおよび変更する方法について説明します。Kubernetes でTiDB Operator を使用して TiProxy をデプロイする方法については、 TiDB Operatorのドキュメント参照してください。

TiProxy をデプロイ

  1. TiUP v1.15.0 より前では、自己署名証明書を手動で生成する必要があります。

    TiDB インスタンスの自己署名証明書を生成し、その証明書をすべての TiDB インスタンスに配置して、すべての TiDB インスタンスが同じ証明書を持つようにします。詳細な手順については、 自己署名証明書を生成する参照してください。

  2. TiDB インスタンスを構成します。

    TiProxy を使用する場合は、TiDB インスタンスに対して次の項目も構成する必要があります。

    設定例は次のとおりです。

    server_configs:
  tidb:
    security.session-token-signing-cert: "/var/sess/cert.pem"
    security.session-token-signing-key: "/var/sess/key.pem"
    security.ssl-ca: "/var/ssl/ca.pem"
    security.ssl-cert: "/var/ssl/cert.pem"
    security.ssl-key: "/var/ssl/key.pem"
    graceful-wait-before-shutdown: 15

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

    TiProxy の高可用性を確保するには、少なくとも 2 つの TiProxy インスタンスを展開することをお勧めします。ハードウェア ロード バランサーを使用して各 TiProxy インスタンスにトラフィックを分散するか、仮想 IP を構成してトラフィックを使用可能な TiProxy インスタンスにルーティングすることができます。

    TiProxy インスタンスのモデルと数を選択するときは、次の要素を考慮してください。

    • ワークロードの種類と最大 QPS については、 TiProxy パフォーマンス テスト レポート参照してください。
    • TiProxy インスタンスの数は TiDB サーバの数よりも少ないため、TiProxy のネットワーク帯域が TiDB サーバよりもボトルネックになりやすいです。そのため、ネットワーク帯域も考慮する必要があります。例えば、AWS では、EC2 同シリーズのベースラインネットワーク帯域は CPU コア数に比例しません。詳細はネットワークパフォーマンス参照してください。このような場合、ネットワーク帯域がボトルネックになるときは、TiProxy インスタンスをより多くの小さなインスタンスに分割すると QPS が向上することがあります。

    TiDB クラスタをtiup cluster upgradeにアップグレードするときに TiProxy がアップグレードされないように、トポロジ構成で TiProxy のバージョン番号を指定することをお勧めします。そうしないと、TiProxy のアップグレード中にクライアント接続が切断される可能性があります。

    TiProxy 構成項目を構成するには、 TiProxy の設定参照してください。

    設定例は次のとおりです。

    component_versions:
  tiproxy: "v1.0.0"
server_configs:
  tiproxy:
    security.server-tls.ca: "/var/ssl/ca.pem"
    security.server-tls.cert: "/var/ssl/cert.pem"
    security.server-tls.key: "/var/ssl/key.pem"

  4. クラスターを起動します。

    TiUP を使用してクラスターを起動するには、 TiUPドキュメント参照してください。

  5. TiProxyに接続します。

    クラスターがデプロイされると、クラスターは TiDBサーバーと 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クラスタを再起動します

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超えています。
  • セッションはカーソルを使用してデータを読み取りますが、カーソルが閉じられていないか、TiDBサーバーで構成されたgraceful-wait-before-shutdown以内にデータが読み取られません。
  • セッションはローカル一時テーブル作成します。
  • セッションはユーザーレベルロックです。
  • セッションはテーブルロックです。
  • セッションはプリペアドステートメントを作成し、プリペアドステートメントは無効です。たとえば、準備されたプリペアドステートメントが作成された後に、プリペアドステートメントに関連するテーブルが削除されます。
  • セッションはセッション レベル実行プランバインディングを作成しますが、バインディングは無効です。たとえば、バインディングの作成後に、バインディングに関連するテーブルが削除されます。
  • セッションが作成された後、セッションで使用されたユーザーが削除されるか、ユーザー名が変更されます。

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

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

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

言語コネクタサポートされる最小バージョン
JavaMySQL コネクタ/J5.1.19
Ｃlibmysqlクライアント5.5.7
行くGo SQLDriver1.4.0
JavaScriptMySQL コネクタ/Node.js1.0.2
JavaScriptmysqljs/mysql2.15.0
JavaScriptノード-mysql21.0.0-rc-6
PHP のmysqlnd5.4
パイソンMySQL コネクタ/Python1.0.7
パイソンpyMySQL の0.7

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

TiProxy リソース

このページは役に立ちましたか？