Percona XtraDB Cluster(PXC)原理
介绍:
PXC曾经属于一套近乎最完美的mysql高可用集群解决方案(现mgr总体上要优于pxc)，相比传统的基于主从复制模式的集群架构MHA和MM+keepalived，最突出特点就是解决了数据复制延迟问题，基本上可以达到实时同步。节点间关系是对等的,事务要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证MySQL集群的数据一致性.
1.PXC使用端口
- 3306 数据库对外服务端口
- 4444 SST(State Snapshot Transfer )全量传输端口, 指数据镜象传输,可先配置:xtrabackup , rsync ,mysqldump
- 4567 :成员通信端口
- 4568 : IST(Incremental State Transfer )增量传输端口(相对于SST的增量)。
2.PXC的优势
- 强一致性
- 同步延迟小
- 每一个节点都可以读写
- 用箱子推给Group里所有的成员， data page 相当于物理复制，而不是发blog日志,再重现.
- 同步的是结果数据.
- 从节点在apply数据时，支持并行执行，有更好的性能表现
PXC的执行流程
客户端先发起一个事务先在本地执行，当发起对事务的提交操作时,在给用户响应提交成功之前需要将写请求广播出去，然后获取到一个全局的事务ID，一并传送到其他节点上面。各节点检查是否有冲突数据，等各有节点返回OK后事务发起节点commit并返回客户端，否则就需要取消此次事务的操作,事务跟随节点返回无冲突OK后指执行数据合并,但和发起节点有一定的时间差,这里可能会出现延时。
PXC的局限性
- 只支持Innodb引擎.
- 不支持XA事务,
- 因双写导致的updata 更新丢失
- Query log 不能使用Table,,只能log_output=file
- 不支持在没有主键的表delete操作,select ...limit也会返回不同的值.
- 由于基于乐观的并发控制,显示事务commit时可能会失败 .
- 没有lock tables,所有表DDL操作,一定要用pt-osc 否则为导致整个集群锁定
- 最大的事务大小由wsrep_max_ws_rows、wsrep_max_size定义,load data infile每10k行提交时,这种事务将会被拆成数个.
- binlog_row_query_log_events不支持
- 整个集群性能取决于最慢的那个节点,利用xtrabakup做sst时,可能造成Donor Crash,建议在my.cnf中增加innobackup-opts='"- - no-backup-losts".
- 不支持表空间传输.
- 推荐节点数在3-8之间
重要参数
wsrep_provider_options="gcache.size=128M" 主要用于控制sst的动作,从节点给主节点的数据差大小.建议设置1-4G(离线2小时以内的数据量)
主注意事项
- 禁止 alter
- SST 这块建议利用Slave -> PXC
- 关于脑裂,避免结节为偶数，特别是在相同的区域内.
- 集群重启，尽量使用循环重启,否则要检查节点间数据状态show global status like "wsrep_last_commited "(命令有可能记混了,:) .
- 超过100G时避免SST.主从改PXC怎么实现?
群集监控
- 群集健康参数监控
wsrep_cluster_status!=4
wsrep_connected != on
wsrep_ready!=on
- 群集性能监控
wsrep_local_recv_queue & wsrep_local_send_queue
wsrep_flow_control_sent & wsrep_flow_control_recv
wsrep_relicated & wsrep_receved