0
phxsql
编辑
简介:phxsql是一个兼容mysql、服务高可用、数据强一致的关系型数据库集群。phxsql以单master多slave方式部署,在集群内超过一半机器存活的情况下,可自身实现自动master切换,且保证数据一致性。

phxsql -利来国际app

phxsql是一个兼容mysql、服务高可用、数据强一致的关系型数据库集群。phxsql以单master多slave方式部署,在集群内超过一半机器存活的情况下,可自身实现自动master切换,且保证数据一致性。

phxsql基于percona 5.6开发。percona是mysql的一个分支,功能和实现与mysql基本一致。因此本文后续直接把mysql作为讨论对象。

mysql半同步复制存在缺陷,在master进行切换的场景下,数据难以保证一致。

  • 当旧master复制失败时,旧master和updated slave(已收到binlog的slave)需要回滚数据。
  • 当master进行切换时,旧master仍有部分client进行读写。
    关于mysql半同步复制的数据一致性问题可查看 mysql背后的数据一致性分析。

phxsql的设计是为了解决mysql半同步复制的不足,使mysql集群在master切换过程中保证数据的一致。

为了解决mysql的两个问题(binlog复制和master切换),phxsql设计了两个模块(phxbinlogsvr、phxsqlproxy)和一个mysql插件(phxsync)。

phxbinlogsvr负责处理mysql的binlog复制和master管理;phxsqlproxy负责透传client请求到master;phxsync插件负责mysql和phxbinlogsvr的交互。 一台部署了phxsqlproxy,mysql和phxbinlogsvr的机器称为phxsql node。如图1。

phxsql复制流程


在phxsql中,phxbinlogsvr负责管理mysql的角色和存储mysql的binlog,phxbinlogsvr和其管理的mysql部署在同一台物理机上。
mysql master在send event阶段不再把binlog复制给slave,而是通过phxsync插件,把数据复制到phxbinlogsvr集群。

mysql slave也不再从master获取binlog,而是从本机的phxbinlogsvr获取。

phxbinlogsvr集群使用paxos协议进行数据复制。

从逻辑上来看,利用paxos协议进行复制,使phxbinlogsvr形成一个可靠的日志存储。phxsql可以看成是为mysql增加了一个用paxos实现的可靠binlog存储,只要集群中多数派机器存活,就可以解决半同步复制的回滚问题。如图3。

分别从master和slave的角度来解释:

  1. master重启时,通过询问phxbinlogsvr(多数派)pending binlog是否存在来决定是否需要回滚。如图4。
  2. slave从本机phxbinlogsvr能拉取到的binlog都已经经过paxos协议成功复制到多数派机器,因此对于slave来说不存在回滚的问题。
    phxbinlogsvr通过paxos协议复制数据,很好的解决了mysql中需要手动回滚binlog和在大集群时同时需要回滚updated slave上的binlog的问题。

phxsql的master管理

mysql多master同时写入会导致数据的不一致。如图5,机器a是旧master,在收到机器b成为了新master的消息之前提交了transaction 3;而同时机器b已成为新master,transaction 3则会留在机器a而未复制到机器b,最终两机的数据不一致。
mysql多master问题的产生,源于机器间无法得知当前master的状态,最后导致两台机器的数据不一致。

即使使用外部服务(例如zookeeper)也无法解根本问题。

1.对master查询和查询之后的操作不是原子操作,无法保证操作时的准确状态(例如机器a向外部服务查询得知自己是master,然后执行复制binlog操作。但期间出现故障导致两个操作之间停顿了很长时间(譬如1天)。在该期间内master被切换,使得机器a在执行复制binlog时,已不再是master,导致了多master的情况发生。)

2.master管理依赖外部服务的稳定性。

多master问题由于细节太多,暂不在此讨论。

phxsql自身进行了master管理,具有以下特点:

master通过paxos协议投票选出。
master带有租约,并定时续租。租约过期后,需重新选举新的master。
全局只有1个master,或者没有master存在。
有效拒绝过期master的非法写入。

phxsql的master自动切换

phxsql实现了旧master的自动数据回滚和master管理,使得phxsql可以安全地实现master的自动切换,提供高可用服务。和常见的mysql切换master方案不同,phxsql在切换master之后仍然保证集群内各机数据一致。


phxsql自动master流程如下:

slave机器上的phxbinlogsvr定期检查master是否过期。如果过期转第2步,否则继续第1步;
phxbinlogsvr检查本机mysql是否已执行完所有binlog。如果已完成转第3步,否则继续第1步;
phxbinlogsvr发起投票选举新的master。如果投票成功,提升本机mysql为master,关闭readonly开关;否则继续第1步;
旧master恢复,本机的phxbinlogsvr查询发现已不是master,切换mysql角色为slave,设置从本机phxbinlogsvr拉取binlog,并开启readonly开关。

phxsqlproxy请求透传

phxbinlogsvr解决了多master同时写入的问题,使得mysqlclient向旧master写入数据会产生失败。虽然保证了数据的一致性,但仍存在下面2个问题:

  1. mysqlclient持续向旧master写入数据,从而持续的失败。(服务不可用)
  2. 部分mysqlclient向新master写入数据,但其他mysqlclient仍然向旧master读取数据,导致读不到最新的数据。

上述两个问题都是由于mysqlclient的master信息更新不及时;部分client没有及时更新,使得有可能产生phantomread(两次读的结果不一致)。

若slave机器被访问,phxsqlproxy则会把请求透传到master机器的phxsqlproxy。由于phxsql master的全局唯一性,保证了只存在一台mysql被访问。从而解决了多台机器同时被读写的问题。

使用sysbench工具对phxsql和mysql的半同步复制进行了性能对比。phxsql因为增加了phxsqlproxy,导致读性能比原生mysql略低;但由于phxpaxos的实现比mysql的半同步更加高效,让phxsql的写性能比半同步复制更好。

phxsql比mysql读性能比原生mysql略低,但写性能比mysql半同步复制更好。


测试环境和结果如下:

机型信息

  • cpu : intel® xeon® cpu e5-2420 0 @ 1.90ghz * 24
  • 内存 : 32g
  • 磁盘 : ssd raid10
  • 网络互ping耗时
  1. master -> slave : 3 ~ 4ms
  2. client -> master : 4ms

压测工具和参数

  • sysbench
  • —oltp-tables-count=10
  • —oltp-table-size=1000000
  • —num-threads=500
  • —max-requests=100000
  • —report-interval=1
  • —max-time=200

压测内容

  • phxsql和半同步复制在client线程200和500的环境下进行下面方式的压测:
    insert.lua (100%写)
    select.lua (0%写)
    oltp.lua (20%写)

压测结果
client线程数:200

client线程数:500

注:耗时分别为测试结果的平均耗时/95%分位数耗时,单位ms

总结

phxsql解决了mysql半同步复制中数据回滚和多master的问题,使其能实现自动master切换且保证数据一致。phxsql因为增加了phxsqlproxy,导致读性能比原生mysql略低;但由于phxpaxos的实现比mysql的半同步更加高效,让phxsql的写性能比半同步复制更好。

评论

0
0
词条统计
创建者:海尔塔啾啾
编辑次数:1
浏览次数:1263
api调用次数:0
贡献者