相关链接

MySQL 官网主从复制：https://dev.mysql.com/doc/refman/5.7/en/replication.html

优秀博文：https://blog.csdn.net/yhl_jxy/article/details/112486032

主从形式

  • 一主一从
  • 主主复制
  • 一主多从—扩展系统读取的性能，因为读是在从库读取的；
  • 多主一从—5.7开始支持
  • 联级复制—

img

用途及条件

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

主从部署必要条件：

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

原理

img

105353509.jpg

过程描述

从库生成两个线程，一个 I/O 线程（I/O thread），一个 SQL 线程（SQL thread）；

从库 I/O 线程连接主库发送请求到主库（传 pos，binlog event等参数），主库会生成一个 log dump 线程（dump thread），检查 binlog event，

根据从库要求，将 binlog 发送给 从库 I/O 线程，从库 I/O 线程将 binlog 写入 relay log（中继日志），

从库的 SQL 线程，会读取 relay log 文件中的日志，并解析成具体操作执行，实现主从最终数据一致；

概括

默认 MySQL 异步复制模式下，binlog 不是主库 dump thread 主动传给从库的，是从库 I/O 线程连接主库告诉主库发到什么 pos 的 binglog 给从库，

主库收到后，检查 binlog event，按需发送 binlog 给从库。这样处理是因为可能从库有多个，处理速度和性能不一样，从库根据自身情况

去触发获取 binlog 处理，各个从库互不影响，跟主库保持最终数据一致性

主从复制方式

1、异步复制

异步复制是 MySQL 默认的方式。在异步复制下，主库不会主动的向从库发送 binlog，而是等待从库的 I/O 线程建立连接，

从库 I/O 线程请求主库二进制日志事件（传pos等），然后主库创建dump线程，检查自己的 binlog event，

将对应位置的 binlog 发送给从库 I/O 线程，从库 I/O 线程将接收到的 binlog 写入到 relay log（中继日志） 中，从库开启 SQL 线程从

relay log 中刷入到从库磁盘，完成主从异步复制操作。

img

主库处理用户请求和主从复制是两个完全异步化的过程。

2、同步复制

同步模式则是，主库执行一个事务，那么主库必须等待所有的从库全部执行完事务返回 commit 之后才能给客户端返回成功。

img

主库会直接提交事务，而不是等待所有从库返回之后再提交。MySQL只是延迟了对客户端的返回，并没有延后事务的提交。

同步模式性能会大打折扣，它把客户端的请求和主从复制耦合在了一起，如果有某个从库复制线程执行的慢，那么对客户端的响应也会慢很多。

3、半同步复制

半同步相对于同步的区别在于，同步复制需要等待所有的从库 commit，而半同步只需要一个从库 commit 就可以返回了。

如果超过默认的时间仍然没有从库 commit，就会切换为异步模式再提交。客户端也不会一直去等待了。

img

因为即使后面主库宕机了，也能至少保证有一个从库节点是可以用的，此外还减少了同步时的等待时间。

4、并行复制

MySQL 并行复制

  • 社区版5.6中新增
  • 并行是指从库 SQL 线程负责转发到 多个 worker 线程去处理日志
  • 库级别并行应用 binlog，同一个库数据更改还是串行的(5.7版并行复制基于事务组)，一个事务发送到一个 worker 线程执行

设置

set global slave_parallel_workers=10;

设置 sql 线程数为10。

问题及解决方法

1、主库宕机后，数据可能丢失
半同步复制（解决数据丢失的问题）

2、从库只有一个 sql Thread，主库写压力大，复制很可能延时
并行复制（解决从库复制延迟的问题）

3、第一次搭建主从，数据库不存在问题
这个一般是第一次搭建主从的时候，从库存在的问题。需要从主库把数据复制过去，然后在从库恢复即可