在线建立或重做mysql主从复制架构方法（传统模式和GTID模式）【转】

时间：2023-03-09 18:41:50
在线建立或重做mysql主从复制架构方法（传统模式和GTID模式）【转】

mysql主从复制架构,是mysql数据库主要特色之一，绝大多数公司都有用到。

而GTID模式是基于事务的复制模式的意思，发展到现在也是越来越多人用。

以前很多文章，介绍搭建mysql主从复制架构，是需要停止应用服务来做的,对于生产环境，怎么可能让你随便停服务？所以必须做到在线做,不影响业务,那才是最实际的。

先说明,案例分两种方案,实现的意义是一样的,一种是mysqldump方式,一种是xtrabackup方式,视乎实际情况,因为有些业务不一定能用xtrabackup，例如阿里云RDS，腾讯CDB.

一、GTID的概述：

1、全局事物标识：global transaction identifieds。

2、GTID事物是全局唯一性的，且一个事务对应一个GTID。

3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。

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

5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。

6、在传统的slave端，binlog是不用开启的，但是在GTID中，slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。

二、GTID的组成部分：

前面是server_uuid：后面是一个序列号

例如：server_uuid：sequence number

7800a22c-95ae-11e4-983d-080027de205a:10

UUID：每个mysql实例的唯一ID，由于会传递到slave，所以也可以理解为源ID。

Sequence number：在每台MySQL服务器上都是从1开始自增长的序列，一个数值对应一个事务。

三、GTID比传统复制的优势：

1、更简单的实现failover，不用以前那样在需要找log_file和log_Pos。

2、更简单的搭建主从复制。

3、比传统复制更加安全。

4、GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

四、GTID的工作原理：

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

要点：

1、slave在接受master的binlog时，会校验master的GTID是否已经执行过（一个服务器只能执行一次）。

2、为了保证主从数据的一致性，多线程只能同时执行一个GTID。

