线上项目mysql、redis平滑迁移方案及步骤

1.清晰系统内网及公网可达,CVM配置

2.迁移完整数据,项目部署,测试网络环境.

redis:复制rdb文件
mysql:xtrabackup备份
3.确保项目正常运行,网络正常访问.
项目对外接口及账户中心访问可达.
4.初始化redis,mysql.
5.配置网络环境,同步mysql
1.主库创建同步账号,配置腾讯云mysql为从并可写.配置log-bin
2.主库xtrabackup备份,设置从库导入.获取同步点,启动从库(可写),校验状态.
6.配置网络环境,同步redis
1.配置腾讯云redis为从并可写,SLAVEOF同步.
7.更新配置上线,mysql、redis切断恢复主配置.
8.校验mysql、redis,测试接口

demo:步骤
1.mysql:xtrabackup备份
安装xtrabackup
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL //安装依赖包
percona-xtrabackup-2.4.1.tar.gz 解压
备份:
innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=root --password=gzf /home/gzf/innobackup/
还原
systemctl stop mysqld
rm -rf /var/lib/mysql
innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=root --password=gzf --apply-log /home/gzf/innobackup/2017-07-26_14-58-58
innobackupex --defaults-file=/etc/my.cnf --host=127.0.0.1 --user=root --password=gzf --copy-back /home/gzf/innobackup/2017-07-26_14-58-58
chown -R mysql /var/lib/mysql
systemctl start mysqld
2.主从同步:
xtrabackup_info文件获取到binlog和pos位置
确保主从 log-bin= server-id配置;
主创建同步账号
GRANT REPLICATION SLAVE ON *.* to ‘gzf‘@‘%‘ identified by ‘gzf‘;
检查看binlog File 名与备份一致,禁止主重启
show master status;
从配置
change master to master_host=‘**********‘,master_user=‘gzf‘,MASTER_PORT=3306,master_password=‘gzf‘, master_log_file=‘gzflog-bin.000002‘,master_log_pos=1736;
start slave;
show slave status\G;
io和sql线程都能yes说明成功;
mysql只读判断:
mysql> flush tables with read lock;
mysql> set global read_only=1;
将salve库从只读状态变为读写状态,需要执行的命令是:
mysql> unlock tables;
mysql> set global read_only=0;
show global variables like "%read_only%"; //查看只读状态:
3.redis主从同步
从redis配置slave-read-only no
slaveof 127.0.0.1 6379
--断开
slave on one

时间: 2024-12-26 08:54:03

线上项目mysql、redis平滑迁移方案及步骤的相关文章

线上项目腾讯云平滑迁移方案及步骤

目前项目需要迁移至公有云,数据量较大,访问量极高,以腾讯云为例.我们有两种方案(1)购买配置cvm部署应用,云存储Redis,CDB for MySQL,负载均衡CLB(公网)问题: 1.腾讯云redis迁移工具原理为主从拉取rbd\aof进行全量同步,考虑共用腾讯云旧实例保留老数据,及本身主从redis有其他项目数据,便放弃迁移. 2.redis主从同步,跟分库(15个)无关,slaveof后会覆盖各个分库.拉取主库全部分库数据. 3.腾讯云不支持mysql5.7迁移及mysql5.7至mys

Redis数据迁移方案

场景 Redis实例A ---> Redis实例B,整库全量迁移 方案一: mac环境 brew install npm npm install redis-dump -g 针对RedisA: redis-dump -h host1 -p 6379 -d 1 --json > mydb.json针对RedisB: cat mydb.json | redis-dump --convert | redis-cli 方案二:参考: http://www.zlovezl.cn/articles/mig

[原]不同场景下MySQL的迁移方案

一 为什么要迁移 MySQL 迁移是 DBA 日常维护中的一个工作.迁移,究其本义,无非是把实际存在的物体挪走,保证该物体的完整性以及延续性.就像柔软的沙滩上,两个天真无邪的小孩,把一堆沙子挪向其他地方,铸就内心神往的城堡. 生产环境中,有以下情况需要做迁移工作,如下: 1.磁盘空间不够.比如一些老项目,选用的机型并不一定适用于数据库.随着时间的推移,硬盘很有可能出现短缺: 2.业务出现瓶颈.比如项目中采用单机承担所有的读写业务,业务压力增大,不堪重负.如果 IO 压力在可接受的范围,会采用读写

