レプリケーション

SHOW REPLICA STATUSの状態をリアルタイムで表示します。遅延、I/OとSQLのスレッド、エラー、バイナリログの位置です。

場所： ワークスペース › ツール › レプリケーションモニタ

「レプリケーションモニタ」は、接続中のサーバのSHOW REPLICA STATUS（MariaDB 10.5とMySQL 8.0.22より前はSHOW SLAVE STATUS）を表示し、5秒ごとに読み直します。

モニタを開くには：
「ツール」サイドバーで「レプリケーションモニタ」（円形の矢印のアイコン）をクリックします。モニタは新しいタブで開きます。

主な指標：
- IOスレッド：ソースサーバからイベントを読み込むスレッドです。サーバが報告する値（Yes、No、Connecting）をそのまま表示し、緑になるのはYesのときだけです。
- SQLスレッド：それらのイベントをこのサーバで適用するスレッドで、値は同じです。
- 遅延：ソースサーバから遅れている秒数です。
- 緑：5秒未満
- オレンジ：5秒から30秒
- 赤：30秒以上
スレッドが止まっているとサーバには数値がなく、カードには「データなし」と表示されます。ゼロでは、何も適用していないレプリカについて「同期済み」と言うことになるからです。
- ソースサーバ：このレプリカが読み込んでいるホストです。
- バイナリログの位置：ソースのバイナリログファイル、IOスレッドが読み込んだ位置、SQLスレッドが実行した位置です。2つが違う間は、受信してまだ適用していないイベントがあります。

エラー：スレッドがエラーで止まると、「レプリケーションのエラー」セクションが現れ、サーバのメッセージ全文が表示されます。

すべての状態：SHOW REPLICA STATUSのすべての列を、生の値で表示します。カードに出ないもの、たとえばGTIDの位置、Master_Server_Id（このレプリカがどのマシンから読み込んでいるか）、設定された遅延も含まれます。

自動更新：「自動更新（5秒）」スイッチで5秒ごとに状態を読み、「更新済み」に最後に読んだ時刻が表示されます。オフにすると静的なスナップショットのままになり、読み直したいときは「更新」をクリックします。

遅延のアラート：遅延が「サーバのアラート」で設定したしきい値に達すると（トピック「サーバのアラート」を参照）、システムの通知が送られます。

モニタは読むだけで、レプリケーションを開始も停止もしません。レプリカではないサーバ（プライマリやスタンドアロンのサーバ）では、カードの代わりに「このサーバはレプリカではありません」と表示されます。

キーワード： レプリケーション、レプリカ、スレーブ、マスター、遅延、IOスレッド、SQLスレッド、SHOW REPLICA STATUS、自動更新、レプリケーションのエラー、バイナリログの位置

ひとつのマシンを内側から見るのではなく、グループ全体をひと目で。

場所： ワークスペース › ツール › トポロジ

「レプリケーションモニタ」と並んで存在し、それに取って代わるものではありません。あちらは接続中のマシンの状態を内側から見て表示し、こちらはグループのすべてのマシン（開いていないものも含む）と通信し、読むだけです。

どのマシンがプライマリで、どれがレプリカかは、あなたが宣言するものです。検出はしません。検出では今接続しているものしか見えないので、グループがひとりでに変わり、「このレプリカはもうグループにない」と「このレプリカは落ちている」を区別できなくなるからです。

代わりにするのは、あなたに反論することです。宣言したレプリカがプライマリから見えなかったり、レプリカが別のサーバを指していたりすれば、そう伝えます。

グループの別のレプリカから読み込むレプリカ（カスケード）は、矛盾ではありません。図はそのレプリカから矢印を描き、プライマリは自分から読み込むものだけを数えます。

メンバーが応答しないのはグループの通常の状態で、エラーではありません。「9件中7件に到達」と表示され、欠けている2つが名前と理由とともに示されます。

キーワード： レプリケーション、トポロジ、グループ、プライマリ、レプリカ

「遅延秒数」は2つの場合にうそをつきます。だからその横に、GTIDのずれがあります。

場所： トポロジ › 遅延

Seconds_Behind_Sourceが測るのは適用中のイベントで、適用し残っている量ではありません。そのため、2つの点で誤解を招きます。

- IOスレッドが止まっていると、サーバには計算の材料がなく、nullを返します。ここでは0ではなく「データなし」と表示されます。0では、切断されたレプリカについて「同期済み」と言うことになるからです。
- 長い停止のあと再接続したばかりのレプリカは、取得すべきバイナリログがまだ何時間分も残っていても、今適用しているイベントが新しいというだけで、0と言うことがあります。

だからその横にGTIDのずれがあります。プライマリが持っていてレプリカがまだ実行していないトランザクションの数です。この数値は、何が足りないかをたしかに示します。レプリケーションがGTIDではなくバイナリログの位置で動いているときは比べるものがなく、それもそう表示されます。

キーワード： 遅延、遅れ、GTID、ずれ

保存済みの接続のうち、どれがプライマリで、どれがレプリカかを選びます。

場所： トポロジ › グループを宣言

グループはツール自体から宣言します。ツールバーの「グループを宣言」ボタンです。サーバモニタの設定にはありません。そちらは、別のスイッチを持つ別のツールです。

メンバーは保存済みの接続から選びます。ひとつをプライマリに選び、ほかを見たい順にレプリカとして加えます。保存済みの接続が少なくとも2つ必要です。プライマリ用とそのレプリカ用です。なければ、まず接続マネージャで保存してください。