配置和授权(通用前置步骤）

如果没有开GTID模式,主从库不用做些什么特别配置,主从之间注意server-id不要一样就可以了,这个坑很容易掉进去.

当然了,binlog是必须开的,主从就靠这个来复制的,不开就是白搭.

还有binlog_format推荐用row,原则上mixed也没啥大问题,但是很多情况下实际上都会自动转成row模式的，而且row模式是三种模式中，最少可能丢数据的模式，即使丢数据也是极个别的极端情况，例如断网.

事务隔离界别transaction_isolation推荐REPEATABLE-READ或READ-COMMITTED都可以，视乎你对数据一致性要求高不高，但不代表那种会数据不准确.

========================================

开启GTID模式,那就要设置下面两个参数,而且一做就要全做，各主从服务器都要做，并需要重启mysql服务才能生效

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#这个不能在线开启，要写到配置文件my.cnf里面,还要重启才生效。
#不然就是下面的报错
mysql> set gtid_mode = 1;
ERROR 1238 (HY000): Variable 'gtid_mode' is a read only variable
#所以我们要编辑my.cnf来开启
vim my.cnf
#GTID模式,5.6的新功能,新的复制验证方式,需要就打开,binlog建议改成row
gtid_mode = on
binlog_format = row
#强制GTID的一致性,一般和上面参数一起使用,但是开启后只允许能够保障事务安全，并且能够被日志记录的SQL语句被执行，
#像create table ... select 和 create temporarytable语句，以及同时更新事务表和非事务表的SQL语句或事务都不允许执行。
enforce_gtid_consistency = 1
#然后重启mysql进程
service mysqld restart

扩展一下,在gtid模式下,出现不支持的语句需要自己去修改,不然会报错或不记录,例如下面这样.

1
2
3
4
CREATE TABLE ... SELECT
可以改为下面这样分成两句:
CREATE TABLE
INSERT ... SELECT

因为GTID模式要重启才能生效,对于一些大库要慎重更改使用gtid(重启失败那就悲剧了),一定要用的话,主库要找个月黑风高,夜深人静的时候设置完再重启,从库就没所谓啦.

==========================================

然后我们还要关注一些参数，在从库可以选择性开启，主库加不加都不影响使用，

1
2
3
4
5
6
7
8
9
#用来配置从服务器的更新是否写入二进制日志,如果有层级从库就必须开,没有的话建议关闭,能有效提高性能
log_slave_updates
#设置从库SQL线程并行重放events(事务)的worker线程数量,默认值为0，最大值为1024.在5.6.x版本中设置这个参数大于0时，
#则SQL线程充当worker线程的协调者，在多个worker线程之间分发基于库级别的events,也就是库级别并行复制，
#5.7.x版本的并行复制可以设置基于组提交事务的并行复制,更加好用.
slave_parallel_workers = 8
#5.7新参数，指定并行复制方式，为了兼容5.6的模式，默认的并行复制方式是基于库级别的，即默认值是：DATABASE，
#我们要设置成5.7支持的基于组提交事务的并行复制方式，则需要设置成：LOGICAL_CLOCK，速度更快。
#slave_parallel_type = LOGICAL_CLOCK

题外话，这个看需求来开启,有个别从库会再搭从库来挂载,如果不开这个参数,那就做不了,如果没有这种需求,不开也没什么,反而增加性能.

配置修改完了,我还还需要在主库授权一下主从复制用户的权限,这里说的授权是指主库对从库授权读写binlog权限.

1
mysql>grant replication slave on *.* to 'rep'@'%' identified by 'password';

因为我贪方便,直接用的root用户,后面请见谅了.

mysqldump方式

因为mysql自带,不需要再做些什么,比较方便易用,不过需要强调一下,数据量太大的话,mysqldump就略显不足了,因为是逻辑备份和导入，导出导入时间耗费巨大,各位自己衡量.

第一步,数据的导出与导入和初始化从库（以下操作，先在主库操作，后在从库操作）

导出和导入,如果库太大,就会多花点时间,也正如我们开头说的,先用的是mysqldump来,具体参数我就不多说了,有兴趣就去查一下,直接看命令就好了.

首先，我们先从主库备份个整库备份：

1
mysqldump -uroot -p123123 --opt --default-character-set=utf8 --triggers -R --hex-blob --single-transaction --no-autocommit --master-data=2 -A >test2.sql

就这样,我们就得到全库备份文件test2.sql,

对于有没有必要做全库备份的问题,要看实际情况,如果你是做MHA,PXC之类的集群,你必然要保持主从数据完全一致,不只是业务库,系统库也需要.如果你从库一开始就不打算拿来用,那确实只操作业务库就好了,还有其他什么忽略不需要复制到从库的参数,这个按你需求实际情况来做,这里就不再细说了.

需要强调一下的是,为什么能做到在线建立和重做主从,就是因为这个参数,

--master-data=2

后面会详细说说这个参数会有些什么特别的地方.

转回正题,备份做完了,那就是要拷到从库恢复了,怎么传输过去,这里就不细说了,什么scp,rsync,http,ftp什么的,你喜欢就好了,而我这里,用的是scp

1
scp -o StrictHostKeyChecking=no root@10.0.2.6:/data/ttt/test2.sql /data/ttt

命令仅供参考,你们自己喜欢怎么改都行

再然后,要初始化一下从库的mysql。

虽然说现在是测试,不过一般来说,建立和重做主从,必然是因为他本来就是空白机,或者是主从失效了,需要重做,原因我不说了,反正类似pt-osc工具也没用的,就是必须重做的架势,至于怎么安装mysql我就不多说了.

简单说说怎么初始化,具体可以看我另一篇文章

1
2
3
4
5
6
7
#这个只是5.6的初始化方式
service mysqld stop
rm -rf /data/mysql/data/*
/usr/local/mysql/scripts/mysql_install_db --defaults-file=/usr/local/mysql/my.cnf --basedir=/usr/local/mysql/ --datadir=/data/mysql/data --user=mysql > /dev/null 2>&1
service mysqld start
/usr/local/mysql/bin/mysqladmin -u root password '123123'
#5.7的和这个不一样,请看我另一篇文章

简单几个命令就完成了初始化,然后准备导入,为什么要说准备呢,当然是因为还有些准备工作,例如是如果要开GTID的话

1
2
3
4
5
6
7
8
9
10
11
12
13
#使用GTID模式的实例的导入,需要目标实例的GTID记录是空的,不然会报错,就类似这样:
[root@pingtest1 ttt]# mysql -uroot -p123123 < test2.sql 
Warning: Using a password on the command line interface can be insecure.
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
#提示GTID_EXECUTED为非空,不能导入.
#所以导入前要先重置下binlog
mysql>reset master;
#重置了binlog那就没问题了,重新执行
mysql -uroot -p123123 -e 'reset master'
mysql -uroot -p123123 < test2.sql
#好了,导入完成后,我们检查一下,gtid模式要看看这个
mysql>show variables like "%gtid%";
gtid_purged    |    16fdabc7-30f9-11e6-9234-0800273e5680:1-3216

看到上面这个就行了.

第二步,配置主从同步（以下操作，都是在从库操作）

在说怎么配置之前,我先说一下为什么能在线不停应用服务来做主从的原因,还记得我上面说的那个参数吗?,没错,就是--master-data=2,意思是记录备份当前的binlog信息.

有不少人以前做主从,都是从主库show master status查看binlog位置,然后change master to.....所以必须把应用服务停了,不然binlog位置变了后,在做主从期间中间那些语句就执行不了,最终导致数据不同步.

而加了--master-data=2之后,test2.sql这个文件会记录当前binlog的位置,这样我们就不用理会做主从期间中间的那些数据,只需要把binlog位置直接指向sql文件里面的binlog位置就可以了,然后数据就会自己同步到最新位置.

来看看我的test2.sql的binlog位置,就文件的前30行,要是你觉得文件太大很难打开,more或者head -30都可以,就不要vim了,只看关键字

1
2
3
4
5
SET @@GLOBAL.GTID_PURGED='16fdabc7-30f9-11e6-9234-0800273e5680:1-3216';
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000019', MASTER_LOG_POS=1856541;

看到了,当前binlog位置是mysql-bin.000019,Position位置是1856541,gtid位置是16fdabc7-30f9-11e6-9234-0800273e5680:1-3216.

知道了这些信息,那么我们就可以开干了

一般模式直接change master to就可以了,主要就是mysql-bin.000019和Position位置是1856541,用来告诉主库,我这些语句执行过了,不需要理会GTID的东西(其实主库没开GTID就不会存在这个数据)

1
2
3
4
5
6
7
8
9
10
#做之前，别忘记先清空一下主从结构的记录
mysql>reset slave all;
#然后再执行操作
mysql>change master to
master_host='10.0.2.6',
master_user='repl',
master_password='*****',
master_port=3306,
master_log_file='mysql-bin.000019',
master_log_pos=1856541;

====================================

GTID模式下,则还需要多做一步,就是执行那个语句,设置gtid编号,用来告诉主库,我这些语句执行过了,

1
mysql>SET @@GLOBAL.GTID_PURGED='16fdabc7-30f9-11e6-9234-0800273e5680:1-3216';

就是跳过之前已经复制过的事务,因为GTID记录的事务是从1开始的,只会增加或变更UUID,不会重置计数器,所以就要手动设置跳过之前执行过(已经在备份里的结果)的事务.然后change master to一下,

1
2
3
4
5
6
7
8
9
#做之前，别忘记先清空一下主从结构的记录
mysql>reset slave all;
#然后再执行操作
mysql>change master to
master_host='10.0.2.6',
master_user='root',
master_password='123123',
master_port=3306,
MASTER_AUTO_POSITION = 1;

在这一步GTID简单很多,这也是为什么越来越多人用的原因,已经不用理会pos跑到哪里,他会自己去找.

要注意的是,主库开了GTID复制模式,从库就用不了旧的模式来做复制了,会提示报错,所以从库必须也使用GTID模式来做从库才可以.

======================================

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
然后启动从库复制
mysql>start slave;
最后检查一下
mysql>show slave status\G
          Master_Log_File: mysql-bin.000019
          Read_Master_Log_Pos: 4980238
               Relay_Log_File: pingtest1-relay-bin.000002
                Relay_Log_Pos: 3124105
        Relay_Master_Log_File: mysql-bin.000019
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    .
                    .
                    .
          Exec_Master_Log_Pos: 4980238
                    .
                    .
                    .
        Retrieved_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:3217-4885
            Executed_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:1-4885

如何证明主从复制正常了呢？主要看下面这些值：

Slave_IO_Running和Slave_SQL_Running的双yes：    证明io线程和sql线程都正常，如果不是双yes，这个主从复制架构就是失败的，不能使用。

Master_Log_File=Relay_Master_Log_File：     证明从库执行的binlog文件和主库的是一致的，不一致就是不同步了，有一定延时，但还可以用，关键看你能不能接受这个延时（跨binlog文件一般算比较大的延时了）。
Read_Master_Log_Pos=Exec_Master_Log_Pos：    证明从库执行binlog的pos位置是和主库一致的，如果是操作太频繁的库，有一些不一致是正常的，如果太大，就代表数据有延时，但不影响从库使用。

Seconds_Behind_Master：    表示slave上SQL
thread与IO
thread之间的延迟，也就是看到还有多少数据还没写进去。在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO
thread），然后通过SQL
thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被执行完的那部分的差值。

因为我数据比较少,很容易就追上了,看不到差异,但是可以很肯定和你们说,我主库没停过应用服务,然后从库就做好了。

再看看主库上面的线程如何

1
2
mysql>show processlist;
9172 | root  | 10.0.2.5:57506  | NULL | Binlog Dump GTID |   75 | Master has sent all binlog to slave; waiting for binlog to be updated

线程也在,可以确定整套复制都正常了.

xtrabackup方式

也正如我开头说的,某些库很大,几十G几百G什么的也不用很意外,如果还用mysqldump就不科学了,导出导入耗费时间巨大,这个时候就必须靠xtrabackup这种物理拷贝的备份还原工具,加快速度进行,另一方面来说,从备份原理得出的结果来看,mysqldump备份得到的结果是备份开始时间的数据结果,而xtrabackup备份得到的结果是备份结束时间的数据结果,是属于比较新的数据,对于操作频繁的库用xtrabackup来做也是优势明显.

第一步目的和上面一致,只是用了软件,而用xtrabackup恢复不需要初始化mysql（以下操作，先在主库操作，后在从库操作）

至于怎么安装xtrabackup就不多说了,各位可以看我另一篇文章,介绍怎么安装xtrabackup和介绍怎么使用xtrabackup,命令我就简单贴出来,然后说一下用途就算了.

先在主库备份全库(想只备份特定库的还请自己想办法,这里就不延伸了)

1
innobackupex --defaults-file="/usr/local/mysql/my.cnf"  --user=root --password='123123' --stream=tar  "/data/ttt" 2> /data/ttt/backup.log | gzip > /data/ttt/test2.tgz

意思就是把/usr/local/mysql/my.cnf配置文件里标明的全库拷贝出来,并通过gzip压缩成一个文件.

拷贝到从库机器

1
scp  -o StrictHostKeyChecking=no root@10.0.2.6:/data/ttt/test2.tgz ./

然后在从库服务器操作，拷贝到一个文件夹解压

1
2
3
4
mkdir test2back
mv test2.tgz test2back/
cd test2back/
tar xf test2.tgz

在从库开始恢复备份

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#关闭mysql服务
/etc/init.d/mysqld stop
#先删了旧的数据文件
rm -rf /data/mysql/data/*
#然后先apply-log
innobackupex --defaults-file='/usr/local/mysql/my.cnf' --apply-log /data/ttt/test2back/
#然后开始恢复
innobackupex --defaults-file='/usr/local/mysql/my.cnf' --copy-back /data/ttt/test2back/
#恢复完成后看一下,做完收尾工作
ll /data/mysql/data
chown -R mysql.mysql data/
#启动mysql服务
/etc/init.d/mysqld start
#尝试登陆一下,ok就完成了
mysql -uroot -p123123

相对来说,速度快了一些,操作也还是简单一些,就是多安装了一个软件.

第二步,配置主从同步（以下操作，都是在从库操作）

实际上和上面用mysqldump的思维是一样,因为xtrabackup备份完成时会生成一个文件xtrabackup_binlog_info,里面就记录了binlog位置和GTID值,故而也能做到不停应用服务来做主从,而且用xtrabackup数据还比较新.

我们来打开这个文件看一下

1
2
vim xtrabackup_binlog_info
mysql-bin.000020        8454162 16fdabc7-30f9-11e6-9234-0800273e5680:1-22037

非常直观,就这三个值,如果你还有兴趣留意,其实xtrabackup_info也有记录，不过两者还是有一些差异.

大多数时候用xtrabackup_binlog_info就可以了，但是特殊情况下用xtrabackup_binlog_pos_innodb会好一些，因为xtrabackup_binlog_info中记录的位置包含非innodb引擎的数据变化位置，但是对于innodb引擎，redo
log里边本身是包含了binlog pos的，如果你apply
log，那么事务的前滚，回滚可能造成这个位置有变动，如果你是做主备复制，复制搭建之后，同步的数据包含非innodb表，那这个xtrabackup_binlog_pos_innodb中的位置就不可靠，反之如果你的同步不涉及到非innodb表，那么可以使用它。

也正如我上面第二步说的,备份恢复完之后,这个从库就可以用了,设置的方法也和上面mysqldump没差别,如果是非GTID的话,直接change master to 就可以用了,

1
2
3
4
5
6
7
8
9
10
#做之前，别忘记先清空一下主从结构的记录
mysql>reset slave all;
#然后再执行操作
mysql>change master to
master_host='10.0.2.6',
master_user='repl',
master_password='*****',
master_port=3306,
master_log_file='mysql-bin.000020',
master_log_pos=8454162;

==========================================

如果是GTID模式的话,那就先set一下,跳过之前已经执行过的事务

1
mysql>SET @@GLOBAL.GTID_PURGED='16fdabc7-30f9-11e6-9234-0800273e5680:1-22037';

然后看一下状态

1
2
mysql> show variables like '%gtid%';
gtid_purged                     | 16fdabc7-30f9-11e6-9234-0800273e5680:1-22037 |

再执行change master to 来完成

1
2
3
4
5
6
7
8
9
#做之前，别忘记先清空一下主从结构的记录
mysql>reset slave all;
#然后再执行操作
mysql>change master to
master_host='10.0.2.6',
master_user='root',
master_password='123123',
master_port=3306,
MASTER_AUTO_POSITION = 1;

==========================================

然后启动从库复制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
mysql>start slave;
最后检查一下
mysql>show slave status\G
          Master_Log_File: mysql-bin.000020
          Read_Master_Log_Pos: 4980238
               Relay_Log_File: pingtest1-relay-bin.000002
                Relay_Log_Pos: 17522575
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
                    .
                    .
                    .
          Exec_Master_Log_Pos: 17522575
                    .
                    .
                    .
        Retrieved_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:22038-26950
            Executed_Gtid_Set: 16fdabc7-30f9-11e6-9234-0800273e5680:1-26950

如何证明主从复制正常了呢？主要看下面这些值：

Slave_IO_Running和Slave_SQL_Running的双yes：    证明io线程和sql线程都正常，如果不是双yes，这个主从复制架构就是失败的，不能使用。

Master_Log_File=Relay_Master_Log_File：     证明从库执行的binlog文件和主库的是一致的，不一致就是不同步了，有一定延时，但还可以用，关键看你能不能接受这个延时（跨binlog文件一般算比较大的延时了）。
Read_Master_Log_Pos=Exec_Master_Log_Pos：    证明从库执行binlog的pos位置是和主库一致的，如果是操作太频繁的库，有一些不一致是正常的，如果太大，就代表数据有延时，但不影响从库使用。

Seconds_Behind_Master：    表示slave上SQL
thread与IO
thread之间的延迟，也就是看到还有多少数据还没写进去。在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO
thread），然后通过SQL
thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被执行完的那部分的差值。

还是太快,看不到差异,不过可以肯定复制是完成了,主从架构完成,主库依然没有停过.

再看看主库上面的线程如何

1
2
mysql>show processlist;
32718 | root  | 10.0.2.5:54224  | NULL | Binlog Dump GTID |   162 | Master has sent all binlog to slave; waiting for binlog to be updated

线程也在,可以确定整套复制都正常了.

扩展阅读：

说起了主从复制延时，就不得不强调，一般的主从复制，是属于异步复制的，即主库不需要理会从库是否执行，或者知否追得上复制的速度，只管自己跑，如果有漏了什么也是不管的，这也是我们常说的主从不一致的根本原因。

为了解决这个问题，就有了半同步复制，和完全同步复制的概念。

半同步的意思是一个事务在主库执行完还不行，必须在至少一个从库成功写入数据，事务才算真正提交成功，而其他还没写入的从库则执行异步操作，后续再写入。这时主库不能再把从库状态弃之不顾，必须知道至少一个从库写入成功才能完成，减少复制失败的事情，但风险还有一些，因为还有一些异步复制的从库。

完全同步就更加严格，要所有从库返回写入成功，这个事务才能算提交成功，严格来说，只有一台从库的半同步架构，也和完全同步的概念相等。

实现半同步的方式很简单，mysql有自带半同步插件，只是一般没有使用，我的另一篇文章有说明，配置起来也不难。

实现完全同步方式则大多数是靠集群软件实现，例如很出名的PXC集群软件，必须所有主从都要写入成功，事务才算提交完成。

但是论性能，半同步和完全同步，必然会比异步降低得很明显，数据一致性要求和系统性能，永远都是背道而驰。

问题汇总:

有些朋友做的从库,可能有一种情况,就是除同步账户外,本身并不知道主库的其他用户密码,这就造成一种尴尬的情况,如果需要管理从库的时候,就显得很不方便,所以逼着要去破解从库的密码.

还有另一种情况,就是主库和从库版本不一致,数据表结构可能会有一些版本造成的差异,如果主库这些表有更改,就会在从库报错,算是一个隐性坑,所以我们最好忽略这些表或库的同步语句.

1.   先来看怎么破解密码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#先关闭mysql
service mysqld stop
#进入安全模式
/usr/local/mysql/bin/mysqld_safe --skip-grant-tables --skip-networking&
#此时就免密码登陆了
/usr/local/mysql/bin/mysql -uroot
#更改密码，密码和用户可选，
#这是5.6及之前的方式
update mysql.user set password=PASSWORD('新密码') where user='root' and host='root' or host='localhost'or host='localhost.localdomain'or host='127.0.0.1';
#5.7之后要用新的字段
update mysql.user set authentication_string=password('新密码') where user='root'
#刷新策略
flush privileges;
#重启mysql
/etc/init.d/mysqld restart
#正常登陆
/usr/local/mysql/bin/mysql -uroot  -p'新密码'
#如果有需要就升级下版本,例如5.6主库,5.7主库这种情况
mysql_upgrade --defaults-file=/usr/local/mysql/my.cnf -uroot -p'新密码' -h127.0.0.1
#测试功能是否正常
mysql> show databases;

2.    然后是第二种情况,忽略某些表和库的同步,忽略同步的方式可以在主库做,也可以在从库做,不过从一些解析起来很麻烦的坑来说(这里就不说太多了),在从库做是最好的.

1
2
3
4
5
6
7
8
9
10
11
12
#在5.6版本之前需要在配置文件my.cnf操作,当然是要重启才生效
vim /usr/local/mysql/my.cnf
#只执行某个库或某个表的同步语句
replicate_wild_do_table=test.%,mysql.user
#忽略掉某个库或某个表的同步语句
replicate_wild_ignore_table=mysql.%,test.fucking
#在5.7之后的版本,新加入了一个动态修改的命令,不用重启了
#这次不用理会配置文件了,当然后面加一下我觉得还是有必要,避免重启后还原的报错
#只执行某个库或某个表的同步语句
mysql > change replication filter replicate_wild_do_table=(''test.%',''mysql.user');
#忽略掉某个库或某个表的同步语句
mysql > change replication filter replicate_wild_ignore_table=(''test.%',''mysql.user');

提醒下,忽略同步的库和表要走心,考虑多一些情况.
3. 在停止多元复制环境时要注意并行复制的进度，例如出现下面这种情况，就先等一等再停止。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#请关注Executed_Gtid_Set:项
show slave status\G
    .
    .
    .
             Master_Server_Id: 2721321239
                  Master_UUID: 4cdc2a74-6299-11e6-95ce-008cfaf595bc
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Reading event from the relay log
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 4cdc2a74-6299-11e6-95ce-008cfaf595bc:50007036-50049107
            Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-47551250,
3edae34c-6299-11e6-95cd-8038bc0c67be:1-6758,
4cdc2a74-6299-11e6-95ce-008cfaf595bc:1-50010063:50010080-50010093:50010099-50010101:50010108:50010130-50010139:50010145-50010148:50010158:50010179-50010184:50010190-50010200:50010207:50010215-50010221:50010227-50010236:50010243:50010276-50010285:50010291-50010293:50010300:50010308-50010312:50010326-50010328:50010371-50010373:50010391-50010393:50010403-50010405:50010427-50010429:50010464-50010466:50010480-50010482:50010490-50010496:50010518-50010520:50010538-50010540:50010551-50010553:50010574
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: al_rds
           Master_TLS_Version: 
*************************** 2. row ***************************
               Slave_IO_State: Waiting for master to send event
    .
    .
    .

那是因为你这么一停止，并行复制就中途停止了，就有可能出现有些数据回滚不了，或者有些数据复制错误，然后后续你还想把他起来就很大可能会报错了，所以宁愿先等一等，再停止。

当然了，如果是线上环境，究竟要等到什么时候？所以最好就是数据库不繁忙的时候再做。要么，你就是准备好重做的心态了，那就来吧。

转自
在线建立或重做mysql主从复制架构方法（传统模式和GTID模式）-ping_note-51CTO博客 http://blog.51cto.com/arthur376/1792551
mysql GTID 主从复制模式 - luckc# - 博客园 https://www.cnblogs.com/luckcs/articles/6295992.html
基于GTID环境的数据恢复 - GoogSQL - 博客园 http://www.cnblogs.com/xuanzhi201111/p/4606444.html