ブログシリーズの過去5回の投稿では、クラスタリング/レプリケーション（MySQL / Galera、MySQL Replication、MongoDB＆PostgreSQL）の展開、既存のデータベースとクラスターの管理と監視、パフォーマンスの監視と正常性、セットアップの方法について説明しました。 HAProxyとMaxScaleを介して非常に利用可能であり、前回の投稿では、バックアップをスケジュールして災害に備える方法を説明しました。
ClusterControl 1.2.11以降、データベース構成マネージャーに大幅な機能拡張が行われました。新しいバージョンでは、複数のデータベースホストのパラメータを同時に変更でき、可能であれば、実行時にそれらの値を変更できます。
ヒントとコツのブログ投稿で新しいMySQL構成管理を取り上げましたが、このブログ投稿では、MySQL、PostgreSQL、MongoDBのClusterControl内の構成管理についてさらに詳しく説明します。
ClusterControl構成管理
構成管理インターフェースは、「管理」>「構成」の下にあります。ここから、ClusterControlが管理するデータベースノードおよびその他のツールの構成を表示または変更できます。 ClusterControlは、すべてのノードから最新の構成をインポートし、以前に作成されたコピーを上書きします。現在、履歴データは保持されていません。
ノード上で構成ファイルを直接手動で編集する場合は、[インポート]ボタンを押して変更した構成を再インポートできます。
最後になりましたが、構成テンプレートを作成または編集できます。これらのテンプレートは、クラスターに新しいノードをデプロイするたびに使用されます。もちろん、テンプレートに加えられた変更は、これらのテンプレートを使用して作成された、すでにデプロイされているノードにさかのぼって適用されることはありません。
MySQL構成管理
前述のように、MySQL構成管理はClusterControl1.2.11で完全に見直されました。インターフェイスがより直感的になりました。パラメータを変更すると、ClusterControlはパラメータが実際に存在するかどうかを確認します。これにより、パラメータが存在しないために設定がMySQLの起動を拒否しないことが保証されます。
[管理]->[構成]から、ロードバランサーノードを含む、選択したクラスター内で使用されるすべての構成ファイルの概要を確認できます。
ツリー構造を使用して、ホストとそれぞれの構成ファイルを簡単に表示します。ツリーの下部に、このクラスターで使用可能な構成テンプレートがあります。
パラメータの変更
許可される接続の最大数（max_connections）などの単純なパラメーターを変更する必要がある場合、実行時にこのパラメーターを変更するだけで済みます。
まず、この変更を適用するホストを選択します。
次に、変更するセクションを選択します。ほとんどの場合、MYSQLDセクションを変更する必要があります。 MySQLのデフォルトの文字セットを変更する場合は、MYSQLDセクションとクライアントセクションの両方で変更する必要があります。
必要に応じて、新しいセクション名を入力するだけで新しいセクションを作成することもできます。これにより、my.cnfに新しいセクションが作成されます。
パラメータを変更し、「続行」を押して新しい値を設定すると、ClusterControlはこのバージョンのMySQLにパラメータが存在するかどうかを確認します。これは、存在しないパラメータが次回の再起動時にMySQLの初期化をブロックするのを防ぐためです。
max_connectionsの変更のために「proceed」を押すと、それが構成に適用され、SETGLOBALを使用して実行時に設定されたという確認を受け取ります。 max_connectionsは実行時に変更できるパラメーターであるため、再起動は必要ありません。
ここで、バッファプールのサイズを変更したいとします。これを有効にするには、MySQLを再起動する必要があります。
予想どおり、構成ファイルで値が変更されましたが、再起動が必要です。これを行うには、ホストに手動でログインし、MySQLプロセスを再起動します。 ClusterControlからこれを行う別の方法は、ノードダッシュボードを使用することです。
Galeraクラスターでのノードの再起動
「ノードの再起動」を選択して「続行」ボタンを押すと、ノードごとに再起動を実行できます。
Galeraノードで「初期開始」を選択すると、ClusterControlはMySQLデータディレクトリを空にし、この方法で完全コピーを強制します。これは、明らかに、構成の変更には不要です。確認ダイアログで「初期」チェックボックスをオフのままにしてください。これにより、ホスト上でMySQLが停止および開始されますが、ワークロードとバッファープールのサイズによっては、MySQLがダーティページをInnoDBバッファープールからディスクにフラッシュし始めるため、これにはしばらく時間がかかる場合があります。これらは、メモリでは変更されているがディスクでは変更されていないページです。
MySQLマスタースレーブトポロジでのノードの再起動
MySQLマスタースレーブトポロジの場合、ノードごとに再起動することはできません。マスターのダウンタイムが許容できる場合を除いて、最初に構成の変更をスレーブに適用してから、スレーブを新しいマスターに昇格させる必要があります。
スレーブを1つずつ確認し、スレーブで「ノードの再起動」を実行できます。
すべてのスレーブに変更を適用した後、スレーブを新しいマスターになるように昇格させます。
スレーブが新しいマスターになった後、古いマスターノードをシャットダウンして再起動し、変更を適用できます。
構成のインポート
構成ファイルだけでなくデータベースにも直接変更を適用したので、次の構成のインポートまでに、ClusterControlに格納されている構成に変更が反映されていることを確認します。辛抱強くない場合は、[インポート]ボタンを押してすぐに構成のインポートをスケジュールできます。
PostgreSQL構成管理
PostgreSQLの場合、構成管理はMySQL構成管理とは少し異なります。一般に、ここには同じ機能があります。構成の変更、すべてのノードの構成のインポート、およびテンプレートの定義/変更です。
ここでの違いは、構成ファイル全体をすぐに変更して、この構成をデータベースノードに書き戻すことができることです。
行った変更で再起動が必要な場合は、「再起動」ボタンが表示され、ノードを再起動して変更を適用できます。
MongoDB構成管理
MongoDB構成管理は、MySQL構成管理と同様に機能します。構成の変更、すべてのノードの構成のインポート、パラメーターの変更、テンプレートの変更を行うことができます。
[パラメータの変更]ダイアログを使用すると、構成の変更は非常に簡単です（「パラメータの変更」セクションで説明されています::
変更すると、「ConfigChangeLog」ダイアログでClusterControlによって提案された変更後のアクションを確認できます。
次に、それぞれのMongoDBノードを一度に1ノードずつ再起動して、変更をロードできます。
最終的な考え
このブログ投稿では、ClusterControlで構成を管理、変更、およびテンプレート化する方法について学習しました。テンプレートを変更すると、トポロジにノードを1つだけデプロイした場合に、時間を大幅に節約できます。テンプレートは新しいノードに使用されるため、後ですべての構成を変更する必要がなくなります。ただし、MySQLおよびMongoDBベースのノードの場合、新しい構成管理インターフェイスにより、すべてのノードの構成を変更するのは簡単になりました。
念のため、最近、クラスタリング/レプリケーション（MySQL / Galera、MySQL Replication、MongoDB＆PostgreSQL）の同じシリーズ展開、既存のデータベースとクラスターの管理と監視、パフォーマンスの監視と正常性、セットアップを高度に行う方法について説明しました。 HAProxyとMaxScaleを介して利用可能であり、前回の投稿では、バックアップをスケジュールして災害に備える方法を説明しています。