DBAの大多数は、データベースのヘルスチェックを時々実行します。通常、それは毎日または毎週発生します。このようなチェックが重要である理由と、それらに何を含める必要があるかについては、前に説明しました。
システムが良好な状態であることを確認するには、ホスト統計、MySQL統計、ワークロード統計、バックアップの状態、データベースパッケージ、ログなど、非常に多くの情報を調べる必要があります。このようなデータは、適切に監視されているすべての環境で利用できる必要がありますが、複数の場所に散在している場合もあります-MySQLの状態を監視するためのツール、システム統計を収集するための別のツール、たとえば、あなたのバックアップ。これにより、ヘルスチェックに必要以上に時間がかかります。DBAは、システムの状態を理解するためにさまざまな要素をまとめる必要があります。
ClusterControlのような統合ツールには、すべてのビットが同じ場所（または同じアプリケーション）に配置されるという利点があります。それでも、それらが隣り合って配置されていることを意味するわけではありません。UIのさまざまなセクションに配置されている可能性があり、DBAはUIをクリックして、すべての興味深いデータに到達するために時間を費やす必要があります。
運用レポートの作成の背後にある全体的な考え方は、最も重要なデータをすべて1つのドキュメントにまとめることです。このドキュメントをすばやく確認して、データベースの状態を理解することができます。
運用レポートは、メニューの[サイドメニュー]-> [運用レポート]から利用できます：
そこに行くと、事前定義されたスケジュールに基づいて、手動または自動で作成されたレポートのリストが表示されます。
新しいレポートを手動で作成する場合は、[作成]オプションを使用します。レポートの種類、クラスター名（クラスターごとのレポートの場合）、電子メールの受信者（オプション-レポートを配信する場合）を選択すると、ほぼ完了です。
レポートは定期的に作成するようにスケジュールすることもできます：
現在、5種類のレポートをご利用いただけます：
- 可用性レポート-すべてのクラスター。
- バックアップレポート-すべてのクラスター。
- スキーマ変更レポート-MySQL/MariaDBベースのクラスターのみ。
- 毎日のシステムレポート-クラスターごと。
- パッケージアップグレードレポート-クラスターごと。
可用性レポート
可用性レポートは、まあ、可用性に焦点を当てています。 3つのセクションがあります。まず、可用性の概要：
データベースの可用性統計、クラスタータイプ、合計稼働時間とダウンタイム、クラスターの現在の状態、およびその状態が最後に変更された日時に関する情報を確認できます。
別のセクションでは、すべてのクラスターの可用性について詳しく説明します。以下のスクリーンショットは、データベースクラスターの1つのみを示しています。
ノードがいつ状態を切り替え、どのように遷移したかを確認できます。クラスタに最近問題があったかどうかを確認するのに最適な場所です。同様のデータがこのレポートの3番目のセクションに表示され、クラスターの状態の変化の履歴を確認できます。
バックアップレポート
2番目のタイプのレポートは、すべてのクラスターのバックアップをカバーするものです。バックアップの概要とバックアップの詳細の2つのセクションがあり、前者は基本的に、最後のバックアップが作成された日時、正常に完了したか失敗したか、バックアップの検証ステータス、成功率、保持期間の簡単な概要を示します。
ClusterControlは、スケジュールされたバックアップまたは遅延スレーブが構成されていない状態で実行されている監視対象データベースクラスターのいずれかを検出した場合のバックアップポリシーの例も提供します。次に、バックアップの詳細を示します。
また、クラスターで実行されたバックアップのリストを、指定された間隔内の状態、タイプ、およびサイズとともに確認することもできます。これは、完全復旧テストを実行しなくてもバックアップが正しく機能することを確認できる限り近いものです。このようなテストを時々実行することを強くお勧めします。朗報は、ClusterControlがスタンドアロンホストの[バックアップ]->[バックアップの復元]でMySQLベースの復元と検証をサポートしていることです。
日次システムレポート
このタイプのレポートには、特定のクラスターに関する詳細情報が含まれています。まず、クラスターに関連するさまざまなアラートの概要から始めます。
次のセクションでは、クラスターの一部であるノードの状態について説明します。
クラスタ内のノード、それらのタイプ、役割（マスターまたはスレーブ）、ノードのステータス、稼働時間、およびOSのリストがあります。
レポートの別のセクションは、上記で説明したのと同じバックアップの概要です。次に、クラスター内の上位のクエリの概要を示します。
最後に、「ノードステータスの概要」が表示されます。この概要には、各ノードのOSおよびMySQLメトリックに関連するグラフが表示されます。
ご覧のとおり、ここには、ホストの負荷のすべての側面（CPU、メモリ、ネットワーク、ディスク、CPU負荷、ディスクフリー）をカバーするグラフがあります。これは、最近何か奇妙なことが起こったかどうかを知るのに十分です。また、MySQLワークロードに関する詳細（実行されたクエリの数、クエリのタイプ、データへのアクセス方法（どのハンドラーを介して））も確認できます。一方、これはMySQL側の問題のほとんどを選択するのに十分なはずです。見たいのは、過去に見たことのないすべてのスパイクとディップです。おそらく、新しいクエリがミックスに追加され、その結果、 handler_read_rnd_next 急上昇？おそらく、CPU負荷が増加し、接続数が多いと、MySQLの負荷が増加したことを示している可能性がありますが、ある種の競合も示している可能性があります。予期しないパターンを調査するのが良いかもしれないので、何が起こっているのかがわかります。
パッケージアップグレードレポート
このレポートは、監視対象ホストのリポジトリマネージャーがアップグレードできるパッケージの概要を示します。正確なレポートを作成するには、すべてのホストで常に安定した信頼できるリポジトリを使用するようにしてください。いくつかの望ましくない場合、監視対象のホストは、アップグレード後に古いリポジトリ（たとえば、すべてのMariaDBメジャーバージョンが異なるリポジトリを使用する）、不完全な内部リポジトリ（たとえば、アップストリームから部分的にミラーリングされる）、または最先端のリポジトリ（通常は不安定な場合）で構成される可能性がありますナイトリービルドパッケージ）。
最初のセクションはアップグレードの概要です：
アップグレードに使用できるパッケージの総数と、ロードバランサー、仮想IPアドレス、アービトレーターなどのクラスターに関連するマネージドサービスをまとめたものです。次に、ClusterControlは、すべてのホストのパッケージタイプごとにグループ化された詳細なパッケージリストを提供します。
このレポートは利用可能なバージョンを提供し、メンテナンスウィンドウを効率的に計画するのに大いに役立ちます。セキュリティやデータベースパッケージなどの重要なアップグレードの場合、重要でないアップグレードよりも優先することができます。これは、他の優先度の低いメンテナンスウィンドウと統合できます。
スキーマ変更レポート
このレポートは、生成された2つの異なるレポート間で発生したテーブル構造の選択されたMySQL/MariaDBデータベースの変更を比較します。 MySQL / MariaDBの古いバージョンでは、DDL操作は非アトミック操作（8.0より前）であり、完全なテーブルコピー（ほとんどの操作では5.6より前）が必要です-完了するまで他のトランザクションをブロックします。テーブルが大量のデータを取得すると、スキーマの変更は非常に困難になる可能性があり、特にクラスター化されたセットアップでは慎重に計画する必要があります。多層開発環境では、開発者がテーブル構造をサイレントに変更し、クエリのパフォーマンスに大きな影響を与えるケースが数多く見られます。
ClusterControlが正確なレポートを生成するには、それぞれのクラスターのCMON構成ファイル内に特別なオプションを構成する必要があります。
- schema_change_detection_address -SHOW TABLES / SHOW CREATE TABLEを使用してチェックが実行され、スキーマが変更されたかどうかが判別されます。チェックは指定されたアドレスで実行され、形式はHOSTNAME：PORTです。 schema_change_detection_databases また、設定する必要があります。変更されたテーブルの差分が作成されます（差分を使用）。
- schema_change_detection_databases -スキーマの変更を監視するためのデータベースのコンマ区切りリスト。空の場合、チェックは行われません。
この例では、クラスターID27のMariaDBクラスター上のデータベース「myapp」と「sbtest」のスキーマ変更を監視します。データベースノードの1つをschema_change_detection_addressの値として選択します。 。 MySQLレプリケーションの場合、これはマスターホスト、またはデータベースを保持する任意のスレーブホストである必要があります（部分レプリケーションがアクティブな場合）。次に、/ etc / cmon.d / cmon_27.cnf内に、次の2行を追加します。
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestCMONサービスを再起動して、変更をロードします：
$ systemctl restart cmon最初の最も重要なレポートの場合、ClusterControlは、以下のように、メタデータ収集の結果のみを返します。
最初のレポートをベースラインとして、後続のレポートは期待する出力を返します。
レポートには、新しいテーブルまたは変更されたテーブルのみが出力されることに注意してください。最初のレポートは、後続のラウンドで比較するためのメタデータ収集専用であるため、違いを確認するには、少なくとも2回実行する必要があります。
このレポートを使用すると、データベース構造のフットプリントを収集し、データベースが時間の経過とともにどのように進化したかを理解できます。
最終的な考え
運用レポートは、データベースインフラストラクチャの状態を理解するための包括的な方法です。運用スタッフまたは管理スタッフの両方向けに構築されており、データベース操作の分析に非常に役立ちます。レポートはインプレースで生成することも、電子メールで配信することもできます。これにより、レポートサイロがある場合に便利になります。
レポートに含めたいその他の情報、不足しているもの、不要なものについてのフィードバックをお待ちしています。