pxc基礎運維

wsrep_slave_threads:建議每個CORE啟動4個複制線程，這個參數很大程度上受到I/O能力的影響，一般可以通過觀察

wsrep_cert_deps_distance這個狀态變量來擷取目前最佳的線程數，

參數實際上表示機關時間平均多少個writesets能被執行掉

監控要點：

wsrep_flow_control_paused:這個變量辨別目前節點落後于叢集的程度，0.0表示沒有落後，1.0為flow_control已經停止了，應該盡量保證這個變量值為0.0

如果落後厲害，則應該适當增加複制線程數wsrep_slave_threads

wsrep_cert_deps_distance:這個變量辨別目前節點平均時間内并行執行的事務數，這個資料可以用來作為wsrep_slave_threads的參考

同時當并發量很高的時候，這個值也會很大

wsrep_flow_control_sent:表示flow_contro發出FC_PAUSE事件的次數，暫停的次數越多，表示接受到的請求頻繁堵滿SLAVE隊列

，這種情況下不是隊列長度不足，就是機器性能太差

wsrep_local_recv_queue_avg:這個表示本地節點平均的接收隊列長度，如果不為0.0，則表示接收來的資料不能被及時應用

wsrep_local_send_q_avg:表示本地節點發送資料的隊列長度，如果不為0.0，則表示向外發送資料的速度比較慢，有堆積。

高負載引起當機風險的防治

1、參考建議的監控資料，嚴格控制

2、對應用的入口SQL詳細稽核，避免不正常的SQL運作

3、使用一些政策，例如IPTABLES 限制機關時間内的并發量，包個數，來避免當機

節點故障-故障

1、任何的硬體故障、軟體奔潰、網絡接近異常，都将造成節點故障。判斷故障節點的依據，是根據他是否能夠連接配接

PC(Primary component)，而PC是從目前叢集中随機選擇的，是以不能簡單的根據伺服器是否能夠PING通等外部的方式來判斷，需要根據各個節點的wsrep_local_state.

2、故障偵測節點每隔evs.inactive_check_period接收一次資料。

3、一旦節點發生故障，分不同的情況，如果無法進行IST，則需要做SST，代價非常巨大

4、Donor選擇，有自動選擇和手動指定兩種方式，通過wsrep_sst_donor=DONOR_NAME來指定，不指定則在目前叢集中随機選擇。

5、當某個node選為Donor時，如果使用rsync或者DUMP，這個節點是不能提供用戶端服務的，即使使用xtra這個點的性能和穩定性也會受到很大影響，基于這種情況，手動

設定一個，避免高負載的機器被用來做donor

節點故障--恢複

1、節點故障後擷取GTID的方法

執行mysqld 加--wsrep-recover參數可擷取GTID，如：mysqld --defaults-file=/etc/my.cnf --log_error=/dev/stdout --wsrep-recover

然後調用--wsrep_start_position=設定GTID，啟動MYSQL

2、預設情況下，會自動從innodb redolog記錄的checkpoint裡擷取GTID

本文轉自 DBAspace 51CTO部落格，原文連結:http://blog.51cto.com/dbaspace/1873003