まだご覧になっていない方のために、ClusterControl 1.7.5をリリースしました。これには、大幅な改善と新しい便利な機能が含まれています。一部の機能には、クラスター全体のメンテナンス、バージョンCentOS8とDebian10のサポート、PostgreSQL 12のサポート、MongoDB4.2とPerconaMongoDB v4.0のサポート、および新しいMySQLフリーズフレームが含まれます。
待ってください、しかしMySQLフリーズフレームとは何ですか？これはMySQLにとって新しいものですか？
それは、MySQLカーネル自体の中で新しいものではありません。これは、MySQLデータベースに固有のClusterControl1.7.5に追加した新機能です。 ClusterControl1.7.5のMySQLFreezeFrameは、次のことをカバーします。
- クラスター障害が発生する前のMySQLプロセスリストのスナップショット（近日公開）。
これらは、バグを追跡し、問題が発生したときにMySQL/MariaDBクラスターを修正するのに役立つ貴重な情報セットです。将来的には、SHOWENGINEInnoDBステータス値のスナップショットも含める予定です。今後のリリースにご期待ください。
この機能はまだベータ版であることに注意してください。ユーザーと協力して、より多くのデータセットを収集する予定です。このブログでは、特にMySQL / MariaDBクラスターを診断するときにさらに情報が必要な場合に、この機能を活用する方法を紹介します。
クラスター障害の場合、以下のように自動回復（クラスター/ノード）が有効になっていない限り、ClusterControlは何もしません。
有効にすると、ClusterControlはノードの回復またはクラスターの回復を試みます。クラスタトポロジ全体を表示します。
MySQLの場合、たとえばマスター/スレーブレプリケーションでは、使用可能なスレーブの数に関係なく、常に少なくとも1つのマスターが稼働している必要があります。 ClusterControlは、レプリケーションクラスターのトポロジを少なくとも1回修正しようとしますが、NDBクラスターやGaleraクラスターなどのマルチマスターレプリケーションに対してより多くの再試行を提供します。ノードリカバリは、障害のあるデータベースノードのリカバリを試みます。プロセスが強制終了されたとき（異常なシャットダウン）、またはプロセスでOOM（メモリ不足）が発生したとき。 ClusterControlはSSH経由でノードに接続し、MySQLを起動しようとします。 ClusterControlが自動データベースリカバリとフェイルオーバーを実行する方法については以前にブログを書いています。ClusterControl自動リカバリのスキームの詳細については、その記事にアクセスしてください。
以前のバージョンのClusterControl<1.7.5では、これらの試行されたリカバリによってアラームがトリガーされました。しかし、お客様が見逃したことの1つは、クラスター障害の直前の状態情報を含む、より完全なインシデントレポートでした。この不足に気づき、ClusterControl1.7.5にこの機能を追加するまで。これを「MySQLフリーズフレーム」と呼びました。この記事の執筆時点で、MySQL Freeze Frameは、クラッシュ直前のクラスター状態の変化につながるインシデントの簡単な要約を提供します。最も重要なのは、レポートの最後に、ホストとそのMySQLグローバルステータス変数および値のリストが含まれていることです。
MySQLフリーズフレームは自動回復とどのように異なりますか？
MySQLフリーズフレームは、ClusterControlの自動回復の一部ではありません。自動回復が無効か有効かにかかわらず、MySQLフリーズフレームは、クラスターまたはノードの障害が検出されている限り、常に機能します。
MySQLフリーズフレームはどのように機能しますか？
ClusterControlには、さまざまなタイプのクラスターステータスとして分類される特定の状態があります。 MySQL Freeze Frameは、次の2つの状態がトリガーされると、インシデントレポートを生成します。
- CLUSTER_DEGRADED
- CLUSTER_FAILURE
ClusterControlでは、CLUSTER_DEGRADEDは、クラスターに書き込むことができるが、1つ以上のノードがダウンしている場合です。これが発生すると、ClusterControlはインシデントレポートを生成します。
CLUSTER_FAILUREの場合、その命名法はそれ自体を説明していますが、クラスターに障害が発生し、読み取りまたは書き込みを処理できなくなった状態です。次に、それはCLUSTER_FAILURE状態です。自動回復プロセスが問題の修正を試みているかどうか、または無効になっているかどうかに関係なく、ClusterControlはインシデントレポートを生成します。
MySQLフリーズフレームを有効にするにはどうすればよいですか？
ClusterControlのMySQLフリーズフレームはデフォルトで有効になっており、状態CLUSTER_DEGRADEDまたはCLUSTER_FAILUREがトリガーまたは検出された場合にのみインシデントレポートを生成します。したがって、ユーザー側でClusterControl構成設定を設定する必要はなく、ClusterControlが自動的に設定します。
この記事の執筆時点では、インシデントレポートを見つけることができる4つの方法があります。これらは、以下のセクションを実行することで見つけることができます。
以前のバージョンの運用レポートは、ユーザーによって生成された運用レポートを作成、スケジュール、または一覧表示するためにのみ使用されます。バージョン1.7.5以降、MySQLフリーズフレーム機能によって生成されたインシデントレポートが含まれています。以下の例を参照してください：
チェックされたアイテムまたはレポートタイプ==incident_reportのアイテムはインシデントですClusterControlのMySQLフリーズフレーム機能によって生成されたレポート。
クラスターを選択してエラーレポートを生成する、つまり次のプロセスを実行する：<クラスターを選択>→ログ→エラーレポート→エラーレポートの作成。これには、ClusterControlホストの下のインシデントレポートが含まれます。
s9sCLIコマンドラインの使用
生成されたインシデントレポートには、s9sCLIコマンドでこれを使用する方法に関する説明またはヒントが含まれています。インシデントレポートに表示される内容は次のとおりです。
ヒント！ s9s CLIツールを使用すると、このレポートのデータを簡単にgrepできます。例：
s9s report --list --long
s9s report --cat --report-id=Nしたがって、エラーレポートを見つけて生成する場合は、次の方法を使用できます。
[[email protected] ~]$ s9s report --list --long --cluster-id=60
ID CID TYPE CREATED TITLE
19 60 incident_report 16:50:27 Incident Report - Cluster Failed
20 60 incident_report 17:01:55 Incident Report特定のホストでwsrep_*変数をgrepする場合は、次の操作を実行できます。
[[email protected] ~]$ s9s report --cat --report-id=20 --cluster-id=60|sed -n '/WSREP.*/p'|sed 's/ */ /g'|grep '192.168.10.80'|uniq -d
| WSREP_APPLIER_THREAD_COUNT | 4 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_CLUSTER_CONF_ID | 18446744073709551615 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_CLUSTER_SIZE | 1 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_CLUSTER_STATE_UUID | 7c7a9d08-2d72-11ea-9ef3-a2551fd9f58d | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_EVS_DELAYED | 27ac86a9-3254-11ea-b104-bb705eb13dde:tcp://192.168.10.100:4567:1,9234d567-3253-11ea-92d3-b643c178d325:tcp://192.168.10.90:4567:1,9234d567-3253-11ea-92d4-b643c178d325:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b25e-cfcbda888ea9:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b25f-cfcbda888ea9:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b260-cfcbda888ea9:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b261-cfcbda888ea9:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b262-cfcbda888ea9:tcp://192.168.10.90:4567:1,9e93ad58-3241-11ea-b263-cfcbda888ea9:tcp://192.168.10.90:4567:1,b0b7cb15-3241-11ea-bdbc-1a21deddc100:tcp://192.168.10.100:4567:1,b0b7cb15-3241-11ea-bdbd-1a21deddc100:tcp://192.168.10.100:4567:1,b0b7cb15-3241-11ea-bdbe-1a21deddc100:tcp://192.168.10.100:4567:1,b0b7cb15-3241-11ea-bdbf-1a21deddc100:tcp://192.168.10.100:4567:1,b0b7cb15-3241-11ea-bdc0-1a21deddc100:tcp://192.168.10.100:4567:1,dea553aa-32b9-11ea-b321-9a836d562a47:tcp://192.168.10.100:4567:1,dea553aa-32b9-11ea-b322-9a836d562a47:tcp://192.168.10.100:4567:1,e27f4eff-3256-11ea-a3ab-e298880f3348:tcp://192.168.10.100:4567:1,e27f4eff-3256-11ea-a3ac-e298880f3348:tcp://192.168.10.100:4567:1 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_GCOMM_UUID | 781facbc-3241-11ea-8a22-d74e5dcf7e08 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_LAST_COMMITTED | 443 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_LOCAL_CACHED_DOWNTO | 98 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_LOCAL_RECV_QUEUE_MAX | 2 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_LOCAL_STATE_UUID | 7c7a9d08-2d72-11ea-9ef3-a2551fd9f58d | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_PROTOCOL_VERSION | 10 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_PROVIDER_VERSION | 26.4.3(r4535) | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_RECEIVED | 112 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_RECEIVED_BYTES | 14413 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_REPLICATED | 86 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_REPLICATED_BYTES | 40592 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_REPL_DATA_BYTES | 31734 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_REPL_KEYS | 86 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_REPL_KEYS_BYTES | 2752 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_ROLLBACKER_THREAD_COUNT | 1 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_THREAD_COUNT | 5 | 192.168.10.80:3306 | 2020-01-09 08:50:24 |
| WSREP_EVS_REPL_LATENCY | 4.508e-06/4.508e-06/4.508e-06/0/1 | 192.168.10.80:3306 | 2020-01-09 08:50:24 | ClusterControlは、ClusterControlが実行されているホストでこれらのインシデントレポートを生成します。 ClusterControlは、ルートシステムユーザーを使用している場合は、/ home /
MySQLフリーズフレームを使用する際の危険や警告はありますか？
ClusterControlは、MySQLノードまたはクラスター内の何も変更または変更しません。 MySQLフリーズフレームは、特定の間隔でSHOW GLOBAL STATUS（現時点）を読み取り、レコードを保存します。これは、MySQLノードまたはクラスターがクラッシュする可能性がある場合、またはハードウェアまたはディスクに問題がある場合の状態を予測できないためです。これを予測することはできないため、値を保存して、特定のノードがダウンした場合にインシデントレポートを生成できます。その場合、これが発生する危険性はほとんどありません。 MySQL内でいくつかのロックが保持されている場合、理論的には一連のクライアント要求をサーバーに追加できますが、まだ気づいていません。一連のテストではこれが示されていないため、許可していただければ幸いです。問題が発生した場合に備えて、サポートチケットを知っているか、提出します。
ClusterControlが特定のフレームをフリーズしてデータを収集する前にネットワークの問題が問題であった場合、インシデントレポートがグローバルステータス変数を収集できない場合があります。そもそもノードへの接続がないため、ClusterControlがさらなる診断のためにデータを収集する方法がないため、これは完全に合理的です。
最後に、なぜすべての変数がグローバルステータスセクションに表示されないのか疑問に思われるかもしれません。当面の間、インシデントレポートで空または0の値が除外されるフィルターを設定します。その理由は、ディスクスペースを節約したいからです。これらのインシデントレポートが不要になったら、[運用レポート]タブから削除できます。
MySQLフリーズフレーム機能のテスト
これを試して、どのように機能するかを確認してください。ただし、ライブ環境または本番環境でこれを実行またはテストしていないことを確認してください。 MySQL / MariaDBのシナリオの2つのフェーズについて説明します。1つはマスタースレーブのセットアップ用で、もう1つはGaleraタイプのセットアップ用です。
マスタースレーブのセットアップでは、簡単に試すことができます。
以下のように、自動回復モード（クラスターとノード）が無効になっていることを確認してください。
したがって、テストシナリオの修正を試みたり、修正したりすることはありません。
マスターノードに移動し、読み取り専用に設定してみてください：
[email protected][mysql]> set @@global.read_only=1;
Query OK, 0 rows affected (0.000 sec)今回はアラームが発生したため、インシデントレポートが生成されました。以下のクラスターはどのように見えるかを参照してください：
そしてアラームがトリガーされました：
そしてインシデントレポートが生成されました：
Galeraベースのセットアップの場合、クラスターが使用できなくなること、つまりクラスター全体の障害が発生することを確認する必要があります。マスタースレーブテストとは異なり、ネットワークインターフェイスを試してみるため、自動回復を有効にすることができます。
注：この設定では、リモートインスタンスでノードをテストする場合は、複数のインターフェイスがあることを確認してください。接続しているインターフェイスをダウンさせると、インターフェイスを起動できなくなります。
3ノードのGaleraクラスターを作成します（たとえば、vagrantを使用）
コマンドを発行して（以下のように）、ネットワークの問題をシミュレートし、これをすべてのノードに対して実行します
[[email protected] ~]# ifdown eth1
Device 'eth1' successfully disconnected.これで、クラスターがダウンし、次の状態になりました：
そしてインシデントレポートを生成します：
サンプルのインシデントレポートの場合、このrawファイルを使用して保存できますhtmlとして。
試すのは非常に簡単ですが、繰り返しになりますが、これは非稼働環境および非製品環境でのみ行ってください。
ClusterControlのMySQLFreezeFrameは、クラッシュを診断するときに役立ちます。トラブルシューティングを行うときは、原因を特定するために豊富な情報が必要です。これがまさにMySQLFreezeFrameが提供するものです。