本文将回顾MySQL复制概念和MySQL几种复制方案,同时也会澄清一些关于复制问题的误解。
MySQL复制是什么?
复制能够保护信息得到备份,并且备份会不同于原数据,备份会被保存到另一个环境。即主备数据不在同一台服务器。下图是MySQL复制示意图:
MySQL有 哪 些复制方案?
复制如此重要,那么在MySQL中我们有哪些选择呢?
1. 异步复制
异步复制意味着本地环境操作完成,事务就完成 ,不会受到slave复制是否完成的影响。
当改变被提交后,master就会把数据修改信息放到binlog中(也可能把实际的statement放到binlog中,这是row-based复制和statement-based复制的不同,后面会讲到)。dump线程读取binlog日志然后将其发送到slave,slave接受并保存到待处理队列中(被称为relay-log),slave会执行每一个在master上的改变:
2. 半同步复制
半同步复制(Semi-synchronous replication)意味着master和slave彼此通讯确保事务的正确转移。 当改变发生时,master需要等待slave已经将日志保存到relay-log中并向master回复确认master才能提交事务 。 半同步复制可以保证事务被正确的复制,但不能保证在slave上一定发生:
需要注意的是,半同步复制的话,master需要等待至少有一个slave服务器确认接收到事务并保存了relay-log(或达到超时)才能继续处理同一个SESSION中的当前事务,至于具体多少个slave确认,可以通过参数rpl_semi_sync_master_wait_slave_count进行配置,这个值有效范围是1~1024之间,而且这个值可以动态更新。举个栗子:
假设rpl_semi_sync_master_wait_slave_count被设置为2,并且有两个slave,分别是: slave1和slave2。
1. T1等待两个slave的ack;
2. master收到slave1的ack;
3. 此时加入一个slave3,并将rpl_semi_sync_master_wait_slave_count改为3;
4. master收到 sl av e2的ack ;
5. master收到 sl av e3的ack;
6. master唤醒等待中的事务,并准备提交;
记住半同步复制会影响性能,因为它需要等待来自slave的确认(ack)。但是,它也能减少slave上由于故障导致数据丢失的风险。
3. 组复制
组(Group)复制是MySQL5.7版本新介绍的概念,在5.7.17发布了GA,而且以插件模式提供。
任意一个数据库节点无论什么时候执行一个事务,组复制插件在向客户端响应它已经完成事务前,会尝试得到其他数据库节点的同意。组复制示意图如下:
4. Percona XtraDB Cluster / Galera Cluster
再介绍一个把master数据复制到其他节点的解决方案,就是Percona XtraDB Cluster,简称PXC。这个解决方案把重心放在一致性上,并且通过使用一个认证过程来保证事务避免冲突和执行的正确性。在这个集群方案的数据库环境下, 每个节点的数据都是相同的,节点之间会依赖galera提供的广播机制来保证一致性 。
以一条SQL为例,某节点接收SQL请求后,在commit之前,由wsrep API 调用galera库进行集群内广播,所有其他节点验证成功后事务在集群所有节点进行提交,反之rollback。PXC保证整个集群所有数据的强一致性,满足CAP理论中的CA,即 Consistency 和 Availability。
Percona XtraDB Cluster 有很多组件:
该解决方案几乎是同步的,可与组复制相媲美。但是,它还具有使用多主复制的能力。Percona XtraDB Cluster这样的组件能很好的提高数据库基础架构可用性:
Row-Based VS. Statement-Based
讨论MySQL复制,就不得不提Row-Based复制和Statement-Based复制。 因为它们是两种不同复制方案的实现原理。
对于statement-based 复制(被翻译为基于语句复制),执行的SQL本身会被写入binlog中,例如完全相同的 INSERT/UPDATE/DELETE 语句会被在slave上执行。它的优缺点如下:
Row-based 复制(基于行复制)是从MySQL 5.7.7起默认的选择,它有很多优点,改变的行会被记录在binlog中,因此它不需要上下文信息。它的其他优点如下::
当然,也有缺点:
关于复制的误解
误解1: 复制就是集群
标准的异步复制不是集群,记住不管是标准的异步复制还是半同步复制,都不能保证环境服务于同一数据集。 而使用集群(例如Percona XtraDB Cluster)时,这是不同的,任意一个请求打到任意一台服务器上其结果都一样。如果不是,则会从群集中删除受影响的节点。异步复制没有这样的保障,即使某个slave节点与master处于不一致状态时仍然会接受操作请求。
误解2: 复制作为手动故障转移方案
理论上来说,两个环境之间是有可比性的。然而,有许多参数能影响性能和数据一致性。只要你使用了异步复制,在master上发生的事务正确性就无法在slave上得到保障。当然,你可以通过增强持久化的配置来改善这点,但是它相应的会带来一定的性能损耗,性能和可靠之间总需要做一定的取舍。
误解3: 我有复制,所以不用备份
复制是为了对数据集有一个可访问的副本的解决方案,通过把读请求打到复制节点,能减轻master的压力。但是复制不是备份。备份一般是指离线备份,它的作用是数据库所在环境发生灾难性的破坏不可恢复时,还能通过备份恢复数据库。对数据库进行离线备份是非常重要和有意义的事情!
误解4: 因为有复制,所以数据库能负载均衡事务请求
给master增加一个slave尽管可以改善系统的可用性,但是你仍然需要自己做几件事情:把读请求打到slave上,把写请求打到master上。有很多代理工具可以完成这样的事情,当然你可以自己动手造轮子!