ツールがレプリケーションを調べられるエンジンへの接続だけが出てきます。それ以外は一覧に現れず、なぜないのかがわかるように、そのエンジンの名前がレプリカの下に表示されます。すでに保存したメンバーをもう調べられなくなった場合も、グループはそのメンバーを未到達として、理由とともに表示し続けます。

Calíopeはトポロジを推測しません。検出では今接続しているものしか見えないので、グループがひとりでに変わり、「このレプリカはもうグループにない」と「このレプリカは落ちている」を区別できなくなるからです。代わりに、宣言したレプリカがプライマリから見えないときに、あなたに反論します。

各グループは、独自のポーリング間隔と独自のスイッチを持ちます。オフにすると、トポロジを削除せずにポーリングが止まります。メンバーだった接続を削除しても、グループは消えません。印が付き、どのメンバーが取り除かれたかが伝えられます。

キーワード： 宣言、グループ、プライマリ、レプリカ、接続、設定

レプリカの表の行から、そのメンバーのすべてを開きます。役割、チャネル、GTIDのずれ、最近のエラーです。

場所： ワークスペース › ツール › トポロジ

レプリカの表の行をクリックまたはタップすると（VoiceOverやキーボードで実行してもかまいません）、そのメンバーのすべてが開きます。宣言した役割と観測された役割、アドレス、バージョン、測定した時刻です。チャネルごとに、ソース、遅延、IOスレッドとSQLスレッド、バイナリログのファイルと位置、GTIDのずれ、IOとSQLの最後のエラーとそのコードを表示します。プライマリでは、バイナリログの状態と、接続しているのが見えるレプリカの数が加わります。

GTIDのずれは4通りに読めます。同期している、遅れている（差が大きいときは琥珀色）、プライマリがポーリングの間に進んだ範囲内、または比較できない（GTIDなし）です。

下部の「前へ」と「次へ」でメンバーを順に移動し、「コピー」で技術的な要約をコピーし、「完了」で閉じます。グループを離れたメンバーは、そう表示されます。

キーワード： レプリケーション、メンバー、レプリカ、GTID、遅延、スレッド、エラー

サーバのバイナリログをイベントごとに読み、クラス（DDL、DML、システム）とテキストで絞り込みます。

場所： ワークスペース › ツール › バイナリログ

バイナリログは、サーバのすべての変更の記録です。レプリカがコピーするものであり、ポイントインタイムリカバリが再生するものです。ビューアは、コマンドラインユーティリティのmysqlbinlogを使わずに、アプリからそれを読みます。

開き方：
ツールサイドバーで、バイナリログ（巻物のアイコン）をクリックします。新しいタブで開き、すぐに最新のファイルを読み込みます。

使い方：
1. ファイル：サーバのバイナリログファイル（SHOW BINARY LOGS）がサイズとともに一覧表示されます。1つ選ぶと、そのイベントを読み込みます。
2. 「上限」は、ファイルの先頭から読み込むイベントの数です（100〜2000）。変更するとファイルを読み直します。ファイルのイベントがそれより多い場合は、一覧の上の行でそのことが示されます。続きを読むには上限を上げてください。
3. 「種類」でクラスを絞り込みます：すべて、DDL、DML、システム。
4. 「検索…」欄では、種類または内容にそのテキストを含むイベントだけが残ります。
5. 「ログを再読み込み」でファイルの一覧を読み直し、選んでいるファイルも読み直します。タブを開いた後の変更はこうして確認します。最新のファイルを読んでいて、その後サーバが別のファイルを始めていた場合は、新しいファイルに移ります。

イベントのクラス：
- DDL（オレンジ）：スキーマやアカウントを変更するSQL文。CREATE、ALTER、DROP、RENAME、TRUNCATE、GRANT、REVOKE。
- DML（青）：データの変更。行ベースのログでは、1つの変更はグループになります。それを生んだSQL文（サーバが記録していれば、MariaDBではAnnotate_rows、MySQLではRows_query）、対象のテーブル（Table_map）、そして行（Write_rows、Update_rows、Delete_rows）です。ステートメントベースのログでは、INSERT、UPDATE、DELETE、REPLACE、LOAD DATAそのものです。
- システム（グレー）：変更でないものすべて。BEGIN、コミット（Xid）、Gtid、Rotate、ファイルのヘッダ（Format_desc）、その他の制御イベント、そしてFLUSH PRIVILEGESのように、データもスキーマも変更しないSQL文です。

各行に表示されるもの：
イベントの種類、開始位置（位置）、サーバが記録していれば終了位置、クラス、そしてInfoフィールド（SQL文のSQL、Table_mapのテーブル、コミットのトランザクション番号）です。

使い道：
- 変更の監査：どのDDLが、どの順番で実行されたか。
- レプリケーションの分析：レプリカが何をコピーしているか。
- ポイントインタイムリカバリ：どの位置まで復元するかの正確な位置。

ビューアは読むだけです。バイナリログを削除したり変更したりすることはありません。

必要な権限：
- MariaDB 10.5以降：BINLOG MONITOR。
- MySQL：ファイルの一覧表示にREPLICATION CLIENT、イベントの読み込みにREPLICATION SLAVE。

これらがない場合や、バイナリログがオフの場合、ビューアはアクセスできないと表示します。サーバが応答しない場合はそのことを表示し、「ログを再読み込み」で再試行します。

macOS、iPad、iPhone、Apple Vision Proで使えます。

キーワード： binlog、バイナリログ、イベント、レプリケーション、監査、ポイントインタイム、DML、DDL、SHOW BINARY LOGS、mysqlbinlog、Xid、Gtid、Write_rows、Update_rows