深入理解MySQL 5.7 GTID系列(八):GTID带来的运维改变

简介: 依托前文的解析来讲5.7中 GTID带来的运维改变,我想理解应该是更加深刻,这节主要讨论以下几个部分: 如何跳过一个事务 mysqldump导出行为的改变 5.7中搭建基于GTID的主从 5.7中GTID的主从的切换 5.7中在线改变GTID模式 一、如何跳过一个事务 和传统基于位置的主从不同,如果从库报错我们需要获得从库执行的最后一个事务,方法有如下: show slave status \G 中的 Executed_Gtid_Set。

依托前文的解析来讲5.7中 GTID带来的运维改变,我想理解应该是更加深刻,这节主要讨论以下几个部分:

8481c8f592b7f349aa84a1de5c171db681516edf 如何跳过一个事务
8481c8f592b7f349aa84a1de5c171db681516edf mysqldump导出行为的改变
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中搭建基于GTID的主从
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中GTID的主从的切换
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中在线改变GTID模式

一、如何跳过一个事务

和传统基于位置的主从不同,如果从库报错我们需要获得从库执行的最后一个事务,方法有如下:

8481c8f592b7f349aa84a1de5c171db681516edf show slave status \G 中的 Executed_Gtid_Set。
8481c8f592b7f349aa84a1de5c171db681516edf show global variables like '%gtid%'; 中的 gtid_executed 。
8481c8f592b7f349aa84a1de5c171db681516edf show master status;中的Executed_Gtid_Set。

然后构建一个空事务如下:

stop slave ;
set gtid_next='4a6f2a67-5d87-11e6-a6bd-000c29a879a3:34';
begin;commit;
set gtid_next='automatic';
start slave ;

如果是多个如下:

stop slave ;
set gtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:3';
begin;commit;
set gtid_next='89dfa8a4-cb13-11e6-b504-000c29a879a3:4';
begin;commit;
set gtid_next='automatic';
start slave ;

二、 mysqldump导出行为的改变

使用mysqldump受到选项set-gtid-purged=AUTO的影响,假如我们在GTID开启和关闭的情况下使用如下语句导出数据:

mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases

在GTID开启的情况下会多如下设置:

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;

--
-- GTID state at the beginning of the backup 
--

SET @@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-105';

为什么要这么设置呢?因为如果做基于GTID的主从,是否生成BINLOG就意味着在导入数据的时候是否基于本地数据库生成新的GTID事务,显然这是不合理的,所以将SQL_LOG_BIN设置为0是必须的。接着GTID_PURGED被设置为备份时刻已经执行过的GTID事务,如前文第五节源码剖析设置GTID_PURGED会设置三个地方的GTID如下:

8481c8f592b7f349aa84a1de5c171db681516edf mysql.gtid_executed表
8481c8f592b7f349aa84a1de5c171db681516edf gtid_purge变量
8481c8f592b7f349aa84a1de5c171db681516edf gtid_executed变量

看起来是合理的,但是如果这里忽略了整个mysql.gtid_executed表是innodb表,导入过程中某些版本(已知percona 5.7.14,5.7.17)会重新删除和建立,因此通过GTID_PURGED设置的mysql.gtid_executed表会重新改变,重启数据库后需要读取mysql.gtid_executed表可能获得错误Gtid集合导致复制错误。这也为我的故障案例埋下了伏笔,案例中在详细描述。
当然也可以使用 --set-gtid-purged=OFF选项来告诉mysqldump不需要加入SQL_LOG_BIN= 0和GTID_PURGED,但是初始化搭建基于GTID的主从一定不要设置为OFF。下面是这个选项的含义。

--set-gtid-purged[=name] 
 Add 'SET @@GLOBAL.GTID_PURGED' to the output. Possible
 values for this option are ON, OFF and AUTO. If ON is
 used and GTIDs are not enabled on the server, an error is
 generated. If OFF is used, this option does nothing. If
 AUTO is used and GTIDs are enabled on the server, 'SET
 @@GLOBAL.GTID_PURGED' is added to the output. If GTIDs
 are disabled, AUTO does nothing. If no value is supplied
 then the default (AUTO) value will be considered.

三、5.7中搭建基于GTID的主从

这里存在一个注意点,也是我案例中会提到的。我们还是直接说步骤

8481c8f592b7f349aa84a1de5c171db681516edf 注意主备库必须开启GTID和设置好server_id
enforce_gtid_consistency = ON
 gtid_mode = ON
 server_id = 9910
 binlog_format = row

