码迷,mamicode.com
首页 > 数据库 > 详细

不停应用服务,在线建立或重做mysql主从复制的案例,包含一般模式和GTID模式

时间:2016-06-24 20:53:23      阅读:654      评论:0      收藏:0      [点我收藏+]

标签:mysql 主从

mysql主从嘛,绝大多数公司都有用到,GTID发展到现在也是越来越多人用,停止应用服务来做主从,略显low了,现在都流行在线做,不影响业务,多实际是吧,不啰嗦了,现在就来看看案例.

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


先说mysqldump方式,

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


第一步,配置和授权

如果没有GTID,主库不用做些什么,主从之间注意server-id就可以了,这个坑很容易掉进去,当然了,binlog是必须开的,主从就靠这个来复制的,不开就是白搭,binlog_format推荐用row,transaction_isolation推荐是REPEATABLE-READ,如果想用到GTID,那就要开启下面两个参数,

#GTID模式,5.6新功能,新的复制方式,需要就打开,binlog要改成row

gtid_mode = on

#强制GTID的一致性,一般和上面参数一起使用,但是开启后只允许能够保障事务安全,并且能够被日志记录的SQL语句被执行,像create table ... select 和 create temporarytable语句,以及同时更新事务表和非事务表的SQL语句或事务都不允许执行。

enforce_gtid_consistency = 1

要写到配置文件,重启生效,因为不能在线改,

mysql> set gtid_mode = 1;

ERROR 1238 (HY000): Variable ‘gtid_mode‘ is a read only variable

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

对于从库要注意一个参数,

#用来配置从服务器的更新是否写入二进制日志,如果有层级从库就必须开,没有的话建议关闭,能有效提高性能

log_slave_updates

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

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

grant replication slave on *.* to ‘rep‘@‘%‘ identified by ‘password‘;

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


第二步,数据的导出与导入和初始化从库,

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

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

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

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

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

简单说说怎么初始化

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‘

简单几个命令就完成了初始化,然后准备导入,为什么要说准备呢,当然是因为还有些准备工作,安全相关的有需求做就做吧,一些特殊的设置也是,这里要说的就是GTID模式下,导入前要先重置下binlog

reset master;

原因是使用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 -uroot -p123123 -e ‘reset master‘

mysql -uroot -p123123 < test2.sql

好了,导入完成后,我们检查一下,一般模式就直接

show databases;

gtid模式还要看看这个

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了,只看关键字

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就可以了.

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模式下,则还需要多做一步,就是执行那个语句,

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

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

change master to

master_host=‘10.0.2.6‘,

master_user=‘root‘,

master_password=‘123123‘,

master_port=3306,

MASTER_AUTO_POSITION = 1;

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

然后启动从库复制

start slave;

最后检查一下

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

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

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

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就不多说了,各位可以看我另一篇文章,介绍怎么安装xtrabackup2.3.4和介绍怎么使用xtrabackup,命令我就简单贴出来,然后说一下用途就算了.

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

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压缩成一个文件.

拷贝到从库机器

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

然后拷贝到一个文件夹解压

mkdir test2back

mv test2.tgz test2back/

cd test2back/

tar xf test2.tgz

现在开始恢复备份

关闭mysql服务

/etc/init.d/mysqld stop

先删了旧的数据文件

rm -rf /data/mysql/data*

然后先apply-log

innobackupex --defaults-file=‘/usr/local/mysql/my.cnf‘ --user=root --password=‘123123‘ --apply-log /data/ttt/test2back/

然后开始恢复

innobackupex --defaults-file=‘/usr/local/mysql/my.cnf‘ --user=root --password=‘123123‘ --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数据还比较新.

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

vim xtrabackup_binlog_info

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

非常直观,就这三个值,如果你还有兴趣留意,其实xtrabackup_info也有记录.

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

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一下,跳过之前已经执行过的事务

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

然后看一下状态

mysql> show variables like ‘%gtid%‘;

gtid_purged                     | 16fdabc7-30f9-11e6-9234-0800273e5680:1-22037 |

再执行change master to 来完成

change master to

master_host=‘10.0.2.6‘,

master_user=‘root‘,

master_password=‘123123‘,

master_port=3306,

MASTER_AUTO_POSITION = 1;

然后启动从库复制

start slave;

最后检查一下

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

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

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

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主从复制的案例,包含一般模式和GTID模式

标签:mysql 主从

原文地址:http://arthur376.blog.51cto.com/2918801/1792551

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!