ClusterControlとそのコンポーネントのパフォーマンスを最適化する方法

バッファプールサイズは重要なコンポーネントであり、MySQLのパフォーマンスを向上させるために事前に構成する必要があります。これにより、MySQLの処理を、ディスクにアクセスする代わりにメモリ内で実行できます。簡単な経験則は、InnoDBのヒット率を確認し、BUFFER POOLANDMEMORYセクションで次の行を探すことです。

Buffer pool hit rate 986 / 1000

986/1000のヒット率は、1000行の読み取りのうち、RAM内の行を986回読み取ることができたことを示しています。残りの14回は、ディスクからデータの行を読み取る必要がありました。簡単に言うと、1000/1000は、ここで達成しようとしている最高の値です。つまり、頻繁にアクセスされるデータはRAMに完全に収まります。

innodb_buffer_pool_sizeの値を増やすと、MySQLが作業できる余地を増やすのに大いに役立ちます。ただし、事前に十分なRAMリソースがあることを確認してください。デフォルトでは、ClusterControlはRAMの50％をバッファプールに割り当てます。ホストがClusterControl専用の場合、OSプロセスとキャッシュに少なくとも2GBのRAMを確保すれば、70％などのより高い値にプッシュすることもできます。それほど多くを割り当てることができない場合は、RAMを増やすことが唯一の解決策です。

この値を変更するには、MySQLの再起動（MySQL 5.7.5より古い）が必要です。したがって、正しいサービスの再起動の順序は次のようになります。

1. my.cnf内のinnodb_buffer_pool_size値を変更します。
2. CMONサービスを停止します。
3. MySQL/MariaDBサービスを再起動します。
4. CMONサービスを開始します。

または、ダウンタイムを長くする余裕がある場合は、単にホストを再起動します。

max_connectionsの調整

デフォルトでは、インストーラスクリプトは最大512のmax_connections値を設定します。MySQLサーバーが他のアプリケーションと共有されているか、ClusterControlによって数十のMySQLノードが監視されていない限り、ClusterControlは合計で200接続に達することはほとんどないため、これはかなり高いです。 （30ノード以上について話している）

max_connectionsの値が高いとリソースが浪費され、値を調整するとMySQL用に構成された最大メモリに影響します。システムRAMより大きい場合、すべての接続が使用されていると、MySQLサーバープロセスがOOM例外で終了する可能性があります。

これを確認するには、max_used_connectionsMySQLステータスを探すだけです。以下は、合計6つのMySQLノードを持つ2つのクラスターを監視するClusterControlノードでMySQLがこれまでに到達した最大接続数です。

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

開始するのに適した値はMax_used_connectionsx2であり、値が一貫して増加している場合は徐々に増やします。 max_connections変数の変更は、SETGLOBALステートメントを介して動的に行うことができます。

MySQLソケットファイルの使用

デフォルトでは、インストーラースクリプトは、すべてのClusterControlデータベース構成ファイル内で次のホスト値を自動的に構成します。

上記は、ClusterControlがMySQLサーバーと同じサーバーで実行されている場合でも、リモートのMySQLホストに接続するのと同じように、MySQLクライアントをTCPネットワーク経由で強制的に接続します。ほとんどすべてのOSプラットフォームがMySQLソケットファイルを異なる方法で事前構成するため、インストールプロセスを簡素化するために意図的にこのように構成しました。これにより、インストールの失敗率が大幅に低下します。

値を「localhost」に変更すると、クライアントは代わりにMySQL Unixソケットファイルを使用するように強制されます：

Unixベースのシステムでは、MySQLプログラムはホスト名localhostを特別に扱います。これは、他のネットワークベースのプログラムと比較して予想とは異なる可能性があります。ローカルホストへの接続の場合、MySQLプログラムはUnixソケットファイルを使用してローカルサーバーに接続しようとします。これは、ポート番号を指定するために--portまたは-Pオプションが指定されている場合でも発生します。

MySQL UNIXソケットファイルを使用すると、はるかに安全になり、ネットワークのオーバーヘッドが削減されます。 TCPよりも常に推奨されます。ただし、ソケットファイルが正しく構成されていることを確認する必要があります。これは、my.cnf内の次のディレクティブおよびClusterControlノード上のすべてのMySQLオプションファイルに存在する必要があります。例：

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

ソケットファイルを変更するには、MySQLとCMONを再起動する必要もあります。 「localhost」を使用している場合は、skip-networking =1などの構成オプションを追加して、リモート接続を受け入れないようにすることができます。 ClusterControl Dockerイメージは、このアプローチを使用して、ポートにバインドする際のdocker-proxyの制限を克服しています。

SSSDを使用したOpenSSH

ClusterControlは、リモートノードを管理および監視するための主要な通信チャネルとしてSSHプロトコルを使用します。デフォルトのOpenSSH構成はかなり適切であり、ほとんどの場合に機能するはずです。ただし、SSHがSElinuxやSystem Security Services Daemon（SSSD）などの他のセキュリティ強化ツールと統合されている一部の環境では、SSHのパフォーマンスに大きな影響を与える可能性があります。

各管理対象ノードに対して確立されるSSH接続の数が増え続け、最終的にはClusterControlサーバーとすべての管理対象ノードの両方がSSH接続でシステムメモリを使い果たしてしまうケースが数多く見られます。場合によっては、ClusterControlサーバーで毎晩通常のシステム全体を再起動するだけで問題を解決できます。

System Security Services Daemon（SSSD）を使用してインフラストラクチャを実行している場合は、ClusterControlノードの/ etc / ssh/ssh_configにあるOpenSSHクライアント構成内の次の行にコメントすることをお勧めします。

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

上記では、SSSDを使用してホストキーを管理することをスキップします。ホストキーは、代わりにOpenSSHクライアントによって処理されます。

ClusterControl 1.7.0以降、Prometheusでエージェントベースの監視ツールを使用するオプションがあります。エージェントベースの監視では、ClusterControlはSSHを使用して、一部の環境で過剰になる可能性のあるホストメトリックをサンプリングしません。

ファイルシステムとパーティショニング

ClusterControlコントローラーは、クラスターごとにほぼ毎秒、ログファイルに新しいエントリを書き込みます。このディスクへの順次書き込みを利用してコストを節約したい場合は、この目的でスピンドルディスクを使用できます。すべてのcmon_X.cnf内の次の行を変更します：

logfile=/new/partition/log/cmon_X.log

XをクラスターIDに置き換え、CMONサービスを再起動して変更を適用します。

ClusterControlをバックアップリポジトリとして使用している場合は、ルートパーティション以外の別のパーティションに十分なディスク領域を割り当てることをお勧めします。パーティションがネットワーク化されたファイルシステムまたはクラスター化されたファイルシステム上にあると、復元操作を実行するときにターゲットノードに簡単にマウントできるようになります。作成されたバックアップがメインパーティションのすべてのディスクスペースを使い果たし、最終的にClusterControlとそのコンポーネントに影響を与える場合があります。