mysql 主从备份原理

mysql 主从备份原理

1.1 用途及条件

mysql主从复制用途

• 实时灾备，用于故障切换
• 读写分离，提供查询服务
• 备份，避免影响业务

主从部署必要条件：

• 主库开启binlog日志（设置log-bin参数）
• 主从server-id不同
• 从库服务器能连通主库

2.1 主从原理

• 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量，主库验证从库，交给主库IO线程负责数据传输;

• 在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接，主库 A 校验完用户名、密码后，开始按照备库 B master.info里传过来的位置，从本地读取 binlog，将binlog文件信息，偏移量和binlog文件名等发给 B

• 从库接收到信息后，将binlog信息保存到relay-bin中，同时更新master.info的偏移量和binlog文件名

• 从库的SQL线程不断的读取relay-bin的信息，同时将读到的偏移量和文件名写道relay-log.info文件，binlog信息写进自己的数据库，一次同步操作完成。

• 完成上次同步后，从库IO线程不断的向主库IO线程要binlog信息

• 从库如果也要做主库，也要打开log_bin 和log-slave-update参数

3.1 主从切换

在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。

在状态 1 中，虽然节点 B 没有被直接访问，但是我依然建议你把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：

• 有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作；
• 防止切换逻辑有 bug，比如切换过程中出现双写，造成主备不一致；
• 可以用 readonly 状态，来判断节点的角色。

有同学想，我把从库设置成只读了，还怎么跟主库保持同步更新呢？这个问题，你不用担心。因为 readonly 设置对超级 (super) 权限用户是无效的，而用于同步更新的线程，就拥有超级权限。

4.1 主从延迟的原因

4.1.1 主从主机的性能不一样

更新请求对 IOPS 的压力，在主库和从库上是无差别的，从的机器性能比主的机器差时，当从库主机上的多个从库都在争抢资源的时候，就可能会导致主从延迟

4.1.2 从的主机读压力较大

我们作了主从读写分离，开发写的代码执行大量读的查询时，对从压力较大，导致从的cpu或者内存占用很高，导致主从延迟，可以一主多从来解决，但是不宜过多，一般3-5个从，过多的从也会导致主从延迟同步

4.1.3 网络原因

主和从的机器不在同一台机房，网络传输数据较慢导致的主从延迟

4.1.4 大事务

主库上必须等事务执行完成才会写入 binlog，再传给备库。所以，如果一个主库上的语句执行 10 分钟，那这个事务很可能就会导致从库延迟 10 分钟