五分钟！搞懂 MySQL主从复制原理,牛批！

在 Master 上， gtid_next 是默认的 AUTOMATIC ,即 GTID 在每次事务提交时自动生成。它从当前已执行的 GTID 集合(即 gtid_executed)中，找一个大于 0 的未使用的最小值作为下个事务 GTID。在实际的更新事务记录之前将 GTID 写入到 Binlog。

在 Slave 上，从 Binlog 先读取到主库的 GTID(即 set gtid_next 记录)，而后执行的事务采用该 GTID。

GTID 的好处

master_auto_position=1

GTID 模式复制局限性

1. 在一个事务里面混合使用引擎，如 Innodb(支持事务)、MyISAM(不支持事务)， 造成多个 GTIDs 和同一个事务相关联出错。

2. CREATE TABLE…..SELECT 不能使用，该语句产生的两个 Event。 在某一情况会使用同一个 GTID(同一个 GTID 在 slave 只能被使用一次)：

• event one：创建表语句 create table

• event two ：插入数据语句 insert

3. CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 不能在事务内使用 (启用了 –enforce-gtid-consistency 参数)。

4. 使用 GTID 复制从库跳过错误时，不支持 sql_slave_skip_counter 参数的语法。

GTID 主从复制实战

1.Master 主数据库上的操作

在 my.cnf 文件中配置 GTID 主从复制

[root@mysql-master ~]# cp /etc/my.cnf /etc/my.cnf.bak

[root@mysql-master ~]# >/etc/my.cnf

[root@mysql-master ~]# cat /etc/my.cnf

[mysqld]

datadir = /var/lib/mysql

socket = /var/lib/mysql/mysql.sock

symbolic-links = 0

log-error = /var/log/mysqld.log

pid-file = /var/run/mysqld/mysqld.pid

#GTID:

server_id = 1

gtid_mode = on

enforce_gtid_consistency = on

#binlog

log_bin = mysql-bin

log-slave-updates = 1

binlog_format = row

sync-master-info = 1

sync_binlog = 1

#relay log

skip_slave_start = 1

配置后，重启 MySQL 服务：

[root@mysql-master ~]# systemctl restart mysqld

登录 MySQL，并查看 Master 状态， 发现多了一项 Executed_Gtid_Set ：

mysql> show master status;

±------------------±---------±-------------±-----------------±------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

±------------------±---------±-------------±-----------------±------------------+

| mysql-bin.000001 | 154 | | | |

±------------------±---------±-------------±-----------------±------------------+

1 row in set (0.00 sec)

mysql> show global variables like ‘%uuid%’;

±--------------±-------------------------------------+

| Variable_name | Value |

±--------------±-------------------------------------+

| server_uuid | 317e2aad-1565-11e9-9c2e-005056ac6820 |

±--------------±-------------------------------------+

1 row in set (0.00 sec)

查看确认 GTID 功能打开:

mysql> show global variables like ‘%gtid%’;

±---------------------------------±------+

| Variable_name | Value |

±---------------------------------±------+

| binlog_gtid_simple_recovery | ON |

| enforce_gtid_consistency | ON |

| gtid_executed | |

| gtid_executed_compression_period | 1000 |

| gtid_mode | ON |

| gtid_owned | |

| gtid_purged | |

| session_track_gtids | OFF |

±---------------------------------±------+

8 rows in set (0.00 sec)

查看确认 Binlog 日志功能打开:

mysql> show variables like ‘log_bin’;

±--------------±------+

| Variable_name | Value |

±--------------±------+

| log_bin | ON |

±--------------±------+

1 row in set (0.00 sec)

授权 slave 复制用户，并刷新权限:

mysql> flush privileges;

Query OK, 0 rows affected (0.04 sec)

mysql> show grants for slave@‘172.23.3.66’;

±------------------------------------------------------------------------------+

| Grants for slave@172.23.3.66 |

±------------------------------------------------------------------------------+

| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO ‘slave’@‘172.23.3.66’ |

±------------------------------------------------------------------------------+

1 row in set (0.00 sec)

再次查看 master 状态:

mysql> show master status;

±------------------±---------±-------------±-----------------±-----------------------------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

±------------------±---------±-------------±-----------------±-----------------------------------------+

| mysql-bin.000001 | 622 | | | 317e2aad-1565-11e9-9c2e-005056ac6820:1-2 |

±------------------±---------±-------------±-----------------±-----------------------------------------+

1 row in set (0.00 sec)

这里需要注意一下：

启动配置之前，同样需要对从服务器进行初始化。对从服务器初始化的方法基本和基于日志点是相同的，只不过在启动了 GTID 模式后，在备份中所记录的就不是备份时的二进制日志文件名和偏移量了，而是记录的是备份时最后的 GTID 值。

需要先在主数据库机器上把目标库备份一下，假设这里目标库是 slave_test：

mysql> CREATE DATABASE slave_test CHARACTER SET utf8 COLLATE utf8_general_ci;

Query OK, 1 row affected (0.02 sec)

mysql> use slave_test;

Database changed

mysql> create table user (id int(10) PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);

Query OK, 0 rows affected (0.27 sec)

mysql> insert into slave_test.user values(1,“xiaoming”),(2,“xiaohong”),(3,“xiaolv”);

Query OK, 3 rows affected (0.06 sec)

Records: 3 Duplicates: 0 Warnings: 0

mysql> select * from slave_test.user;

±—±---------+

| id | name |

