【20180408】MySQL集群PXC的一些随笔

285572001

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%的值就会恢复正常，流控结束。
    
  
  

引用
　　部分信息来自于知数堂课件总结