GTID概念

从MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了数据库的主备一致性,故障恢复以及容错能力。

开启GTID的好处

GTID相对于行复制数据安全性更高,故障切换更简单。

  1. 根据 GTID 可以快速的确定事务最初是在哪个实例上提交的。

  2. 简单的实现 failover,不用以前那样在需要找 log_file 和 log_pos。

  3. 更简单的搭建主从复制,确保每个事务只会被执行一次。

  4. 比传统的复制更加安全,一个 GTID 在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致。

  5. GTID是连续的没有空洞的,保证数据的一致性,零丢失

  6. GTID 用来代替classic的复制方法,不再使用 binlog+pos 开启复制。而是使用 master_auto_postion=1 的方式自动匹配 GTID 断点进行复制。

  7. GTID 的引入,让每一个事务在集群事务的海洋中有了秩序,使得 DBA 在运维中做集群变迁时更加方便


故障模拟

下面模拟A库挂掉,程序切换至B库,重新搭建A库并加入同步的过程。

模拟A库挂掉

在A库执行以下代码,搞坏A库的mysql以及数据。我这里使用的是宝塔安装的mysql,所以mysql的安装位置是:/www/server/mysql,数据存放在/www/server/data,需要根据你的实际情况修改。

#结束mysql进程
pkill -9  mysqld
#卸载mysql
rm -rf /www/server/mysql
#删除数据库文件
rm -rf /www/server/data

执行以上语句后,A库的mysql已打不开了,且数据也丢失了。

业务系统切换至B库

修改业务系统的数据库连接地址,改成B库的地址,让业务系统继续运转。

A库重装mysql

修改A库my.cnf

在末尾添加:

[mysqld]
log-bin=mysql-bin
binlog_format=mixed
server-id=1
log-slave-updates
slave-skip-errors=all
binlog-ignore-db=mysql,sys,performance_schema,information_schema
replicate-ignore-db=mysql,sys,performance_schema,information_schema
# 开启gtid
gtid_mode=ON
enforce-gtid-consistency=true

创建同名数据库

在A库创建一个跟B库同名的数据库,最好密码也一致,方便管理。

从B库复制数据到A库

从B库复制数据到A库。由于业务系统已切换到B库,意味着B库的数据随时在变动。后面配置好同步后,A库会自动更新到最新的B库的数据。

创建同步账号

在A库创建同步账号:

CREATE USER slaveuser@'%' IDENTIFIED WITH mysql_native_password BY 'password';
grant replication slave on *.* to slaveuser@'%';
flush privileges;

重启A库mysql

/etc/init.d/mysqld restart

配置同步

在A库上执行:

stop slave;
change master to master_host='B库的地址',master_port=3306,master_user='slaveuser',master_password='abc123456',master_auto_position =  1;
start slave;

在B库上执行:

stop slave;
change master to master_host='A库的地址',master_port=3306,master_user='slaveuser',master_password='abc123456',master_auto_position =  1;
start slave;

检查同步情况。