同时主备库都开启binlog如果不设置级联从库,从库不要设置log_slave_updates参数。
这是最合理的设置。

8481c8f592b7f349aa84a1de5c171db681516edf 建立复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'test123';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' ;
8481c8f592b7f349aa84a1de5c171db681516edf 导出数据
mysqldump --single-transaction --master-data=2 -R -E --triggers --all-databases > test.sql
8481c8f592b7f349aa84a1de5c171db681516edf 从库导入数据
source即可。
8481c8f592b7f349aa84a1de5c171db681516edf 从库执行reset master语句
这一步主要防止gtid_executed被更改过。这个问题在在percona 5.7.14 5.7.17存在但是在percona 5.7.15 5.7.19又不存在。所以为了安全还是执行下面的两步。
reset master;
8481c8f592b7f349aa84a1de5c171db681516edf 提取GTID_PURGED,并且执行
使用head -n 40 命令可以快速的得到比如我这里的
--
-- GTID state at the beginning of the backup 
--

SET @@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-21';

执行

SET @@GLOBAL.GTID_PURGED='ec9bdd78-a593-11e7-9315-5254008138e4:1-21';

语句即可,完成本部分mysql.gtid_executed表会重构。

8481c8f592b7f349aa84a1de5c171db681516edf 使用MASTER_AUTO_POSITION建立同步
change master to 
master_host='192.168.99.41',
master_user='repl',
master_password='test123',
master_port=3310,
MASTER_AUTO_POSITION = 1;
8481c8f592b7f349aa84a1de5c171db681516edf 启动slave
start slave
四、5.7中GTID的主从的切换

切换中必须要确认从库(新主库)没有做过本地的事务,如果做过,否则切换主库(新从库)需要拉取这一部分的GTID事务,如果这些binlog已经不存在了那么势必会报错。这种情况下还是从建从库吧。那么我们来说正常的切换步骤。

8481c8f592b7f349aa84a1de5c171db681516edf 从库(新主库)
stop slave;
reset slave all;
8481c8f592b7f349aa84a1de5c171db681516edf 主库(新从库)
change master to 
master_host='192.168.99.40',
master_user='repl',
master_password='test123',
master_port=3310,
MASTER_AUTO_POSITION = 1;
start slave;

实际就这么简单,从库(新主库)会生成自己的GTID事务,新主库接受到后执行即可。此时会出现如下有两个server_uuid对应的GTID,如下的gtid_executed

6cca360b1373e6d4ea67bd0741fcb85383cf80d8

总的说来如果要作为的切换的从库,不要在从库本地做任何事务。如果确实要做比如加索引等不影响数据的操作可以是使用如下:

mysql> set sql_log_bin=0;
Query OK, 0 rows affected (0.00 sec)

mysql> create index test_jjj on jjj(id);
Query OK, 0 rows affected (0.42 sec)
Records: 0 Duplicates: 0 Warnings: 0

这样也是不会增加本地GTID的。

五、在线修改GTID模式

这是5.7.6以后实现的功能其主要依赖了我们前面分析的 Previous gtid Event以及参数gtid_mode新加入的2个值。我们具体来看看gitd_mode各个值的含义:

8481c8f592b7f349aa84a1de5c171db681516edf OFF(0): Both new and replicated transactions must be anonymous.(生成的是匿名事务,slave也只能应用匿名事务)
8481c8f592b7f349aa84a1de5c171db681516edf OFF_PERMISSIVE:(1) New transactions are anonymous. Replicated transactions can be either
anonymous or GTID transactions.(生成的是匿名事务,slave可以应用匿名和GTID事务)
8481c8f592b7f349aa84a1de5c171db681516edf ON_PERMISSIVE(2): New transactions are GTID transactions. Replicated transactions can be either
anonymous or GTID transactions.(生成的是GTID事务,slave可以应用匿名和GTID事务)
8481c8f592b7f349aa84a1de5c171db681516edf ON(3): Both new and replicated transactions must be GTID transactions(生成的是GTID事务,slave也只能应用GTID事务)

注意每次修改值必然导致一次binlog的切换,如果发生binlog删除也能够依托 Previous gtid Event快速准确的找到gtid_purged(Gtid_state.lost_gtids)。

在线启动
8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;

确定事务都支持GTID,不会在err log中出现警告如下:
2017-02-26T22:35:24.322055Z 55 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

生成的是匿名事务,slave可以应用匿名和GTID事务

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

生成的是GTID事务,slave可以应用匿名和GTID事务

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行

