Percona XtraDB Cluster(PXC)原理

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

转载于:https://www.cnblogs.com/2woods/p/9427785.html