MySQL MHA 操作ステータス監視の概要

1. プロジェクトの説明

1.1 背景

MHA (Master HA) は、 MySQLマスタースレーブレプリケーションアーキテクチャのautomating master failoverオープンソースの MySQL 高可用性プログラムです。 MHA はmasterノードの障害を検出すると、最新のデータを持つslaveノードを新しいmasterノードに昇格させます。自動FailOverの前提条件は、MHA が起動され、実行されていることです。実稼働環境では、 MySQLマスターノードが時間通りに起動しなかったり、気づかないうちに異常停止したりすることがあり、その結果、異常発生時に自動FailOver行われず、実稼働に影響したり、処理時間が長くなって障害が拡大したりすることがあります。

また、 MHA FailOverすると、MHAの実行状態はis running （0：PING_OK）からstopped （2：NOT_RUNNING）に変わります。実行フィードバック結果の変化から、マスタースレーブ切り替えが発生したかどうかを判断できます。 Warningとして扱うことができます。

つまり、MHA の動作状況を監視する必要があるということです。

1.2 実装設計

MHA はManagerノード上で実行され、1 つのManagerノードで数十のクラスターを管理できます。現在、私たちの監視システムはTelegraf + InfluxDB + Grafanaなので、MHA の実行ステータスを収集してInfluxDBに保存するには、 ManagerノードにTelegrafをデプロイする必要があります。既存のGrafana MySQL Dashboardに、 masterha_check_status 的panelを追加します。

1.2.1 従来の方法

記事の第 7 部「MongoDB レプリカセットの状態の監視を例に、 Telegrafシステムに Exec 入力プラグインを作成して展開する方法を確認する」では、 MySQL MHA監視を実装する方法を紹介しましたが、この方法ではクラスタごとに手動でメンテナンスする必要があり、自動検出機能が十分ではないため、特にグループに多数の MHA クラスタがある場合は、メンテナンスコストが増加します。

1.2.2 最適化された方法

Managerノードは、監視対象の MHA クラスターごとに専用の構成ファイルを提供します。最適化された監視方法により、構成ファイルに基づいて監視が自動的に検出および調整されるため、個別の構成やメンテナンスが不要になります。

展開手順は次のとおりです。

2. 実装の詳細

2.1 Python実行ファイルの編集

実行ファイルはtelegraf_checkmhastatus.pyです。

#!/usr/bin/python
# -*- コーディング: UTF-8 -*-

 

インポートOS
インポートio
輸入再
ConfigParserをインポートする

パス='/cnf/mhacnf'
#fout=open('出力ファイル名','w')
os.listdir(Path) 内の Name の場合:
  パス名 = os.path.join(パス、名前)
 ## print(パス名)
 ## print(名前)
  config = ConfigParser.ConfigParser()
  試す：
    config.read(パス名)
    server_item = config.sections()
    server1_host = '' ##MHA cnf 構成ファイルのノード 1
    server2_host = '' ##MHA cnf 構成ファイルのノード 2
    server3_host = '' ##MHA cnf 構成ファイルのノード 3
    mha_cnf_remark = ''
    server_itemに「server1」がある場合:
      server1_host = config.get('server1','ホスト名')
    それ以外：
       server1_host = ''
       mha_cnf_remark = mha_cnf_remark + 'Server1 は構成されていません。'
    server_itemに「server2」がある場合:
      server2_host = config.get('server2','ホスト名')
    それ以外：
      server2_host = ''
      mha_cnf_remark = mha_cnf_remark + 'Server2 は構成されていません。'
    server_itemに「server3」がある場合:
      server3_host = config.get('server3','ホスト名')

      ##print(mha_cnf_remark)
  except 例外を e として:
    印刷する

  mha_status_result = ''
  server1_host <> '' かつ server2_host <> '' の場合:
    cmd_mha_status ='/usr/local/bin/masterha_check_status --conf='+パス名
    os.popen(cmd_mha_status) を mha_status として実行します:
      mha_status_result = mha_status.read()
      mha_status_result で 'running(0:PING_OK)' の場合:
        print('masterha_check_status,server='+server1_host+' ステータス=1i')
        print('masterha_check_status,server='+server2_host+' ステータス=1i')
      mha_status_result で 'stopped(2:NOT_RUNNING)' の場合:
      ＃＃それ以外：
        print('masterha_check_status,server='+server1_host+' ステータス=0i')
        print('masterha_check_status,server='+server2_host+' ステータス=0i')

例:

