【20180408】MySQL集羣PXC的一些隨筆

PXC驗證不經過只有倆個狀況

1. 快照太久
   • SQL語句執行時間太長，或者UNDO表空間太小，或者事務量過大，或者過於頻繁的提交，致使執行SQL過程當中進行一致性讀時，SQL執行後修改的前鏡像（即UNDO數據）在UNDO表空間中已經被覆蓋，不能構造一致性讀塊（CR blocks）。 這種狀況最多。
   • SQL語句執行過程當中，訪問到的塊，在進行延遲塊清除時，不能肯定該塊的事務提交時間與SQL執行開始時間的前後次序。 這種狀況不多。
2. 對同一行數據進行修改

PXC其餘node節點apply應用失敗通常是硬件層次出現問題

1. 失敗以後通常進行IST增量補全
2. 如果IST失敗則會被T出集羣

PXC沒有lock table

• 進行alter table DDL操做的時候會升級爲全局鎖，將整個實例鎖住。因此最好建議是DDL操做的時候不能進行online DDL，最好是使用pt-osc或者gh-ost等

PXC的IST

1. 當一個節點加入，它當前的UUID於現集羣相同，而且缺失的數據可以在donor的writeset的cache中找到，則能夠進行IST，不然只能所有初始化數據，而且進行SST
   • gcache.size默認是128M，能夠根據高峯時期binlog一個小時內生成的binlog大小設置
2. 須要注意的是，IST所須要的cache是臨時存在的，因此一個集羣徹底關閉，可是各個節點關閉的時候seqno不一致，則即便先啓動最新sequo的節點，其餘落後的節點任然不可以作IST，只能SST。因此，若是須要徹底關閉整個集羣，須要先中斷外部連接，而後在集羣相對靜止的狀況下來關閉，才能避免SST。
3. PXC之間的IST和SST數據的傳輸主要有三種方式:
   • mysqldump邏輯備份，會鎖表。
   • rsync 會存在文件鎖
   • xtrabackup 通常建議使用這個

腦裂

1. 倆個節點發生腦裂的話，那麼就不能針對整個集羣進行操做，任何命令都是顯示"unkown command"
   • pc.ignore_db = yes 忽略腦裂，繼續操做

PXC的侷限性

1. 僅僅工做在InnoDB引擎表上面，所以對mysql庫下面的系統表的修改不能複製，可是DDL操做時能夠被複制的，因此能夠經過create user，grant等方式操做系統表。
2. 不支持在沒有主鍵的表上面的DELETE操做，select...limit也會在不一樣節點返回不一樣的值。（僅僅只是在沒有主鍵的狀況下limit會返回不一樣的結果集麼？）
3. 不支持的操做：LOCK／UNLOCK TABLES，lock functions(GET_LOCKS(),RELEASE_LOCK()...)
4. query log日誌不能存放在表裏，必須存放在文件中。
5. 最大的事務大小由wsrep_max_ws_rows,wrsep_max_ws_size定義，LOAD DATA INFILE 每10K行提交一次，這種事務被分割爲成數個小事務。（XtraDB Cluster 自動分割，仍是操做時手動分割？）
   • wsrep_max_ws_rows,wrsep_max_ws_size 誰先觸發，誰先進行拆分
6. 因爲集羣是基於樂觀的併發控制（optimistic consurrency control）,事務衝突的狀況可能哎commit階段發生，當多個節點修改同一行數據的時候，只有一個節點可以成功，失敗的節點將終止，而且返回死鎖錯誤碼 Error:1213 SQLSTATE:4001(ER_LOCK_DEADLOCK).（這樣是否太不穩定了？動不動就會有某個節點終止刮掉的狀況？並且這種狀況如何處理？）
7. 不支持XA事務，由於XA事務有可能在commit的時候出現異常rollback.(參考http://www.infoq.com/cn/articles/xa-transactions-handle)
8. 整個集羣的吞吐量/性能取決於最慢的那個節點，由於須要在全部的節點上面certification，同時還取決於節點之間的網絡性能，所以須要全部的節點都有相同的硬件配置，而且網絡，磁盤等性能要儘量的高，例如使用SSD。

流控

1. 什麼是流控？
   • 流控簡而言之就是流量控制，在PXC雖然是屬於同步複製，可是它也只是在邏輯或者說虛擬的同步複製，在apply和commit並非同步而是異步的，存在某些緣由會致使apply和commit會落後於集羣中的其餘節點，一旦落後的事務過多，這個時候就會啓動流控，在整個流控的過程當中，集羣是不對外提供寫功能，可是並不會影響讀。
2. fc.limit=1
   • 控制流控的閥值，一旦node落後這個值則會發起流控，這個值並非固定的。會根據集羣中節點的數量動態調整的。
3. fc_master_slave=NO
   • 是否開啓動態調整流控的閥值。通常默認是NO
4. fc_factor = 0.0～1.0
   • 控制流控何時回覆正常，通常默認是0.5 便是fc.limit的50%的值就會恢復正常，流控結束。

引用

部分信息來自於知數堂課件總結