介绍MySQL数据库的主从复制的实操，操作起来都比较简单。

一、MySQL数据库的主从复制（同步）实操

1.1 准备

1.

注意：这里是两个不同的服务器，装了两个MySQL软件：

• 左边：主库 右边：从库

两边的库，如下：

2.

两边，分别进入MySQL配置文件，都要打开binlog功能：（不是MySQL运行必要，而只是主备传送时必要）

vim /etc/my.cnf;

在配置文件里，加上如下：
log-bin=/var/lib/mysql/mysql-bin
server-id=123454

• 配置binlog的位置
• server-id：在一个集群里边，编号只要不一样就行

3.

两边，都重启MySQL的数据库

systemctl restart mysqld

mysqld：才是MySQL的数据库

mysql：是客户端

1.2 配置主库

1.

左边：给主库加全局读锁：所有事务对主库只能读、不能写。因为要备份主库的数据，然后去从库上还原。因为主备复制，复制的只是binlog日志，只是增量。

FLUSH TABLES WITH READ LOCK;

查看，主库，写到哪一条binlog了：\G是横着的表，竖着看，因为窗口比较窄。

SHOW MASTER STATUS \G;

如下：那么后续备库就会从该文件的该位置194处，开始同步：

因为主库已经加了全局读锁，事务只能读、不能写。就算之前打开了binlog功能，也不会往binlog里面写；

2.

退出MySQL数据库，进入Linux虚拟机：

通过备份工具mysqldump，备份主库的所有数据：因为之前已经直接加读锁了（当前读），所以这里没有用MVCC（历史读）

3.

将上述左边主库的备份文件，传输到右边的从库：

scp dbdump.sql root@192.168.57.146:/root/dbdump.sql

左边主库：释放锁。此时，主库就能随意读写了：

1.3 配置从库

1.

右边从库：进MySQL客户端

执行从主库传输过来的备份文件：

此时，从库的内容，跟主库的内容是不是完全一样？

不是，因为实际业务中主库是会一直有新的事务进来的，所以上述从库是主库的旧版。只是写到了binlog12 的194位置。

2.

查看一下从库的状态。因为怕之前从库已经配置好了同步，即已经是别人的从库：

show slave status \G;

如果从库已经配置好了同步，那么：

• 停止主备复制；stop slave;
• 重置从库;reset slave;------------ 这样该库，就不是任何人的从库了，如下：

3.

给该库，设置指定的主库：

change master to
MASTER_HOST='192.168.57.144',
MASTER_USER='root',
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=194;

已经配置好了，以主库的12号binlog的194位置开始，往后同步：

这里的MASTER_LOG_FILE、MASTER_LOG_POS，目的是：

让从库知道从哪个log、log的哪个位置，开始同步复制。

注意，这里是手动指定的。

4.

开启主备复制；start slave;

查看从库的状态；show slave status \G;

从库的两个线程，正在运行：

以上，就配置好了主从同步。

1.4 试验：主从能否成功同步（没有配置复制同步类型，默认异步）

左右两边，都切到d1的库；

查看该库下数据表Z的内容；

试验：

主库：插入1条数据

从库：看能不能更新过来

查看从库的状态：

主库的binlog在哪个位置，从库的binlog就是同步到哪个位置，即主从同步。

（因为之前配置主从同步的期间，主库是加了全局读锁的。主库加锁前的状态=主库加锁后的持续时间的状态=从库同步的起点）

因为，上述是没有做任何的配置，所以上述的主从同步，是异步的。

即不足：因为主库不知道，binlog日志是否成功抵达备库，所以容易导致丢失数据。

1.5 完善配置：改为半同步的复制（同步）类型

因为半同步的机制，是插件，不是跟着MySQL自动装上的

即：设置红框中的配置项：

• 将下述两个so文件，给load进来：
• 去掉下面的两个井号，

然后，将主从的服务，都重启；

此时，就是半同步的状态。

1.6 参数：两者脱扣的时间

如果超过10秒，两者就会退化成异步；

1.7 查看当前的线程

1.主库

show processlist \G;

2.从库：

会多出两个线程：

• 右边箭头：这个是io线程
• 右边箭头下边：是sql线程，即重放中继日志的线程

二、让主从复制（同步）的配置，更方便

2.1 不方便的地方、改进思路：配置从库时，需要手动配置告诉从库要从主库的哪个binlog开始复制、哪个位置开始复制

本节的1.3部分：配置从库时，需要手动配置告诉从库要从主库的哪个binlog开始复制、哪个位置开始复制；

• 即主库中，每个事务都有1个唯一ID。有点像业务系统中使用UUID。这样从库从哪个binlog开始执行就特别容易区分了

2.2 GTID：给事务分配全局唯一的ID，自动定位

GTID：（Global Transaction Identification）全局的事务ID

• 分两部分：uuid+每个事务流水号
• 每个事务流水号，就代表一个已经执行了的、已持久化的事务

2.3 启用GTID的方式

1.在主库、从库的配置文件中，都加上两项配置

• 打开GTID模式
• 增强GTID的一致性

2.从库中，修改连接主库的信息，重新连接主库

以前：

给该从库，设置指定的主库：

已经配置好了，从主库的12号binlog的194位置开始，往后同步：

change master to
MASTER_HOST='192.168.57.144',
MASTER_USER='root',

MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=194;

现在：

change master to
MASTER_HOST='192.168.57.144',
MASTER_USER='root',

master_auto_position=1;        // 让从库自动的根据GTID，去选取从哪个binlog、哪个位置开始复制

创新的思路：

麻烦易忘的手动--->自动

2.4 实操

1.

在主库、从库的配置文件中：

都加上如下两项，并保存；

重启mysqld数据库；

2.

因为两个库的配置文件都已修改，且各自是已重启、分别正常运行的状态。

那么，此时还需要重新配置从库的主库连接信息：（让从库，重新连接一下，主库）

进入从库的客户端：

• 暂停主备复制（同步）；
• 改变该从库的主库信息

3.

我们怎么知道，是通过GTID的形式进行复制同步的呢？

查看从库slave的状态：

slave：

a person who is the legal property of another and is forced to obey them.

=attachment=appendix

奴隶

三、小结