p469 ~ p534. 分为2部分, p469 ~ p501(10.1 ~ 10.4), p501 ~ p534.
概述
- 支持两种复制方式, 基于语句的复制和基于行的复制, 集中5.1之后才有基于行的复制.
- 在同一时刻, 主备无法保证完全一致性, 可能有几秒, 几分钟, 几小时的延迟.
- 一般是一主多从, 主库单写从库读.
复制解决的问题
- 数据分布
- 负载均衡
- 备份
- 高可用和故障切换
- MySQL升级测试
复制流程
- 主库记录数据更改到二进制日志(Binary Log)
- 备库将主库日志复制到自己的中继日志(Relay Log)中
- 备库读取中继日志中的事件, 将其重放到备库中
配置复制
步骤如下
- 在每台服务器上创建复制账号
- 配置主库和备库
- 通知备库连接到主库并从主库复制数据.
创建复制账号
grant replication slave, replication client on *.* to repl@'192.168.0.%' identified by 'password';
配置主库和备库
主库修改my.cnf, 如果之前没有设置log_bin, 需要重启MySQL.
log_bin = mysql-bin
server_id = 10
执行查询语句, SHOW Master status;
备库也要增加类似的配置, 也要重启MySQL
log_bin = mysql-bin
server_id=2
relay_log = /var/lib/mysql/mysql-relay-bin
log_slave_updates = 1
read_only = 1
启动复制
设置从库复制.
change master to master_host='106.***',
master_port=**,
master_user='repl',
master_password='***',
master_log_file='mysql-bin.000001',
master_log_pos=0;
执行语句start slave开启复制. 通过执行show slave status可用查看复制的状态, 以及报错信息.
通过执行show processlist, 可以看到有2个线程. 一个I/O线程, 等待master的更新, 一个sql重放线程, 准备读取日志重放到本地数据库.
简单测试了下, 在主库新加了一条数据, 1秒之内, 备库就拿到了这条数据. 速度相当快.
上面的情况是对全新的2台服务器进行复制. 如果是在一台已有的库进行扩展, 这时可以将主库开始二进制日志记录之前的数据进行备份, 再将备份还原到新的备库上.
mysqldump -h localhost -P 3306 -u root -p --database databaseName > databaseName.sql
复制拓扑
基本原则如下:
- 一个MySQL备库只能有一个主库
- 每个备库必须有一个唯一的server_id
- 一个主库可以有多个备库(一个备库可以有多个兄弟备库)
- 如果打开了log_slave_updates选项, 一个备库可以把其主库上的数据变化传播到其他备库.
一主库多备库
少量写, 大量读的情况
主动-主动模式下的主-主复制
包含两台服务器, 每一个都被配置成对方的主库和备库. 问题是如何解决冲突.
主动-被动模式下的主-主复制
同一时间, 一个是主库一个是备库, 然后可以切换. 这个是主流方式.
- 故障转移和故障恢复比较容易
- 可以让你在不关闭服务器的情况下执行维护, 优化表, 升级操作系统(或应用程序, 硬件等)或其他任务.
拥有备库的主-主结构
为每个主库增加一个备库. 增加了冗余. 利于故障转移.
环形复制
环形结构非常脆弱, 应尽量避免
主库, 分发主库以及备库
结构为主库只有一个备库, 然后通过这个备库连接多个兄弟备库去更新数据.
缺点是无法使用一个备库代替主库, 因为由于分发主库的存在, 导致各个备库与原始主库的二进制坐标不相同.
树或金字塔形
类似分发主库.
定制的复制方案
MySQL的复制非常灵活, 可以根据需要定制解决方案.