博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【20180408】MySQL集群PXC的一些随笔
阅读量:5815 次
发布时间:2019-06-18

本文共 2110 字,大约阅读时间需要 7 分钟。

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

引用

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

转载于:https://blog.51cto.com/11819159/2095585

你可能感兴趣的文章
2019届高二(下)半期考试题(文科)
查看>>
nginx 301跳转到带www域名方法rewrite(转)
查看>>
AIX 配置vncserver
查看>>
windows下Python 3.x图形图像处理库PIL的安装
查看>>
【IL】IL生成exe的方法
查看>>
network
查看>>
SettingsNotePad++
查看>>
centos7安装cacti-1.0
查看>>
3个概念,入门 Vue 组件开发
查看>>
没有JS的前端:体积更小、速度更快!
查看>>
数据指标/表现度量系统(Performance Measurement System)综述
查看>>
GitHub宣布推出Electron 1.0和Devtron,并将提供无限制的私有代码库
查看>>
Angular2, NativeScript 和 React Native比较[翻译]
查看>>
论模式在领域驱动设计中的重要性
查看>>
国内首例:飞步无人卡车携手中国邮政、德邦投入日常运营
查看>>
微软将停止对 IE 8、9和10的支持
查看>>
微服务架构会和分布式单体架构高度重合吗
查看>>
如何测试ASP.NET Core Web API
查看>>
《The Age of Surge》作者访谈
查看>>
测试人员的GitHub
查看>>