±—±---------+

| 1 | xiaoming |

| 2 | xiaohong |

| 3 | xiaolv |

±—±---------+

3 rows in set (0.00 sec)

把 slave_test 库备份出来:

[root@mysql-master ~]# mysqldump --single-transaction --master-data=2 --triggers --routines --databases slave_test -uroot -p123456 > /root/user.sql

这里有个版本上的问题：

MySQL 5.6 使用 mysqldump 备份时，指定备份的具体库，使用 --database 。

MySQL 5.7 使用 mysqldump 备份时，指定备份的具体库，使用 --databases。

然后把备份的 /root/user.sql 文件拷贝到 slave 从数据库服务器上。

[root@mysql-master ~]# rsync -e “ssh -p20” -avpgolr /root/user.sql

到这里主库的操作结束，包含 GTID 的备份数据已经 copy 到从库，下面来进行从库的操作。

2.从库操作

在 my.cnf 文件中配置 GTID 主从复制

与主服务器配置大概一致，除了 server_id 不一致外，从服务器还可以在配置文件里面添加 read_only＝on ，使从服务器只能进行读取操作，此参数对超级用户无效，并且不会影响从服务器的复制。

[root@mysql-slave1 ~]# >/etc/my.cnf

[root@mysql-slave1 ~]# vim /etc/my.cnf

[mysqld]

datadir = /var/lib/mysql

socket = /var/lib/mysql/mysql.sock

symbolic-links = 0

log-error = /var/log/mysqld.log

pid-file = /var/run/mysqld/mysqld.pid

#GTID:

server_id = 2

gtid_mode = on

enforce_gtid_consistency = on

#binlog

log_bin = mysql-bin

log-slave-updates = 1

binlog_format = row

sync-master-info = 1

sync_binlog = 1

#relay log

skip_slave_start = 1

read_only = on

配置完成后，重启mysql服务。

[root@mysql-slave1 ~]# systemctl restart mysql

接着将主数据库目标库的备份数据 user.sql 导入到从数据库里。

[root@mysql-slave1 ~]# ls /root/user.sql

/root/user.sql

[root@mysql-slave1 ~]# mysql -p123456

…

mysql> show databases;

±-------------------+

| Database |

±-------------------+

| information_schema |

| mysql |

| performance_schema |

| sys |

±-------------------+

4 rows in set (0.00 sec)

mysql> source /root/user.sql;

mysql> select * from slave.test;

±—±---------+

| id | name |

±—±---------+

| 1 | xiaoming |

| 2 | xiaohong |

| 3 | xiaolv |

±—±---------+

3 rows in set (0.00 sec)

在从数据库里，使用 change master 配置主从复制:

mysql> stop slave;

Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> change master to master_host=‘172.23.3.66’,master_user=‘slave1’,master_password=‘123456’,master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.26 sec)

mysql> start slave;

Query OK, 0 rows affected (0.02 sec)

mysql> show slave status \G;

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 172.23.3.66

Master_User: slave1

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000001

Read_Master_Log_Pos: 1357

Relay_Log_File: mysql-slave1-relay-bin.000002

Relay_Log_Pos: 417

Relay_Master_Log_File: mysql-bin.000001

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

…

…

Executed_Gtid_Set: 317e2aad-1565-11e9-9c2e-005056ac6820:1-5

Auto_Position: 1

由此，Master 和 Slave 节点已经配置了主从同步关系。接下来你可以自行在主库插入一条数据观察从库是否同步过来。

使用 GTID 添加从库有两种方式

直接同步主库所有GTID

如果主库一开始就开启了 GTID，那么可以直接获取主库的所有GTID来同步至从库。但是如果主库 Binlog 日志太多，那么相应同步的时间也会变长。这种方式适用于小数据量的同步。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Java）

Kafka实战笔记

关于这份笔记，为了不影响大家的阅读体验，我只能在文章中展示部分的章节内容和核心截图

• Kafka入门
• 为什么选择Kafka
• Karka的安装、管理和配置

• Kafka的集群
• 第一个Kafka程序
• 

afka的生产者

• Kafka的消费者
• 深入理解Kafka
• 可靠的数据传递

• Spring和Kalka的整合
• Sprinboot和Kafka的整合
• Kafka实战之削峰填谷
• 数据管道和流式处理(了解即可)

• Kafka实战之削峰填谷

了不影响大家的阅读体验，我只能在文章中展示部分的章节内容和核心截图**

[外链图片转存中…(img-GQGJgiNY-1710408789586)]

• Kafka入门
• 为什么选择Kafka
• Karka的安装、管理和配置

[外链图片转存中…(img-SqXFz7HJ-1710408789587)]

• Kafka的集群
• 第一个Kafka程序
• [外链图片转存中…(img-lZfiZMaZ-1710408789587)]

afka的生产者

[外链图片转存中…(img-oBJEnhfG-1710408789587)]

• Kafka的消费者
• 深入理解Kafka
• 可靠的数据传递

[外链图片转存中…(img-TAnk2lO4-1710408789587)]

[外链图片转存中…(img-CDL1S3Cp-1710408789588)]

• Spring和Kalka的整合
• Sprinboot和Kafka的整合
• Kafka实战之削峰填谷
• 数据管道和流式处理(了解即可)

[外链图片转存中…(img-awrP3oZf-1710408789588)]

• Kafka实战之削峰填谷

[外链图片转存中…(img-Exit8GLk-1710408789588)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录