博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
没有找到mysql。sock_mysql8基于gtid方式搭建主从或恢复
阅读量:6973 次
发布时间:2019-06-27

本文共 2288 字,大约阅读时间需要 7 分钟。

对于mysql8基于gtid方式搭建主从或恢复,看到网上写的太多了,但是效果太差劲,现给出落地步骤(按照我的一步步来保准没问题,具体操作原因不赘述--请参考官方文档:https://dev.mysql.com/doc/refman/8.0/en/replication.html)

废话不多说,直接上实践步骤

前提说明

机器说明:

从库:10.5.31.9 10.5.31.10

主库:10.5.31.8

数据库数据目录/data/mysql/

数据库日志目录/mysqllog/

该文档基于已经建立的mysql8安装模板(已开启gtid、binlog功能)

以下步骤适用于主从搭建或恢复主从关系

从库上操作:10.5.31.9 10.5.31.10

reset master;

stop slave;

service mysqld stop

#删除从库上所有的数据

rm -fr /data/mysql/*

#清除mysql的所有日志,尤其是undo日志

rm -fr /mysqllog/*

注意:修改配置文件/etc/my.cnf中的server_id=211,主从不应一样,从库的值大于主库。

主库上操作(注意开启binlog日志和gtid功能,这里不多说,可以参考华阳的模板中的配置文件):10.5.31.8

#创建复制账号并授予replication slave权限

create user repl@'%' identified by '123456';

grant replication slave on *.* to repl@'%';

flush privileges;

#创建备份目录

mkdir /data/backup -p

#全备

xtrabackup -uroot -p1234.Com --socket=/data/mysql/mysql.sock --backup --target-dir=/data/backup --defualt-file=/etc/my.cnf

#拷贝数据到从库

scp -r /data/backup mysql@10.5.31.9:/data

scp -r /data/backup mysql@10.5.31.10:/data

以下步骤是在主库操作完毕后,在从库上操作:10.5.31.9 10.5.31.10

xtrabackup --prepare --target-dir=/data/backup --default-file=/etc/my.cnf

xtrabackup --copy-back --target-dir=/data/backup --default-file=/etc/my.cnf

登录主库,查看gtid号:10.5.31.8

show master status;

登录从库:10.5.31.9 10.5.31.10

change master to master_host='10.5.31.8',master_port=3306,master_user='repl',master_password='123456',master_auto_position=1;

set gtid_next='automatic';

set global read_only = on;

start slave;

show slave status\G;

显示两个yes,同时Retrieved_Gtid_Set和Executed_Gtid_Set正常即可。

主从热恢复,逻辑备份方式

主库上操作

mysqldump -uroot -p123456 --single-transaction --master-data=2 --socket=/data/mysql/mysql.sock -A > all.sql

--single-transaction 这个参数避免备份时锁表

--master-data=2 因为是基于gtid方案搭建主从,所以采用2,如果是基于binlog日志方案则使用1(记录位置点)

grep GLOBAL.GTID_PURGED all.sql --例如该结果为4a81e208-9f0f-11ea-8686-005056a5c812:1-1202,主要是找到事务号(因为从的事务号和当前备份的肯定是不一样的--主库一直在写数据,需要重新设定从的事务号)

scp ./all.sql 10.5.31.9:/data/

scp ./all.sql 10.5.31.10:/data/

从库上执行:

stop slave;

source /data/all.sql;

RESET MASTER;---将事务置为0,并重新设定事务号

set GLOBAL gtid_purged='4a81e208-9f0f-11ea-8686-005056a5c812:1-1202';

set global read_only = on;

start slave;

show slave status\G;

显示两个yes,同时Retrieved_Gtid_Set和Executed_Gtid_Set正常即可。

查看从库复制表是否有异常(无结果表示无异常,一般情况是符合预期的):select * from performance_schema.replication_applier_status_by_worker where LAST_ERROR_NUMBER>0\G;

转载地址:http://mxhsl.baihongyu.com/

你可能感兴趣的文章
岗位信息显示英伟达芯片重返苹果Mac电脑
查看>>
Facebook押宝的“聊天机器人”会不会仅是一场泡沫?
查看>>
企业微信入局,移动办公又演化成BAT大战?
查看>>
希捷发布企业级固态硬盘 最高速度可达10GB/s
查看>>
安防监控防雷器选择技巧
查看>>
如何删除或重置spfile中的参数
查看>>
【RAC】如何修改vip 或者vip 对应的hostname
查看>>
Sql Server之旅——第三站 解惑那些背了多年聚集索引的人
查看>>
GIX4中懒加载
查看>>
LogCat大量Unexpected value from nativeGetEnabledTags: 0
查看>>
diff corp's HBA and multipath
查看>>
正则表达式基本用法
查看>>
JS中的继承模式
查看>>
很简单的next.js数据获取规范
查看>>
String方法小总结
查看>>
区块链技术融合云计算是如何引领未来新趋势
查看>>
iOS二进制和资源包的自检
查看>>
ubuntu中常用的一些命令
查看>>
第五章 异常和断言
查看>>
JavaScript中的prototype如何实现共享方法,而不产生多个copy
查看>>