mysql 主从备份原理

mysql主从复制用途

主从部署必要条件：

在备库 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参数

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

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

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

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

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

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

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