不同场景下 MySQL 的迁移方案

不同场景下 MySQL 的迁移方案 Posted in MySQL and tagged MySQL, 数据迁移, 方案 on Sep 15, 2015. Viewd 2684 times. 文/温国兵 一 目录 一 目录 二 为什么要迁移 三 MySQL 迁移方案概览 四 MySQL 迁移实战 4.1 场景一 一主一从结构迁移从库 4.2 场景二 一主一从结构迁移指定库 4.3 场景三 一主一从结构双边迁移指定库 4.4 场景四 一主一从结构完整迁移主从 4.5 场景五 双主结构跨机房迁移 4

mysql迁移之巨大数据量快速迁移方案

mysql迁移之巨大数据量快速迁移方案-增量备份及恢复 --chenjianwen 一.前言: 当mysql库的大小达到几十个G或者上百G,迁移起来是一件非常费事的事情,业务中断,导出导入耗费大量的时间:所以,需要考虑怎么去节省时间的问题. 二.方案: 1.制定维护时间,中断业务,登录 mysql,刷新日志 2.全备数据,备份后得到 binlog 日志文件 mysql-bin.000001 3.迁移走之前的 binlog 日志文件,只留下 mysql-bin.000001 4.恢复业务 5.将全

mysql 5.7 迁移数据方案

从一台服务器迁移至其他服务器,如何选择最短的停服时间方案 方案一.凌晨3点的全备份+停服后一天的大概一天的增备 1. 拷贝前一天的全备份至新的服务器 rsync -auzrP /Data/dbbak/db/2019-04-23/2019-04-23_03-10-11 [email protected]:/data/backup/full/ 2. 解压(备份方式:innobackupex  --compress,所以需要提前解压) innobackupex --decompress /data/b

Redis集群方案(来自网络)

参考: https://www.zhihu.com/question/21419897 http://www.cnblogs.com/haoxinyue/p/redis.html 为什么集群? 通常,为了提高网站响应速度,总是把热点数据保存在内存中而不是直接从后端数据库中读取.Redis是一个很好的Cache工具.大型网站应用,热点数据量往往巨大,几十G上百G是很正常的事儿,在这种情况下,如何正确架构Redis呢? 首先,无论我们是使用自己的物理主机,还是使用云服务主机,内存资源往往是有限制的,

dubbo升级2.7.4.1平滑迁移到nacos

dubbo是一款非常优秀的服务治理型RPC框架,dubbo的优秀在于,庞大的架构体系.精湛的模块设计.灵活的SPI设计.丰富的组件实现,博主做微服务技术选型考察dubbo时,非常惊叹在那个年代别人就已经能够产出如此优秀的项目,以至于后面每逢别人说想要学习架构设计时,我都会推荐他读读dubbo的代码,学习下dubbo的架构设计原则.常说dubbo不仅仅是一款RPC框架,是因为他的服务治理特性相对于RPC通讯来说更加的突出,这个特性让我在2017年选型的时候果断选择了他,那个时候dubbo官方还没产

架构设计:系统存储(18)——Redis集群方案:高性能

1.概述 通过上一篇文章(<架构设计:系统存储(17)--Redis集群方案:高可用>)的内容,Redis主从复制的基本功能和进行Redis高可用集群监控的Sentinel基本功能基本呈现给了读者.虽然本人并不清楚上一篇根据笔者实际工作经验所撰写的文章有什么重大问题,导致那么多朋友集体点踩而且截止目前又没有任何人愿意为笔者指出这些问题,但是这不会影响笔者继续学习.总结技术知识的热情.从这篇文章开始我们一起来讨论Redis中两种高性能集群方案,并且在讨论过程中将上一篇文章介绍的高可用集群方案结合