关于mysql:MySQL主从复制详解

前言：

在 MySQL 中，主从架构应该是最根底、最罕用的一种架构了。后续的读写拆散、多活高可用架构等大多都依赖于主从复制。主从复制也是咱们学习 MySQL 过程中必不可少的一部分，对于主从复制的文章有很多，笔者也来凑凑热闹，写写这方面的内容吧，同时分享下本人的教训和办法。

主从复制（也称 AB 复制）是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据主动复制到从服务器之中。对于多级复制，数据库服务器既可充当主机，也可充当从机。MySQL 默认采纳异步复制形式。

主从复制的过程及原理能够总结如下：

master 服务器将数据的扭转记录二进制 binlog 日志，当 master 上的数据产生扭转时，则将其扭转写入二进制日志中。
slave 服务器会在肯定工夫距离内对 master 二进制日志进行探测其是否产生扭转，如果产生扭转，则开始一个 I /OThread 申请 master 二进制事件。
同时主节点为每个 I / O 线程启动一个 dump 线程，用于向其发送二进制事件，并保留至从节点本地的中继日志中，从节点将启动 SQL 线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致。

基于二进制文件地位的主从复制又能够称为传统复制，即从服务器依赖于主服务器的 binlog 文件地位，当主库产生数据变更时，binlog pos 位点会增长，从库会感应到变动来实现同步。

配置主从复制，咱们首先要筹备至多两台 MySQL 实例，一台充当主服务器、一台充当从服务器。因为主从复制依赖于 binlog，所以主库必须开启 binlog，且主从要配置不同的 server_id，上面具体展现下配置过程：

2.1 确认主从库配置参数

MySQL 主从服务器倡议有如下配置，能够先确认下，如果未配置，则须要批改配置文件而后重启。

# 主库参数配置 要有以下参数
vim /etc/my.cnf 
[mysqld] 
log-bin = binlog  // 启用二进制日志
server-id = 137  // 服务器惟一 ID，默认值是 1，个别设置为 IP 地址的最初一段数字
binlog_format = row //bilog 设置为 row 模式 避免复制出错

# 从库倡议配置以下参数
vim /etc/my.cnf 
[mysqld] 
relay-log = relay-bin
server-id = 138

2.2 确定主库二进制地位，创立同步账号

若主从库都是刚刚初始化实现，且主库无操作时，从库可不必同步主库的数据，间接确定主库的 binlog 地位即可。

# 查看主库 binlog 文件地位
show master status;

# 主库创立同步账号
create user 'repl'@'%' identified by '123456';
grant replication slave on *.* to 'repl'@'%';

若主库曾经运行了一段时间，有业务数据在，而从库刚刚初始化实现，此时则须要备份主库的数据，而后导入从库，使得主从数据统一。

# 主库创立同步账号
create user 'repl'@'%' identified by '123456';
grant replication slave on *.* to 'repl'@'%';

# 全备主库数据
mysqldump -uroot -pxxxx -A -R -E --single-transaction --master-data=2 > all_db.sql

# 从库端复原
mysql -uroot -pxxxx < all_db.sql

# 从备份文件中能够找到主库的 binlog 地位

2.3 进入从库，开启主从复制

找到主库二进制文件地位且实现主从数据统一后，咱们就能够正式开启主从复制了。

# 进入从库 MySQL 命令行 执行 change master 语句连贯主库
# 二进制文件名及 pos 地位由下面步骤取得
CHANGE MASTER TO MASTER_HOST='MySQL 主服务器 IP 地址',
    MASTER_PORT=3306,
    MASTER_USER='repl',
    MASTER_PASSWORD='123456',
    MASTER_LOG_FILE='binlog.000002',
    MASTER_LOG_POS=154;
 
# 开启主从复制 并保持状态
start slave;
show slave status \G // 查看 slave 状态 确保 Slave_IO_Running: Yes Slave_SQL_Running: Yes

GTID 是 MySQL 5.6 的新个性，其全称是 Global Transaction Identifier，可简化 MySQL 的主从切换以及 Failover。GTID 用于在 binlog 中惟一标识一个事务。当事务提交时，MySQL Server 在写 binlog 的时候，会先写一个非凡的 Binlog Event，类型为 GTID_Event，指定下一个事务的 GTID，而后再写事务的 Binlog。

在基于 GTID 的复制中，首先从服务器会通知主服务器曾经在从服务器执行完了哪些事务的 GTID 值，而后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且应用 GTID 的复制能够保障同一个事务只在指定的从库上执行一次，这样能够防止因为偏移量的问题造成数据不统一。也就是说，无论是级联状况，还是一主多从的状况，都能够通过 GTID 主动找地位，而无需像之前那样通过 File_name 和 File_position 找主库 binlog 地位了。

基于 GTID 的主从复制与下面基于二进制文件地位的主从复制搭建步骤相似，同样简略展现下搭建过程：

3.1 确认主从库配置，开启 GTID

# 主库参数配置 要有以下参数
vim /etc/my.cnf 
[mysqld] 
server-id = 137
log-bin = binlog  
binlog_format = row 
gtid-mode = ON // 开启 gtid 模式
enforce-gtid-consistency = ON   // 强制 gtid 一致性，用于保障启动 gitd 后事务的平安 

# 从库倡议配置以下参数
vim /etc/my.cnf 
[mysqld] 
server-id = 138
log-bin = binlog  
binlog_format = row 
gtid-mode = ON 
enforce-gtid-consistency = ON 
relay-log = relay-bin

3.2 创立同步账号，放弃主从库数据统一

若主库刚初始化实现或者主库端保留有全副二进制文件，则从库无需手动同步数据。否则须要手动同步数据使得主从统一。

# 主库创立同步账号
create user 'repl'@'%' identified by '123456';
grant replication slave on *.* to 'repl'@'%';

# 若主库刚初始化或保留有残缺二进制文件 则无需执行上面步骤
# 全备主库数据
mysqldump -uroot -pxxxx -A -R -E --single-transaction  > all_db.sql
# 从库端复原
mysql -uroot -pxxxx < all_db.sql

3.3 进入从库，开启主从复制

# 进入从库 MySQL 命令行 执行 change master 语句连贯主库
CHANGE MASTER TO MASTER_HOST='MySQL 主服务器 IP 地址',
    MASTER_PORT=3306,
    MASTER_USER='repl',
    MASTER_PASSWORD='123456',
    MASTER_AUTO_POSITION = 1;
 
# 开启主从复制 并保持状态
start slave;
show slave status \G

在日常学习及工作过程中，主从复制方面也积攒了一些教训，上面简略分享几点，心愿各位少踩坑。

主从两端数据库版本尽量保持一致。
主从库参数倡议雷同，比方字符集、sql_mode 这类参数要设置一样。
从库服务器性能不能过于落后主库，免得因服务器性能产生主从提早。
所有表强制领有主键，因为无主键表同步到从库极易产生主从提早。
倡议从库设为 read only，以防人为误操作从库数据。
监控主从提早及状态，及时解决同步中断或提早问题。

总结：

本文介绍了主从复制的原理及搭建过程，其实对于主从复制的内容还有很多，须要一直的学习。这里举荐大家应用 GTID 模式来搭建主从复制，对于前面分享的几点教训，也是本人日常积攒的，心愿对你有所帮忙。写作不易，感觉还不错的话，请棘手转发分享下哦。

关于mysql:MySQL主从复制详解

1. 主从复制简介及原理

2. 基于二进制文件地位配置主从复制

3. 基于 GTID 的主从复制

4. 一些教训及倡议