ITPub博客

首页 > 数据治理 > 数据治理 > 主备都是全新的恢复,主主搭建步骤

主备都是全新的恢复,主主搭建步骤

原创 数据治理 作者:ginni_hua 时间:2019-09-29 17:13:30 0 删除 编辑
1.172.17.16.8 tar备份copy到跳板机14:42  16:23  100min
scp 172.17.16.8:/home/mysql/DBbackup/bk_newoa/20190116.tar /data/hua/
2. 从跳板机copy至172.19.53.149&53.150  16:32  15min
scp /data/hua/20190116.tar 172.19.53.149:/data/hua/
scp /data/hua/20190116.tar 172.19.53.150:/data/hua/
3.停实例172.19.53.149&53.150
4.将172.19.53.149&53.150 数据删除  5min
rm -rf /data/mysql/db_newoa/data/*
5.将172.19.53.149&53.150解压缩  6min
innobackupex --decompress --parallel=8 /data/hua/20190116/base_20190116
6.在172.19.53.149&53.150上应用数据  2min
innobackupex --apply-log /data/hua/20190116/base_20190116
7.在172.19.53.149&53.150上copy恢复  10min
innobackupex --defaults-file=/data/mysql/db_newoa/newoa.cnf --copy-back /data/hua/20190116/base_20190116
innobackupex --defaults-file=/data/mysql/db_newoa/newoa.cnf --move-back /data/hua/20190116/base_20190116
8.开启数据库
sh startup.sh
9.重做主从
172.19.53.149:
reset master;
reset slave all;
change master to master_host='172.19.53.150', MASTER_PORT=23308, master_user='repl', master_password='4%REplic', MASTER_AUTO_POSITION=1;
172.19.53.150:
reset master;
reset slave all;
备份文件中找到 xtrabackup_slave_info 文件,根据里面内容执行,如果主从都为全新的库,不需要重新设定gtid:
-- SET @@GLOBAL.GTID_PURGED='XXXX';   #执行这个必须gtid为空,先执行reset master
-- set global gtid_executed="7d58ee1a-93a0-11e7-8ff5-f44c7f785650:1-3,d2cf8b03-939f-11e7-99db-407d0f46034d:1-14193879"
change master to master_host='172.19.53.149', MASTER_PORT=23308, master_user='repl', master_password='4%REplic', MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
如果不通,一般是帐号的问题(密码不对?无访问权限...)
select * from mysql.slave_master_info\G;  #查看帐号密码信息repl
show grants for repl@'%';
select user,host from mysql.user; #查看帐号权限,如果有限定IP,则需要变更
update mysql.user set host='%' where user='repl';
还是不通,则为防火墙端口没打开
[root@mysqltest1 ~]# firewall-cmd --zone=public --add-port=23301/tcp --permanent  #开启23301
success
[root@mysqltest1 ~]# firewall-cmd --reload #载入
success
[root@mysqltest1 ~]# firewall-cmd --zone=public --query-port=23301/tcp  #查看
yes
[root@mysqltest1 ~]#  systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-01-23 23:10:23 EST; 30min ago
Docs: man:firewalld(1)
Main PID: 4081 (firewalld)
CGroup: /system.slice/firewalld.service
异常ERROR:
1.Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
这是因为mysql2克隆的mysql1所以,UUID是一样,我们只需要修改mysql2的UUID,重启动mysql服务即可。 vi /data/mysql/db_order/data/auto.cnf  不要破坏UUID的格式,字母的地方是字母,数字的地方是数字,只面要变更其中的数字即可。
2.mysql> start slave;
ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
原因:检查my.cnf,原来没指定relay_log,mysql默认产生的relay_log名被该server上的另一个mysql slave占用了。
修改名称: relay_log = /db/mysql56/logs/relay_98_3326
10.开启keepalived
sudo systemctl restart keepalived
11.检查
备注(reset master/reset slave all):
reset master删除所有index file 中记录的所有binlog 文件,将日志索引文件清空,创建一个新的日志文件,这个命令通常仅仅用于第一次用于搭建主从关系的时的主库.
注意
  reset master 不同于purge binary log的两处地方
1 reset master 将删除日志索引文件中记录的所有binlog文件,创建一个新的日志文件 起始值从000001 开始,然而purge binary log 命令并不会修改记录binlog的顺序的数值
2 reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master 命令不被支持,reset master 将master 的binlog从000001 开始记录,slave 记录的master log 则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。
RESET SLAVE
reset slave 将使slave 忘记主从复制关系的位置信息。该语句将被用于干净的启动, 它删除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新启用一个新的relaylog文件。
使用reset slave之前必须使用stop slave 命令将复制进程停止。
注 所有的relay log将被删除不管他们是否被SQL thread进程完全应用(这种情况发生于备库延迟以及在备库执行了stop slave 命令),存储复制链接信息的master.info文件将被立即清除,如果SQL thread 正在复制临时表的过程中,执行了stop slave ,并且执行了reset slave,这些被复制的临时表将被删除。
RESET SLAVE  ALL
在 5.6 版本中 reset slave 并不会清理存储于内存中的复制信息比如  master host, master port, master user, or master password,也就是说如果没有使用change master 命令做重新定向,执行start slave 还是会指向旧的master 上面。
当从库执行reset slave之后,将mysqld shutdown 复制参数将被重置。
在5.6.3 版本以及以后 使用使用 RESET SLAVE ALL 来完全的 清理复制连接参数信息。 (Bug #11809016)
RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7836221/viewspace-2658757/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2008-03-20

  • 博文量
    174
  • 访问量
    372704