PolarDBは、一時的なサービスの中断や接続の失敗を防ぐための永続的な接続機能をサポートしています。 これらの問題は、仕様のアップグレード、切り替え、マイナーバージョンのアップグレードなどのO&Mアクティビティによって発生する可能性があります。 この問題は、サーバーの誤動作などの異常も引き起こす可能性があります。 永続接続により、PolarDBの可用性が向上します。
前提条件
PolarDBクラスターのPolarProxyバージョンは2.4.7以降です。 現在のバージョンの表示とPolarProxyのアップグレード方法の詳細については、「マイナーバージョンのアップグレード」をご参照ください。
PolarDB for MySQLの5.6、5.7、または8.0とcluster Editionのクラスター。
デフォルトのクラスターエンドポイントまたはActive requestsベースの負荷分散ポリシーを使用するカスタムエンドポイントにアクセスするトラフィックのみが、永続的な接続をサポートします。
背景情報
PolarDBは、高可用性コンポーネントを使用してプライマリ /セカンダリのフェイルオーバーをサポートします。 これにより、クラスターの可用性が高くなります。 ただし、フェイルオーバーはサービスに悪影響を及ぼし、一時的なサービスの中断や接続障害などの問題を引き起こす可能性があります。 次のシナリオでは、アプリケーションがクラスターから一時的に切断される可能性があります。
切り替え: 切り替えは、仕様のアップグレード、自動フェールオーバーと手動フェールオーバー、マイナーバージョンのアップグレードなど、コンソールまたはバックエンドコントローラーで実行されるO&Mアクティビティによってトリガーされます。
フェールオーバー: フェールオーバーは、プライマリノードの障害やサーバーの誤動作などの異常によってトリガーされます。
ほとんどの場合、アプリケーションを再起動するか、自動再接続メカニズムでアプリケーションを構成して、これらの問題を解決できます。 ただし、開発ライフサイクルが短いため、開発の初期段階ではこれらの問題が考慮されない場合があります。 これは、多数の例外またはサービス中断につながる。 PolarDBは永続的な接続機能をサポートしており、仕様のアップグレード、切り替え、マイナーバージョンのアップグレード、サーバーの誤動作など、O&Mアクティビティや異常によって引き起こされる接続の問題を防ぎます。 永続接続により、PolarDBクラスターの可用性が向上します。
永続接続のしくみ
プライマリノードの切り替え
PolarDBクラスターの各セッションは、アプリケーションとPolarProxy間のフロントエンド接続と、PolarProxyとバックエンドデータベース間のバックエンド接続で構成されます。 永続接続機能が有効になった後、PolarProxyが現在のプライマリノードから切断され、新しいプライマリノードに接続されると、PolarProxyとアプリケーション間の接続 (アプリケーションに表示されるセッション) は存続します。 PolarProxyは、新しいプライマリノードへの接続を確立し、セッションを切り替えが実行される前の状態に復元します。 これにより、切り替え全体がアプリケーションに対して透過的になります。
通常、MySQLセッションには、システム変数、ユーザー変数、一時テーブル、文字セットエンコード、トランザクションステータス、およびPREPAREステートメントステータスという情報が含まれます。 このトピックでは、文字セットエンコーディングのステータスを例として使用して、永続的な接続が有効になる前後でセッションのステータスがどのように変化するかを示します。
アプリケーションとPolarProxyの間に接続が確立され、set names utf8; ステートメントが実行されます。 この場合、セッションはnames=utf8の状態になります。 PolarProxyが新しいプライマリノードに接続する場合、セッションのステータスは変更されません。 それ以外の場合、文字セットのエンコードエラーが発生します。 これらのエラーを防ぐには、切り替えが完了した後もセッションステータスを変更しない必要があります。
PolarProxyが新しいプライマリノードに接続すると、元のデータベースと新しいデータベースは、読み取り要求と書き込み要求の両方から一時的にアクセスできなくなります。 ダウンタイムはデータベースの負荷によって異なります。 データベースのダウンタイム中、PolarProxyは両方のデータベースへのリクエストのルーティングを停止します。 PolarProxyは、次の条件に基づいてリクエストの配布を再開します。
新しいプライマリノードが60秒以内に回復すると、PolarProxyはリクエストを新しいデータベースにルーティングします。
新しいプライマリノードが60秒以内に回復できない場合、PolarProxyはアプリケーションから切断されます。 アプリケーションはPolarProxyに再接続する必要があります。 この問題は、永続接続が無効になっている場合にも発生します。
読み取り専用ノードの削除
デフォルトのクラスターエンドポイントから読み取り専用ノードを削除するか、Active requests-based load balancingポリシーを使用するカスタムエンドポイントを削除できます。 削除する読み取り専用ノードでリクエストが実行されていて、プロキシが読み取り専用ノードの削除リクエストを受信してからこのリクエストの実行時間が60秒を超えた場合、このリクエストに対応する接続は切断されます。 接続を存続させることができないその他のシナリオは、使用状況ノートに記載されています。 プロキシが読み取り専用ノードの削除要求を受信すると、すべての新しい接続とアイドル状態の新しい要求はノードにルーティングされなくなります。
使用上の注意
次のシナリオの接続は存続できません。
PolarProxyが新しいプライマリノードに接続すると、セッション内に一時テーブルが存在します。
PolarProxyが新しいプライマリノードに接続すると、結果メッセージはデータベースからPolarProxyに配信されます。 しかしながら、PolarProxyは、メッセージの一部のみを受信している。 たとえば、SELECTステートメントを実行すると、サイズが100 MBの結果メッセージがPolarProxyに返されます。 ただし、切り替えがトリガーされると、PolarProxyは10 MBのメッセージしか受信しません。
PolarProxyが新しいプライマリノードに接続すると、
begin;insert into;などの進行中のトランザクションがセッション内に存在します。カーソルまたはstmt_send_long_dataメソッドが使用され、スイッチオーバーの開始時にリクエストが実行中です。
スイッチオーバーまたはノードの削除が開始されると、PolarProxyは接続がアイドルになるまで60秒待ちます。 接続が60秒以内にアイドル状態になると、PolarProxyは接続を維持します。 すべてのリクエストが返されるか、トランザクションが終了すると、接続がアイドルになります。 これは接続を存続させるのに役立ちます。
[接続ベースの負荷分散] ポリシーを使用するエンドポイントから読み取り専用ノードを削除すると、このノードのすべての接続が切断されます。 ノードが削除されると、読み取り専用ノードへの直接接続も切断されます。
パフォーマンスベンチマーク
環境
ベンチマークには次のクラスターが使用されます。
PolarDB for MySQL 8.0クラスター。 デフォルトでは、クラスターには1つのプライマリノードと2つの読み取り専用ノードが含まれます。
ノード仕様は4コア16 GBです。
(polar.mysql.x4.large) 。
テストツール: Sysbench。
テストデータ:
20のテーブルはテストで使用されます。 各テーブルは10,000行を含む。
並列度は20である。
手順
O&Mアクティビティの実行前と実行後にPolarDBクラスターで存続している接続の比率をテストします。
テスト結果
次のシナリオでは、PolarDBクラスターで存続している接続の比率が100% されます。
説明維持される接続の比率は、クラスター仕様を4コアから8コアなど、層ごとにアップグレードする場合にのみ100% されます。 クラスター仕様を4コアから16コア以上にアップグレードすると、サービスが中断する可能性があります。
読み取り専用ノードが削除されたときにデータベースプロキシノードがダウングレードされた場合、一部の接続が閉じられる可能性があります。
このセクションでは、データベースカーネルエンジンのマイナーバージョンのアップグレードのみをテストします。 このテストには、データベースプロキシのマイナーバージョンのアップグレードは含まれません。 データベースプロキシのマイナーバージョンのアップグレード中に、ネットワークの中断が発生する可能性があります。
シナリオ
生き続ける接続の比率
新しいプライマリノードへの切り替え
100%
データベースカーネルエンジンのマイナーバージョンのアップグレード
100%
クラスター仕様のアップグレード
100%
ノードの追加または削除
100%