MySQL 8.0 リファレンスマニュアル


MySQL 8.0 リファレンスマニュアル  /  ...  /  レプリケーションアプライアンスワーカースレッドの監視

17.2.3.2 レプリケーションアプライアンスワーカースレッドの監視

マルチスレッドレプリカでは、「パフォーマンススキーマ」テーブル replication_applier_status_by_coordinator および replication_applier_status_by_worker に、レプリカコーディネータスレッドおよびアプライヤワーカースレッドのステータス情報がそれぞれ表示されます。 複数のチャネルを持つレプリカの場合、各チャネルのスレッドが識別されます。

マルチスレッドレプリカコーディネータスレッドは、詳細設定が情報メッセージを表示するように設定されている場合、定期的にレプリカエラーログに統計も出力します。 統計は、コーディネータスレッドがアプライヤワーカースレッドに割り当てたイベントの量に応じて出力されます。最大頻度は 120 秒ごとに 1 回です。 このメッセージには、関連するレプリケーションチャネルまたはデフォルトのレプリケーションチャネル (名前のない) に関する次の統計がリストされます:

経過秒数

この情報がエラーログに最後に出力された時間と現在の時間の差 (秒)。

イベント割当済

コーディネータスレッドが起動されてから、すべてのアプライヤワーカースレッドに対してコーディネータスレッドがキューに入れたイベントの合計数。

オーバーランレベルを超えて入力されたワーカーキュー

オーバーランレベルを超えて、任意のアプライヤワーカースレッドにキューに入れられているイベントの現在の数。これは、16384 イベントの最大キュー長の 90% に設定されます。 この値がゼロの場合、アプライヤワーカースレッドは容量の上限で動作していません。

ワーカーキューがいっぱいであるため待機中

アプライヤワーカースレッドキューがいっぱいであったために、コーディネータスレッドがイベントのスケジュールを待機する必要があった回数。 この値がゼロの場合、アプライヤワーカースレッドは容量を使い果たしませんでした。

合計サイズのため待機中

slave_pending_jobs_size_max 制限に達したために、コーディネータスレッドがイベントのスケジュールを待機する必要があった回数。 このシステム変数は、まだ適用されていないイベントを保持するアプライヤワーカースレッドキューで使用可能なメモリーの最大量 (バイト) を設定します。 異常に大きいイベントがこのサイズを超えると、すべてのアプライヤワーカースレッドに空のキューが設定されてから処理されるまで、トランザクションは保持されます。 後続のすべてのトランザクションは、大規模なトランザクションが完了するまで保持されます。

クロック競合で待機中

イベントが依存していたトランザクションがまだコミットされていないために、コーディネータスレッドがイベントのスケジュールを待機する必要があったナノ秒数。 slave_parallel_type が (LOGICAL_CLOCK ではなく) DATABASE に設定されている場合、この値は常にゼロです。

ワーカーが占有している場合の待機 (件数)

コーディネータスレッドが短期間スリープした回数。これは 2 つの状況で実行される可能性があります。 最初の状況では、コーディネータスレッドがイベントを割り当て、最大キュー長の 10% のアンダーランレベルを超えて適用者ワーカースレッドキューが一杯であることが判明します。この場合、最大 1 ミリ秒スリープします。 2 つ目の状況では、slave_parallel_typeLOGICAL_CLOCK に設定され、コーディネータのスレッドがトランザクションの最初のイベントをアプライアンスのワーカースレッドキューに割り当てる必要があり、これは空のキューを持つワーカーに対してのみ実行されるため、キューが空でない場合、コーディネータスレッドは空になるまでスリープします。

ワーカーが占有している場合に待機

空のアプライヤワーカースレッドキューを待機している間にコーディネータスレッドがスリープしたナノ秒数 (つまり、前述の 2 つ目の状況では、slave_parallel_typeLOGICAL_CLOCK に設定され、トランザクションの最初のイベントを割り当てる必要があります)。


関連キーワード:  設定, トランザクション, イベント, ソース, ベース, チャネル, コーディネータスレッド, バイナリ, GTID, 待機