确定已经没有匿名的事务

SHOW GLOBAL STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';

同时确认从库
Retrieved_Gtid_Set
Executed_Gtid_Set
正常增长

到这一步实际上GTID事务已经开始使用了。

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = ON;
8481c8f592b7f349aa84a1de5c171db681516edf 从库执行
stop slave;
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;
start slave;
8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行

修改配置文件my.cnf,将参数的更改加入到配置文件

在线关闭

8481c8f592b7f349aa84a1de5c171db681516edf 从库执行
stop slave;

记录从库执行状态值

Exec_Master_Log_Pos: 7631438Relay_Master_Log_File: bin_log.000016

执行

CHANGE MASTER TO MASTER_AUTO_POSITION = 0,
MASTER_LOG_FILE = 'bin_log.000016', 
MASTER_LOG_POS = 7631438
start slave;

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

生成的是GTID事务,slave可以应用匿名和GTID事务

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

生成的是匿名事务,slave可以应用匿名和GTID事务

8481c8f592b7f349aa84a1de5c171db681516edf 从库执行

等待从库
Retrieved_Gtid_Set
Executed_Gtid_Set
不再变动。
完成这一步实际上GTID事务已经没有生成和应用了

8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行
SET @@GLOBAL.GTID_MODE = OFF;
8481c8f592b7f349aa84a1de5c171db681516edf 主库/从库执行

修改配置文件my.cnf,将参数的更改加入到配置文件

六、总结

学习完本节至少能够学习到:

8481c8f592b7f349aa84a1de5c171db681516edf 如何跳过一个事务
8481c8f592b7f349aa84a1de5c171db681516edf mysqldump导出行为的改变
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中搭建基于GTID的主从
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中GTID的主从的切换
8481c8f592b7f349aa84a1de5c171db681516edf 5.7中在线改变GTID 模式

关于其他运维可以参考官方文档:

8481c8f592b7f349aa84a1de5c171db681516edf Chapter 18 Replication

原文发布时间为:2018-03-29
本文作者:高鹏(重庆八怪)
本文来自云栖社区合作伙伴“ 老叶茶馆”,了解相关信息可以关注“ 老叶茶馆”微信公众号
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
人工智能 运维 关系型数据库
数据库运维:mysql 数据库迁移方法-mysqldump
本文介绍了MySQL数据库迁移的方法与技巧,重点探讨了数据量大小对迁移方式的影响。对于10GB以下的小型数据库,推荐使用mysqldump进行逻辑导出和source导入;10GB以上可考虑mydumper与myloader工具;100GB以上则建议物理迁移。文中还提供了统计数据库及表空间大小的SQL语句,并讲解了如何使用mysqldump导出存储过程、函数和数据结构。通过结合实际应用场景选择合适的工具与方法,可实现高效的数据迁移。
1746 1
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
2101 2
|
运维 关系型数据库 MySQL
运维|MySQL 数据库被黑,心力交瘁
前一阵有一个测试用的 MySQL 数据库被黑了,删库勒索的那种,这里记录一下事情经过,给自己也敲个警钟。
370 2
|
SQL 运维 关系型数据库
MySQL 运维 SQL 备忘
MySQL 运维 SQL 备忘录
305 1
|
运维 关系型数据库 MySQL
在Linux中,MySQL数据库日常运维中涉及哪些关键任务?
在Linux中,MySQL数据库日常运维中涉及哪些关键任务?
|
数据采集 机器学习/深度学习 人工智能
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
运维人的“福音”?AI 驱动的自动化网络监控到底香不香!
1323 0
|
9月前
|
人工智能 运维 监控
运维安全还能靠“人盯人”?别闹了,聊聊自动化处理的真功夫
运维安全还能靠“人盯人”?别闹了,聊聊自动化处理的真功夫
318 17
|
11月前
|
人工智能 运维 安全
运维老哥的救星?AI 驱动的自动化配置管理新趋势
运维老哥的救星?AI 驱动的自动化配置管理新趋势
457 11
|
机器学习/深度学习 人工智能 运维
运维不背锅,从“自动修锅”开始:AI自动化运维是怎么回事?
运维不背锅,从“自动修锅”开始:AI自动化运维是怎么回事?
739 49
|
12月前
|
运维 Prometheus 监控
系统崩了怪运维?别闹了,你该问问有没有自动化!
系统崩了怪运维?别闹了,你该问问有没有自动化!
332 9

热门文章

最新文章

推荐镜像

更多