MySQL主从复制的核心步骤
主库开启binlog并正常记录binlog a、从库启动IO线程 跟主库建立客户端连接 b、主库启动binlog dump线程 读取主库上的binlog event发送给从库的IO线程 c、从库的IO线程获取到binlog event之后将其写入从库 的Relay Log中 d、从库启动SQL线程 将Relay中的数据重放 完成从库的数据更新
查看binlog
查看binlog是否开启
show variables like '%log_bin%'
- log_bin
是否开启binlog
- log_bin_basename
binlog存储文件的完整名称 会默认在文件名后面添加递增的序号 如mysql-bin.000001
- log_bin_index
binlog索引文件名称 如mysql-bin.index
查看所有的binlog文件
show binary logs
文件名称中的序号越大表示日志越新
查看指定binlog内容
show binlog events in 'binlog.000061'
第一行 Event_type=Format_desc 内容为 Server ver: 8.0.18, Binlog ver: 4 表示MySQ版本为8.0.18，Binlog版本是V4
执行SQL操作
# 创建库 CREATE DATABASE pingfanrenbiji DEFAULT CHARACTER SET = utf8mb4; # 创建表 use pingfanrenbiji; CREATE TABLE student (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT); # 插入数据 INSERT INTO `student` (`id`) VALUES (1); INSERT INTO `student` (`id`) VALUES (2);
再次查看binlog
show binlog events in 'binlog.000061' limit 66000,1000
MySQL默认采用自动提交(AUTOCOMMIT)机制 show variables like '%AUTOCOMMIT%';
Relay Log
引入了Relay Log之后 让原本同步的获取事件、重放事件解耦了 两个步骤可以异步的进行 Relay Log充当了缓冲区的作用 Relay Log有一个relay-log.info的文件 用于记录当前复制的进度 下一个事件从什么Pos开始写入 该文件由SQL线程负责更新
复制模型
一主多从
适合少量写、大量读
场景
- 读请求被分到了各个从库上，有效的帮主库分散了压力，能够提升读并发
- 把从库当成一个灾备库，除了主从复制之外，没有其他任何的请求和数据传输
- 也可将其中一个备库作为预发环境的数据库
但涉及到生产环境数据库的数据敏感性
缺点
如果有n个从库 那么主库会有n个binlog dump线程 如果n比较大 可能会造成主库的性能抖动
级联复制
适合从库较多
优势
级联复制的好处在于很大程度上减轻了主库的压力 主库只需要关心与其有直接复制关系的从库 剩下的复制则交给从库即可
劣势
由于是这种层层嵌套的关系 如果在较上层出现了错误 会影响到挂在该服务器下的所有子库 这些错误的影响效果被放大了
主主复制
双主意义在于HA，而不是负载均衡
客户端可以任意写2个主库
劣势
两边的数据冲突的可能性很大 例如复制停止了 系统仍然在向两个主库中写入数据 也就是说一部分数据在A 另一部分的数据在B 但是没有相互复制 且数据也不同步了 要修复这部分数据的难度就会变得相当大
主、被动的主主复制
客户端只能写一个主库 另一个主库是只读的
应用场景
- 不中断服务的前提下 对MySQL进行维护、优化 如修改表结构
假设2个数据库 主动A库和被动B库 a、先停止A库对b库的复制 也就是停掉A上的SQL线程 b、在B上执行非常耗时、可能需要锁表的操作 就不会立即同步到A上来 此时A正对外提供服务 不能使其受到影响 由于采用的是异步的复制模式 所以Relay Log还是继续由I/O线程写入 只是不去进行重放 在B上执行此次的维护操作 "注意"此时A上面发生的更新还是会正常的同步到B来
c、 执行完后交换读写的角色 也就是让A变成只读的被动主库 而B变为主动主库对外提供服务 d、重新开启SQL线程 A开始去对之前Relay Log中积累的event进行重放 虽然A此时可能会阻塞住 但是A已经没有对外提供服务了 所以没有问题
优势
可以在不停止服务的情况下去做数据库的结构更新 其次可以在主库发生故障的情况下 快速的切换，保证数据库的HA
