ProxySQLはMySQL専用のロードバランサーであり、クエリリダイレクト、クエリキャッシング、トラフィックシェーピングなど、さまざまな機能が備わっています。これを使用して、読み取り/書き込み分割を簡単に設定し、クエリを個別のバックエンドノードにリダイレクトできます。結果として、それは使用する多くの説得力のある理由を提供します。一方、HAProxyは優れたロードバランサーですが、データベース専用ではなく、使用することはできますが、ProxySQLと機能的に比較することはできません。これが、HAProxyに依存してProxySQLへの移行を試みる環境の理由である可能性があります。
この短いブログ投稿では、移行プロセスに関するいくつかの提案を共有します。
これは非常に明白であり、問題なく進むはずですが、それでも書面で提出したいと思います。アップグレードを計画します。プロセスに精通していること、すべてを広範囲にテストしたことを確認してください。アップグレードへのさまざまなアプローチを検証し、どれが最適かを判断できるテスト環境をセットアップします。
ProxySQLの使用を検討している場合は、ProxySQLで読み取り/書き込み分割をテストします
要件によっては、ProxySQLで読み取り/書き込み分割の使用を検討することをお勧めします。これは、おそらく、アップグレードの最も説得力のある理由の1つです。アプリケーション側で実装する（またはアプリケーションで実行できない場合はまったく実装しない）代わりに、ProxySQLを使用して読み取り/書き込み分割を実行できます。特にClusterControlを使用してProxySQLをデプロイする場合、セットアップは非常に簡単です。これはほぼ自動的に行われます。
暗黙的なトランザクションを使用しない限り、ClusterControlは一連のクエリルールを使用した読み取り/書き込み分割：
読み取り/書き込み分割の実装は非常に簡単ですが、次のことを行う必要があります。そうすることを計画するときは注意を払ってください。アプリケーションは、ProxySQLの箱から出してすぐには機能しない一部の機能に依存している場合があります。ほとんどの場合、追加の構成でこの機能を利用できますが、テストフェーズでは、アプリが正常に機能するかどうか、またはカスタム構成を追加する必要があるかどうかを確認することが非常に重要です。特にトリッキーな部分は、書き込み後の読み取りの問題です。その場合、一部のクエリの接続多重化を無効にするためにProxySQLを再構成する必要がある場合があります。
これは、ProxySQLの新規ユーザーにとって驚きとなることの1つです。実際には構成ファイルを使用しません。はい、1つありますが、最初の起動時にProxySQLをブートストラップする方法として機能します。 ProxySQLは、その構成を含むSQLiteデータベースを使用し、構成を変更する適切な方法は、ProxySQLの管理ポートに接続されたMySQLクライアントを使用することです。そこから、ProxySQLを再起動することなく、実行時に構成を変更できます。
もちろん、ClusterControl UIでは、ProxySQLを再構成することもできます。
ProxySQLデプロイメントパターン
ProxySQLをデプロイする主な方法は2つあります。専用サーバーを使用してProxySQLを次の場所にデプロイできます：
または、ProxySQLをアプリケーションサーバーと併置できます：
これにより、アプリケーションはUnixソケットを使用してローカルProxySQLインスタンスに接続できます。リモートTCP接続を使用するよりもパフォーマンスの面で優れています。また、セットアップが簡素化されます。ProxySQLインスタンス間で負荷分散するために、Keepalivedやその他の仮想IPプロバイダーを実装する必要はありません。アプリケーションはローカルのProxySQLにのみ接続し、それでほぼ完了です。
ProxySQLインスタンスに常に同じ構成が含まれていることを確認することは、特にその数が多い場合は難しい場合があります。このような課題に対処するには、Ansible / Chef / Puppet、シェルスクリプトなど、さまざまな方法があります。組み込みのソリューションであるProxySQLClusterに依存することをお勧めします。わずか2、3の構成変更で、ProxySQLノードを構成してクラスターを形成し、ノードの1つでの構成変更がクラスターのすべてのメンバーに伝播されるようにすることができます。
より難しい部分の1つは、アプリケーションへの影響を最小限に抑える方法で、トラフィックをHAProxyからProxySQLに確実に切り替えることです。通常、少なくとも1つの設定（アプリケーションが接続するホスト名またはポート）を変更する必要があります。環境によっては、特にデータベース接続構成がアプリケーションに組み込まれている場合、これは理想的ではない場合があります。ほとんどの場合、コードベースを変更し、新しいコードを本番環境にプッシュする必要があります。最大の取引ではありませんが、それよりもうまくいくことができます。
興味深いのは、ProxySQLと最近のバージョンのHAProxy（1.8以降）の両方がSO_REUSEPORTを利用できることです。このソケットオプションは、3.9カーネル以降のLinuxで使用可能であり、複数のプロセスが同じポートを共有できるようにします。 ProxySQLはProxySQLバージョン間の正常なアップグレードに使用でき、HAProxyはアプリケーションに影響を与えることなく構成をリロードするために使用します。興味深いことに、これら2つのロードバランサー間でシームレスに移行するために、HAProxyとポートを共有するようにProxySQLを構成することができます。
これを実行する際に考慮しなければならないことがいくつかあります。まず、ProxySQLはデフォルトでこのオプションを使用しません。起動時に、ProxySQLに-rフラグを追加する必要があります。これを行うには、ProxySQLsystemdユニットファイルを編集します。
[email protected]:~# systemctl edit proxysql --fullExecStart=/usr/bin/proxysql -c /etc/proxysql.cnf -rLinuxで注意する必要があるもう1つの制限は、同じユーザーIDで開始されたプロセスのみがポートを共有できることです。これは、「haproxy」ユーザーとして実行されるようにProxySQLを再構成する必要があることを意味します。
通常どおり、実稼働環境でこの操作を実行する前に、テストを実行することをお勧めします。この偉業を達成することは間違いなく可能ですが、環境に関連するある種の非標準構成のために、注意を払い、本番環境に影響を与えないことを再確認する必要があります。
この短いブログで、HAProxyからProxySQLへの移行プロセスについての洞察が得られることを願っています。データベースバックエンドの場合、準備部分に時間がかかる場合でも、この変更は非常に有益です。適切なテストを経れば、最終的な移行はかなり簡単で安全なはずです。