详解MySQL主从复制实战 - 基于GTID的复制(mysql如何实现主从复制的具体流程)

发布时间：2024-02-26

推荐整理分享详解MySQL主从复制实战 - 基于GTID的复制(mysql如何实现主从复制的具体流程)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:什么是mysql主从复制,mysql主从复制有什么用,mysql主从复制方式有哪些,mysql主从复制方式有哪些,mysql主从复制有什么用,mysql主从复制原理以及架构,mysql如何实现主从复制的具体流程,mysql主从复制有什么用,内容如对您有帮助，希望把文章链接给更多的朋友！

基于GTID的复制

简介

基于GTID的复制是MySQL 5.6后新增的复制方式.

GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID.

在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致.

而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次.

实战

1、在主库上建立复制账户并授予权限

基于GTID的复制会自动地将没有在从库执行的事务重放, 所以不要在其他从库上建立相同的账号. 如果建立了相同的账户, 有可能造成复制链路的错误.

注意在生产上的密码必须依照相关规范以达到一定的密码强度, 并且规定在从库上的特定网段上才能访问主库.

查看用户

查看授权

2、配置主库服务器

NOTE: 把日志与数据分开是个好习惯, 最好能放到不同的数据分区

enforce_gtid_consistency 强制GTID一致性, 启用后以下命令无法再使用

create table ... select ...

因为实际上是两个独立事件, 所以只能将其拆分先建立表, 然后再把数据插入到表中

create temporary table

事务内部不能创建临时表

同一事务中更新事务表与非事务表(MyISAM)

详解MySQL主从复制实战 - 基于GTID的复制(mysql如何实现主从复制的具体流程)

所以建议选择Innodb作为默认的数据库引擎.

log_slave_updates 该选项在MySQL 5.6版本时基于GTID的复制是必须的, 但是其增大了从服务器的IO负载, 而在MySQL 5.7中该选项已经不是必须项

3、配置从库服务器

master_info_repository 与relay_log_info_repository

在MySQL 5.6.2之前, slave记录的master信息以及slave应用binlog的信息存放在文件中, 即master.info与relay-log.info. 在5.6.2版本之后, 允许记录到table中. 对应的表分别为mysql.slave_master_info与mysql.slave_relay_log_info, 且这两个表均为innodb引擎表.

4、从库数据初始化 - [optional]

先在主库上备份数据

—master-data=2 该选项将当前服务器的binlog的位置和文件名追加到输出文件中(show master status). 如果为1, 将偏移量拼接到CHANGE MASTER 命令. 如果为2, 输出的偏移量信息将会被注释。

--all-databases 因为基于GTID的复制会记录全部的事务, 所以要构建一个完整的dump这个选项是推荐的

常见错误

当从库导入SQL的时候出现

此时进入从库的MySQL Command Line, 使用reset master即可

5、启动基于GTID的复制

现有master@..0.2和slave@..0.3, 并且已经通过mysqldump将数据同步至从库slave中. 现在在从服务器slave上配置复制链路

启动复制

启动成功后查看slave的状态

当Slave_IO_Running, Slave_SQL_Running为YES,