《高性能MYSQL》复制-笔记

# 《高性能MYSQL》复制-笔记

复制概述

复制解决的基本问题是让一台服务器的数据与其他服务器保持数据同步。一台主库的数据可以同步到多台备库上。常见的用途：1.应用实现读写分离从而负载均衡。2.由单机变为集群，可实现数据的分布。3.利用心跳检测机制以及主备切换实现高可用和故障切换。

如何复制

复制步骤

1. Master更改数据记录在binlog（二进制日志），通过binlog dump线程读取binglog数据后发送给IO线程
2. IO线程将数据传输给slave的Relaylog（中继日志）
3. Slave数据通过SQL线程读取Relaylog数据并执行。

复制涉及的概念

两个日志

Binlog：二进制文件。存储Master数据库中被修改的数据。

Relaylog：中继日志。与Binlog作用一样，只不过当被读取完以后会被删除

三个线程

Binlog dump 
    将读取Binlog后发送数据给IO线程

IO 线程
    将接收到数据传给RelayLog日志

SQL线程
    读取RelayLog数据

配置复制

基本配置步骤
MYSQL复制配置非常的简单。但由于场景的不同，基本的步骤上还是有点差异。下面是一主一备的基本步骤：
1. 在主中创建可用于复制的帐号
2. 配置主库和从库
3. 在从库中配置连接主库的信息并开启从主库复制数据

具体的配置步骤可以参考：MYSQL复制配置

推荐的复制配置
1. sync_binlog

sync_binlog = 1

开启此选项，MYSQL每次在提交事务之前会将二进制日志保存在磁盘中，保证服务器奔溃时不会丢失事件。但比不开启来说，多了一步IO的操作。

2. log_bin

log_bin=/var/lib/mysql/master_binlog

此选项命名二进制日志，避免因为服务器名的变化导致日志文件名的变化。

3. relay_log

relay_log=/logs/slave_relay_log

命名中继日志，避免中继日志基于机器名来命名

4. read_only

read_only

此选项主要用于从库，可以阻止大部分用户更改数据，避免与主发生数据不一致性的问题

5. skip_slave_start

skip_slave_start

此选项阻止从服务器奔溃后自动复制，会导致更多表的损坏，增加后期维护难度。

6. log_slave_update

log_slave_update

此选项让从库记录更改数据的事件，即记录binlog日志，可让备库变成其他服务器的主库。方便后期主备互换或者备份。

复制拓扑

可以在任意个主库和备库之间建立复制，只有一个限制：每一个备库只能有一个主库。有很多复杂的拓扑结构，接下来会介绍下几个最常见以及简单的拓扑结构。
1. 一主多从
在少量写和大量读时，这种结构是非常有用的。可实现读写分离，很多时候在应用开始出现瓶颈时，可采用一主多从，简单又实用。

2. 多级复制
当一主多从中，从服务器增加，过多的推送binlog会导致主服务器的IO压力增大。所以为了分担主服务器的IO压力，则创建多一台服务器负责推送binlog。

3. 主主复制，被动形式
当主服务器发送故障宕机时，为了及时恢复弥补损失，我们应该将备库切换成主库继续运行。所以我们可以采用主主复制的架构。

复制管理与维护

上面讲了如何配置以及复制中的基本结构，接下来将会说下配置了复制后如何管理以及维护。例如测量从库的延时，确定主从是否一致，如何让备库与主库数据一致。

测量从库的延时
最好的解决办法是使用percona-toolkit工具汇总的pt-heartbeat，这是一个在主库上会每秒更新一次的时间戳。pt-heartbeat的工作原理通过使用时间戳方式在主库上更新特定表，然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟。具体流程:
1）在主上创建一张heartbeat表，按照一定的时间频率更新该表的字段（把时间更新进去）。监控操作运行后，heartbeat表能促使主从同步！
2）连接到从库上检查复制的时间记录，和从库的当前系统时间进行比较，得出时间的差异。

确定主从是否一致
pt-table-checksum 是 Percona-Toolkit的组件之一，用于检测MySQL主、从库的数据是否一致。其原理是在主库执行基于statement的sql语句来生成主库数据块的checksum，把相同的sql语句传递到从库执行，并在从库上计算相同数据块的checksum，最后，比较主从库上相同数据块的checksum值，由此判断主从数据是否一致。检测过程根据唯一索引将表按row切分为块（chunk），以为单位计算，可以避免锁表。检测时会自动判断复制延迟、 master的负载， 超过阀值后会自动将检测暂停，减小对线上服务的影响。

如何让主备数据保持一致
上面讲了如何通过pt-table-checksum检查找到了不一致的数据表，那如何同步数据呢? 这时候可以用pt-table-sync:高效的同步MySQL表之间的数据，他可以做单向和双向同步的表数据。他可以同步单个表，也可以同步整个库。它不同步表结构、索引、或任何其他模式对象。所以在修复一致性之前需要保证他们表存在。

如何使用以上的三个工具，可以参考下这篇文章，《percona-toolkit工具（数据一致性监测、延迟监控）使用梳理》，每个步骤都会有详细说明。

复制的问题

由于各种各样的原因，MYSQL的复制并不能很好地从服务器奔溃、掉电、磁盘损坏、内存或网络错误中恢复。下面是在复制过程中常见的问题

日志损坏
主库二进制日志损坏，除了忽略损坏的位置外你别无选择。
从库中继日志损坏，通过最后执行的日志位置(execmaster log pos)找到主库对应的位置然后change master to重新定位。

混合事务类型和非事务类型表
mysql只会回滚事务类型的表，所以非事务类型表的操作有可能未记录在binlog中，导致主从数据不一致。唯一办法是避免使用混合事务和非事务类型表。

备库发生数据改变
为了预防备库发生数据改变，最好的办法是从库提前设置read_only的选项。即使备库数据发生改变，解决办法是重新从主库同步数据。

不唯一的服务器ID和未设置服务器ID
如果不唯一的服务器ID，很容易导致循环复制，从而影响数据一致性。未设置服务器ServerID则复制时会报错。

复制的高级特性

半同步复制

半同步复制在提交过程中增加了一个延迟，在提交事务后，只有在备库收到了该事务的二进制日志才会给客户端进行查询结束的反馈。这会给客户端查询体验增加一些延迟，不过一般不是问题，因为相对于写入硬盘的时间，通过网络传输一些日志的时延不算什么。需要注意的是半同步复制不会阻塞事务的提交，而是阻塞给客户端的反馈（感觉这个用处不是很大，因为不管怎么样如果传输给备库失败那么用这么办法也不会给备库变出日志来）；当备库一直没有回应已收到事件主库会超时并转化成正常的异步复制模式。

总结

首先mysql复制显著的增加了mysql的可用性以及负载能力。但不可避免会有许多风险和问题的出现。建议采用第三方工具很好的帮助解决这些问题，例如Percona Toolkit工具。复制中最重要的确保主从一致，接下来会有几点建议使用复制时需要做什么？

• 使用pt-table-checksum以确定备库是主库的真实拷贝
• 监控复制以确定正在运行并且没有落后于主库
• 理解复制的异步本质，并且设计你的应用避免或容忍从备库中读脏数据
• 写入的服务器最好一个，且备库配置只读。
• 打开以上所讲的安全设置