Percona XtraDB Cluster之流量控制
什么是流量控制?
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來查看較低和較高閾值：
- 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：
- 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清除它們。
- 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 |
- +----------------------------------+----------------+
【編輯推薦】
