### 什麼是流量控制？ Percona XtraDB Cluster具有一種稱為流控制的自調節機制。該機制有助於避免叢集中最弱/最慢的成員明顯落後於叢集中其他成員的情況。 當叢集成員在寫資料很慢（同時又繼續從群集組通道接收寫集）時，傳入/接收佇列的大小會增加。如果此佇列超過設定的閾值（gcs.fc_limit），則該節點將發出FLOW_CONTROL訊息，要求其他成員放慢或暫停處理。 ### gcs.fc_limit 此設定控制何時啟用流量控制。 簡而言之，如果wsrep_local_recv_queue在給定節點上超過此大小，則將傳送暫停的流控制訊息。 fc_limit預設為16個事務。 這實際上意味著，這可以使給定節點位於從叢集提交事務的後面。 ### gcs.fc_master_slave 如果禁用了fc_master_slave（預設情況下），則會動態修改fc_limit。 該模式實際上是根據叢集中節點的數量動態調整fc_limit的。 群集中的節點越多，計算出的fc_limit越大。 其背後的理論是，叢集獲得的規模越大（並且可能來自更多節點的寫操作越忙），每個節點的應用空間就越遠。 如果僅寫入PXC中的單個節點，則建議您通過設定fc_master_slave = YES來禁用此功能。 無論是否動態調整fc_limit的大小，此設定實際上只不過是要更改。 它沒有任何其他能力可以幫助PXC中的單節點提高更好的寫能力。 ### gcs.fc_factor 如果fc_limit控制何時啟用流控制，則fc_factor在釋放時進行定址。 該係數是介於0.0到1.0之間的數字，該數字乘以當前的fc_limit（如果fc_master_slave = NO，則通過上述計算進行調整）。 這樣就產生了在節點發出另一條流控制訊息之前，recv佇列必須降至低於事務級別的事務數，該訊息向群集授予了繼續複製的許可權。 fc_factor預設為0.5，這意味著在恢復複製之前，佇列必須降至fc_limit的50％以下。 在這種情況下，較大的fc_limit可能意味著要等待很長時間才能再次放鬆流量控制。 但是，最近將此值修改為預設值1.0，以允許複製儘快恢復。 對於終端使用者來說，流控是透明的，但是對於叢集管理員而言，重要的是要知道節點是否在使用流控制。如果是這樣，它將影響整個群集的生產率。 ### 查詢節點是否處於流控制中 FLOW_CONTROL不是持久狀態。佇列大小超過設定的閾值後，節點將進入FLOW_CONTROL。一旦佇列大小回到低端水印以下，它將再次釋放。 如何看待較高和較低的閾值 從Percona XtraDB Cluster 5.7.17-29.20開始，現在可以通過SHOW STATUS來檢視較低和較高閾值： ```shell mysql> show status like 'wsrep_flow_control_interval'; +-----------------------------+----------------+ | Variable_name | Value | +-----------------------------+----------------+ | wsrep_flow_control_interval | [ 3547, 3547 ] | +-----------------------------+----------------+ 1 row in set (0.01 sec) ``` 如您所見，wsrep_flow_control_interval狀態變數發出一個範圍，該範圍代表較低和較高的水平。值集（3547, 3547）表示如果傳入佇列大小大於3547，則啟用FLOW_CONTROL。如果大小小於3547，則釋放FLOW_CONTROL。 儘管如此，這仍無法顯示節點在任何給定時刻是否正在使用FLOW_CONTROL。 為了解決這個問題，PXC在版本中同時引入了wsrep_flow_control_status狀態變數。此布林值狀態變數告訴使用者該節點是否在FLOW_CONTROL中。一旦節點處於流控制之外，則當節點採用流控制時，變數將切換為`OFF`，反之則為`ON`： ```shell mysql> show status like '%flow%'; +-------------------------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------------------------+----------------+ | Innodb_scrub_background_page_split_failures_underflow | 0 | | Ssl_session_cache_overflows | 370780 | | Table_open_cache_overflows | 0 | | wsrep_flow_control_paused_ns | 7056357841773 | | wsrep_flow_control_paused | 0.000901 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 176 | | wsrep_flow_control_interval | [ 3547, 3547 ] | | wsrep_flow_control_interval_low | 3547 | | wsrep_flow_control_interval_high | 3547 | | wsrep_flow_control_status | OFF | +-------------------------------------------------------+----------------+ ``` 最後，wsrep_flow_control_sent / recv計數器可用於跟蹤FLOW_CONTROL狀態。這顯示了流控制啟動的總次數。您可以使用`FLUSH STATUS`清除它們。 ```shell mysql> show global status like 'wsrep_flow%'; +----------------------------------+----------------+ | Variable_name | Value | +----------------------------------+----------------+ | wsrep_flow_control_paused_ns | 6893631531679 | | wsrep_flow_control_paused | 0.000413 | | wsrep_flow_control_sent | 5366 | | wsrep_flow_control_recv | 5369 | | wsrep_flow_control_interval | [ 3547, 3547 ] | | wsrep_flow_control_interval_low | 3547 | | wsrep_flow_control_interval_high | 3547 | | wsrep_flow_control_status | OFF | +----------------------------------+----------------+ mysql> flush status mysql> show global status like 'wsrep_flow%'; +----------------------------------+----------------+ | Variable_name | Value | +----------------------------------+----------------+ | wsrep_flow_control_paused_ns | 6893631531679 | | wsrep_flow_control_paused | 0.000413 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_flow_control_interval | [ 3547, 3547 ] | | wsrep_flow_control_interval_low | 3547 | | wsrep_flow_control_interval_high | 3547 | | wsrep_flow_control_status | OFF | +----------------------------------+-------------