PXC驗證不通過只有倆個情況
- 快照過久
- SQL語句執行時間太長，或者UNDO表空間過小，或者事務量過大，或者過於頻繁的提交，導致執行SQL過程中進行一致性讀時，SQL執行後修改的前鏡像（即UNDO數據）在UNDO表空間中已經被覆蓋，不能構造一致性讀塊（CR blocks）。 這種情況最多。
- SQL語句執行過程中，訪問到的塊，在進行延遲塊清除時，不能確定該塊的事務提交時間與SQL執行開始時間的先後次序。 這種情況很少。
- 對同一行數據進行修改
PXC其他node節點apply應用失敗一般是硬件層次出現問題
- 失敗之後一般進行IST增量補全
- 若是IST失敗則會被T出集羣
PXC沒有lock table
- 進行alter table DDL操作的時候會升級爲全局鎖，將整個實例鎖住。所以最好建議是DDL操作的時候不能進行online DDL，最好是使用pt-osc或者gh-ost等
PXC的IST
- 當一個節點加入，它當前的UUID於現集羣相同，並且缺失的數據能夠在donor的writeset的cache中找到，則可以進行IST，否則只能全部初始化數據，並且進行SST
- gcache.size默認是128M，可以根據高峯時期binlog一個小時內生成的binlog大小設置
- 需要注意的是，IST所需要的cache是臨時存在的，所以一個集羣完全關閉，但是各個節點關閉的時候seqno不一致，則即使先啓動最新sequo的節點，其他落後的節點任然不能夠做IST，只能SST。所以，如果需要完全關閉整個集羣，需要先中斷外部鏈接，然後在集羣相對靜止的情況下來關閉，才能避免SST。
- PXC之間的IST和SST數據的傳輸主要有三種方式:
- mysqldump邏輯備份，會鎖表。
- rsync 會存在文件鎖
- xtrabackup 一般建議使用這個
腦裂
- 倆個節點發生腦裂的話，那麼就不能針對整個集羣進行操作，任何命令都是顯示"unkown command"
- pc.ignore_db = yes 忽略腦裂，繼續操作
PXC的侷限性
- 僅僅工作在InnoDB引擎表上面，因此對mysql庫下面的系統表的修改不能複製，但是DDL操作時可以被複制的，所以可以通過create user，grant等方式操作系統表。
- 不支持在沒有主鍵的表上面的DELETE操作，select...limit也會在不同節點返回不同的值。（僅僅只是在沒有主鍵的情況下limit會返回不同的結果集麼？）
- 不支持的操作：LOCK／UNLOCK TABLES，lock functions(GET_LOCKS(),RELEASE_LOCK()...)
- query log日誌不能存放在表裏，必須存放在文件中。
- 最大的事務大小由wsrep_max_ws_rows,wrsep_max_ws_size定義，LOAD DATA INFILE 每10K行提交一次，這種事務被分割爲成數個小事務。（XtraDB Cluster 自動分割，還是操作時手動分割？）
- wsrep_max_ws_rows,wrsep_max_ws_size 誰先觸發，誰先進行拆分
- 由於集羣是基於樂觀的併發控制（optimistic consurrency control）,事務衝突的情況可能哎commit階段發生，當多個節點修改同一行數據的時候，只有一個節點能夠成功，失敗的節點將終止，並且返回死鎖錯誤碼 Error:1213 SQLSTATE:4001(ER_LOCK_DEADLOCK).（這樣是否太不穩定了？動不動就會有某個節點終止刮掉的情況？而且這種情況如何處理？）
- 不支持XA事務，因爲XA事務有可能在commit的時候出現異常rollback.(參考http://www.infoq.com/cn/articles/xa-transactions-handle)
- 整個集羣的吞吐量/性能取決於最慢的那個節點，因爲需要在所有的節點上面certification，同時還取決於節點之間的網絡性能，因此需要所有的節點都有相同的硬件配置，並且網絡，磁盤等性能要儘可能的高，例如使用SSD。
流控
- 什麼是流控？
- 流控簡而言之就是流量控制，在PXC雖然是屬於同步複製，但是它也只是在邏輯或者說虛擬的同步複製，在apply和commit並不是同步而是異步的，存在某些原因會導致apply和commit會落後於集羣中的其他節點，一旦落後的事務過多，這個時候就會啓動流控，在整個流控的過程中，集羣是不對外提供寫功能，但是並不會影響讀。
- fc.limit=1
- 控制流控的閥值，一旦node落後這個值則會發起流控，這個值並不是固定的。會根據集羣中節點的數量動態調整的。
- fc_master_slave=NO
- 是否開啓動態調整流控的閥值。一般默認是NO
- fc_factor = 0.0～1.0
- 控制流控什麼時候回覆正常，一般默認是0.5 即是fc.limit的50%的值就會恢復正常，流控結束。
引用
部分信息來自於知數堂課件總結