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后指执行数据合并,但和发起节点有一定的时间差,这里可能会出现延时。
Percona XtraDB Cluster(PXC)原理-LMLPHP
Percona XtraDB Cluster(PXC)原理-LMLPHP

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
    Percona XtraDB Cluster(PXC)原理-LMLPHP
  • 群集性能监控
    wsrep_local_recv_queue & wsrep_local_send_queue
    wsrep_flow_control_sent & wsrep_flow_control_recv
    wsrep_relicated & wsrep_receved
05-08 08:04