1. 程式人生 > >【20180408】MySQL集群PXC的一些隨筆

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

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%的值就會恢復正常,流控結束。

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