高性能MySQL笔记(第十章 复制)01

p469 ~ p534. 分为2部分, p469 ~ p501(10.1 ~ 10.4), p501 ~ p534.

概述

• 支持两种复制方式, 基于语句的复制和基于行的复制, 集中5.1之后才有基于行的复制.
• 在同一时刻, 主备无法保证完全一致性, 可能有几秒, 几分钟, 几小时的延迟.
• 一般是一主多从, 主库单写从库读.

复制解决的问题

• 数据分布
• 负载均衡
• 备份
• 高可用和故障切换
• MySQL升级测试

复制流程

• 主库记录数据更改到二进制日志(Binary Log)
• 备库将主库日志复制到自己的中继日志(Relay Log)中
• 备库读取中继日志中的事件, 将其重放到备库中
  

配置复制

步骤如下

1. 在每台服务器上创建复制账号
2. 配置主库和备库
3. 通知备库连接到主库并从主库复制数据.

创建复制账号

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的复制非常灵活, 可以根据需要定制解决方案.