シリーズの最初のパートでは、WHMとcPanelを使用してProxySQLを使用してMySQLレプリケーションセットアップをデプロイする方法を示しました。このパートでは、メンテナンス、管理、フェイルオーバーの展開後の操作と、スタンドアロンセットアップに対する利点をいくつか紹介します。
MySQLユーザー管理
この統合を有効にすると、MySQLユーザー管理はWHMまたはcPanelから実行する必要があります。そうしないと、ProxySQLmysql_usersテーブルがレプリケーションマスター用に構成されているものと同期しません。すでにseveren_user1というユーザーを作成し（MySQLの制限に準拠するためにMySQLのユーザー名の前にcPanelが自動的に付けられます）、以下のようにデータベースにいくつかのn_db1を割り当てたいとします。
上記の結果、ProxySQLで次のmysql_usersテーブルが出力されます。
cPanelの外部でMySQLリソースを作成する場合は、ClusterControl->管理->スキーマとユーザーを使用できます。 機能を選択し、 ClusterControl->ノード->ProxySQLノードを選択->ユーザー->ユーザーのインポートに移動して、データベースユーザーをProxySQLにインポートします。 。
ProxySQLユーザーの同期に使用するProxysqlhookモジュールは、デバッグログを/ usr / local / cpanel / logs/error_logに送信します。このファイルを使用して、舞台裏で何が起こっているかを調べて理解します。 Softaculousを使用してZikulaというWebアプリケーションをインストールした場合、cPanelログファイルに次の行が表示されます。
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL database severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [mysql] Creating MySQL virtual user severaln_ziku703 for user severalnines
[2019-07-08 11:53:41 +0800] info [cpanel] **** Reading ProxySQL information: Host: 192.168.0.16, Port: 6032, User: proxysql-admin *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Inserting severaln_ziku703 into ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Checking if severaln_ziku703 exists inside ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Updating severaln_ziku703 default schema in ProxySQL mysql_users table *****
[2019-07-08 11:53:41 +0800] info [cpanel] **** Save and load user into ProxySQL runtime *****WHMはデータベースユーザーの作成要求ごとに複数のMySQLユーザー/ホストを作成するため、「{DBユーザー}が存在するかどうかを確認する」のような行が繰り返されます。この例では、WHMは次の3人のユーザーを作成します。
ProxySQLは、ユーザーを追加するときに、ユーザー名、パスワード、およびデフォルトのホストグループ情報のみを必要とします。したがって、チェック行は、まったく同じユーザーの複数の挿入を回避するためにあります。
モジュールを変更して改善を加える場合は、WHMサーバーで次のコマンドを実行してモジュールを再登録することを忘れないでください。
(whm)$ /usr/local/cpanel/bin/manage_hooks add module ProxysqlHookクエリの監視とキャッシュ
ProxySQLを使用すると、アプリケーションから渡された、またはアプリケーションを通過しているすべてのクエリを監視できます。標準のWHMは、MySQLクエリ監視でこのレベルの詳細を提供しません。次に、ProxySQLによってキャプチャされたすべてのMySQLクエリを示します。
ClusterControlを使用すると、最も繰り返されるクエリを簡単に検索し、ProxySQLクエリキャッシュ機能を介してそれらをキャッシュできます。 [並べ替え]ドロップダウンを使用して、クエリを[スター数]で並べ替え、キャッシュするクエリにロールオーバーして、その下にある[クエリのキャッシュ]ボタンをクリックします。次のダイアログが表示されます：
キャッシュされたクエリの結果セットは、ProxySQL自体によって保存および提供され、MySQLレプリケーションクラスター全体の負荷を軽減するバックエンドへのヒット数を減らします。 ProxySQLクエリキャッシュの実装は、MySQLクエリキャッシュとは根本的に異なります。これは時間ベースのキャッシュであり、「キャッシュTTL」と呼ばれるタイムアウト後に期限切れになります。この構成では、宛先ホストグループが20であるリーダーグループにヒットしてから5秒間（5000ミリ秒）上記のクエリをキャッシュします。
読み取り/書き込みの分割とバランシング
MySQLのデフォルトポート3306をリッスンすることにより、ProxySQLはMySQLサーバー自体のように機能します。フロントエンドとバックエンドの両方でMySQLプロトコルを話します。 ProxySQLの設定時にClusterControlによって定義されたクエリルールは、すべての読み取り（Regex言語では^ SELECT。*）をリーダーグループであるホストグループ20に自動的に分割し、残りはライターホストグループ10に転送されます。次のクエリルールセクション：
このアーキテクチャでは、ProxySQLが自動的に機能するため、読み取り/書き込みクエリの分割について心配する必要はありません。ユーザーはコードに最小限の変更を加えるだけで済み、ホスティングユーザーは、スタンドアロンのMySQLセットアップに接続するのと同じように、WHMとcPanelによって提供されるすべてのアプリケーションと機能をネイティブに使用できます。
接続バランシングに関して、特定のホストグループ（この例ではリーダーホストグループ20など）に複数のアクティブノードがある場合、ProxySQLは、重み、レプリケーションラグ、使用される接続などのいくつかの基準に基づいて、それらの間で負荷を自動的に分散します、全体的な負荷と遅延。 ProxySQLは、高度な接続プールメカニズムを実装することにより、同時実行性の高い環境で非常に優れていることが知られています。 ProxySQLのブログ投稿から引用されているように、ProxySQLは持続的接続だけでなく、接続の多重化も実装しています。実際、ProxySQLは数十万のクライアントを処理できますが、すべてのトラフィックをバックエンドへの少数の接続に転送します。したがって、ProxySQLはN個のクライアント接続とM個のバックエンド接続を処理できます。ここでN> M（MのN千倍も大きい）です。
MySQLフェイルオーバーとリカバリ
ClusterControlがレプリケーションクラスターを管理している場合、自動リカバリが有効になっていると、フェールオーバーが自動的に実行されます。マスターに障害が発生した場合：
- ClusterControlは、MySQLクライアント、SSH、およびpingを介してマスターの障害を検出および検証します。
- ClusterControlは、フェイルオーバー手順を開始する前に3秒間待機します。
- ClusterControlは、最新のスレーブを次のマスターに昇格させます。
- 古いマスターがオンラインに戻ると、アクティブなレプリケーションに参加せずに、読み取り専用として開始されます。
- 古いマスターに何が起こるかを決めるのはユーザー次第です。 ClusterControlの「RebuildReplicationSlave」機能を使用して、レプリケーションチェーンに戻すことができます。
- ClusterControlは、マスターフェイルオーバーの実行を1回だけ試行します。失敗した場合は、ユーザーの介入が必要です。
ClusterControl-> Activity-> Jobs-> Failover to a new master で、フェイルオーバープロセス全体を監視できます。 以下に示すように：
フェイルオーバー中、データベースサーバーへのすべての接続はProxySQLでキューに入れられます。 mysql-default_query_timeout によって制御され、タイムアウトするまで終了しません。 86400000ミリ秒または24時間の変数。この時点では、アプリケーションでデータベースのエラーや障害が発生することはほとんどありませんが、トレードオフとして、構成可能なしきい値内での遅延の増加があります。
この時点で、ClusterControlはトポロジを次のように表示します。
古いマスターが起動して使用可能になった後でレプリケーションに再び参加できるようにする場合は、 ClusterControl->ノード->古いマスターを選択->レプリケーションの再構築に移動して、スレーブとして再構築する必要があります。スレーブ->新しいマスターを選択->続行 。再構築が完了すると、次のトポロジが得られるはずです（192.168.0.32がマスターになっていることに注意してください）：
サーバーの統合とデータベースのスケーリング
このアーキテクチャを使用すると、すべてのWHMサーバーに存在する多くのMySQLサーバーを単一のレプリケーションセットアップに統合できます。成長に合わせてより多くのデータベースノードを拡張することも、複数のレプリケーションクラスタを使用してそれらすべてをサポートし、単一のClusterControlサーバーで管理することもできます。次のアーキテクチャ図は、ProxySQLソケットファイルを介して2つのWHMサーバーが1つのMySQLレプリケーションクラスターに接続されているかどうかを示しています。
上記により、ホスティングシステムの2つの最も重要な層であるアプリケーション（フロントエンド）とデータベース（バックエンド）を分離することができます。ご存知かもしれませんが、MySQLをWHMサーバーに同じ場所に配置すると、通常、リソースが枯渇します。これは、MySQLを起動して正常に実行するには、大量の先行RAM割り当てが必要になるためです（主に innodb_buffer_pool_size によって異なります）。 変数）。ディスク容量が十分であることを考慮すると、上記の設定では、サーバーごとにホストされるホスティングアカウントを増やすことができ、すべてのサーバーリソースをフロントエンド層アプリケーションで利用できます。
MySQLレプリケーションクラスターのスケールアップは、個別の層アーキテクチャを使用するとはるかに簡単になります。マスターがスケールアップ（RAM、ハードディスク、RAID、NICのアップグレード）のメンテナンスを必要とする場合、マスターの役割を別のスレーブに切り替えることができます（ClusterControl->ノード->スレーブの選択->スレーブのプロモート ）次に、MySQLサービス全体に影響を与えることなくメンテナンスタスクを実行します。スケールアウト操作（スレーブの追加）の場合、アクティブなスレーブから直接ステージングを実行することにより、マスターに影響を与えることなくそれを実行できます。 ClusterControlを使用すると、既存のMySQLバックアップから新しいスレーブをステージングすることもできます（PITR互換のみ）：
バックアップからスレーブを再構築しても、マスターに追加の負担はかかりません。 ClusterControlは、選択したバックアップファイルをClusterControlサーバーからターゲットノードにコピーし、そこで復元を実行します。完了すると、ノードはマスターに接続し、復元時以降に欠落しているすべてのトランザクションの取得を開始し、マスターに追いつきます。遅れている場合、ProxySQLは、レプリケーションの遅れが10秒未満になるまで負荷分散セットにノードを含めません（ProxySQL管理インターフェースを介してmysql_serversテーブルを追加するときに構成可能）。
最終的な考え
ProxySQLは、MySQLレプリケーションの管理におけるWHMcPanelの機能を拡張します。 ClusterControlがレプリケーションクラスターを管理することで、レプリケーションクラスターの管理に関連するすべての複雑なタスクがこれまでになく簡単になりました。