（1） /cnf/mhacnfディレクトリ内のファイルを走査します（MHA設定ファイルの設定ファイルがこのディレクトリにあると仮定します）。
（2） masterha_check_status --cong = XXXX，XXXX特定の設定ファイルです）。実行結果を確認します。
（３）MHAクラスタノードを取得する。
(4) MHA クラスターはすべて 1 つのマスターと 1 つのスレーブで構成されているため、状況は 1 つだけです: if server1_host <> '' and server2_host <> '': 。これは、ニーズや特定のシナリオに応じて変更できます。
（5）データは、 Tag Key hostとserverとともに、 masterha_check_statusという名前のmeasurementに保存されます。操作が正常であればStatus=1 、そうでない場合はStatus=0 。
（6） Serverに対応するデータはServer IPです（ grafana設定するときに関連付けられることに注意してください）。

2.2 telegrafファイルの変更

ファイルのデフォルトディレクトリは/etc/telegraf/で、デフォルトファイルはtelegraf.confです。

実行ファイルをpythonによって駆動される te telegraf.confに埋め込みます。

コードは次のとおりです。

[[入力.exec]]
  ##コマンド配列
  コマンド = ["python /data/check_mha_status/check_mha_status.py",]
  タイムアウト='60秒'
  データフォーマット="流入"

2.3 Telegrafサービスの実行アカウントを変更する

telegrafサービスのデフォルトの起動アカウントはtelegrafです。ただし、 Pythonおよびpython実行可能ファイルが呼び出されるため、権限を変更する必要があります。簡単にするために、 telegraf serviceの実行中のアカウントをアップグレードし、 rootに変更します。 🙂

telegraf.serviceを変更します。デフォルトのパスは/usr/lib/systemd/system/telegraf.serviceです。

変更されたコードは次のとおりです。

[ユニット]
説明=InfluxDB にメトリックを報告するためのプラグイン駆動型サーバーエージェント
ドキュメント=https://github.com/influxdata/telegraf
後=ネットワーク.ターゲット

[サービス]
環境ファイル=-/etc/default/telegraf
##ユーザー=telegraf
ユーザー=root
ExecStart=/usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d $TELEGRAF_OPTS
ExecReload=/bin/kill -HUP $MAINPID
再起動=失敗時
再起動強制終了ステータス=SIGPIPE
KillMode=コントロールグループ

[インストール]
WantedBy=マルチユーザー.ターゲット

2.4 Telegrafサービスを開始する

service telegraf start ####サービスを開始しますservice telegraf status ####サービスの状態を確認しますservice telegraf stop ####サービスを終了します

2.5 Grafanaの設定とパネルの追加

MySQLインスタンスノードのtelegrafも、 MySQL接続数、 TPS 、 QPS 、マスター/スレーブ状態、レイテンシ、リソース (CPU、メモリ、ディスク、IOWait) などの独自のデータを報告するため、これらの指標はDashboard上に表示され、新たに収集された MHA 実行ステータスは新しく追加された MySQL 指標であるため、MHA 実行ステータスは既存のMySQL DashboardのPanelとして使用する必要があります。

MySQL インスタンスノードで報告されるデータは、各ノードのhostとinstance (サーバー IP: ポート) ですが、MHA 実行ステータスによって報告されるデータは、 managerノードのhostと各インスタンスのサーバー IP です。したがって、ホストの関連付けに基づいて 1 つのDashboardに統合することはできません (関連付けがないため)。 instance (サーバー IP: ポート) とServer IP を通じてのみ関連付けることができます。

まず、インスタンス(サーバー IP:ポート)を正規化し、ポートデータを削除します。これを行うには、次のように Grafana 変数 --server_ip を追加します。

上記のデータソースは、 measurement mysqlからのものであることに注意してください。

次に、別のgrafana変数--mha_serverを追加します。これは上記の変数server_ipに依存することに注意してください。

このようにして、2 つのmeasurement mysqlとmasterha_check_statusが関連付けられ、リンクできるようになります。

最後に、次のようにpanel設定を追加します。

SQL ステートメントは次のとおりです。

SELECT mean("Status") FROM "masterha_check_status" WHERE ("server" =~ /^$mha_server$/) AND $timeFilter GROUP BY time(1m) fill(null)

3. 実装

実行中のステータスは 1、異常またはクローズ中のステータスは 0 です。

メール、WeChat、DingTalk などのAlarmを追加することもできますが、ここでは詳しく説明しません。

もう一つ:

最適化された監視方法により、監視は構成ファイルに従って自動的に検出され、調整されます。したがって、新しいMHAが追加され、そのプロセスに 10 分などの長い時間がかかる場合、既存のMHA監視でエラーまたはアラームが報告される可能性があります。

この状況を回避するには、新しいMHA構成ファイルを追加し、それを MHA 構成ファイルディレクトリに配置することをお勧めします。または、最初に構成ファイルを別のディレクトリに配置し、 MHA構成が完了した後の最後の手順として/cnf/mhacnfディレクトリに移動します。

これで、MySQL MHA 動作状況監視に関するこの記事は終了です。MySQL MHA 動作状況監視に関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: