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/backup/full/2019-04-23_03-10-11

  3. 停服

   systemctl stop mysqld

  5. 增备

   innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456  --incremental /data/backup/incr --incremental-basedir=/data/backup/full/2019-04-02_16-42-43

  6. 恢复

  --应用日志

   innobackupex --defaults-file=/usr/local/mysql/etc/my.cnf --apply-log --redo-only  /data/2019-04-18_03-10-09/

  innobackupex --defaults-file=/usr/local/mysql/etc/my.cnf --apply-log --redo-only  /data/2019-04-18_03-10-09/  --incremental-dir=/root/2019-04-18_19-06-43

  7. 拷贝至data目录下,并授权

   innobackupex --defaults-file=/usr/local/mysql/etc/my.cnf --copy-back /data/2019-04-18_03-10-09/

   chown -R  mysql:mysql /data/mysql-data/

   chmod -R 755   /data/mysql-data/

  8. 恢复完成,启动mysql

  mysqld_safe  --user=mysql &

方案二、当前时间全备+binglog恢复

  1. 全备份(热备,物理备)

  innobackupex --defaults-file=/etc/my.cnf --user=root --password=‘123456‘  --use-memory=12G --kill-long-queries-timeout=5 --ftwrl-wait-timeout=20 --compress  --compress-threads=16 /data/bak/db/`date +%F`

  2. 拷贝至新服务器,并恢复

  rsync -auzrP /Data/dbbak/db/2019-04-23/2019-04-23_03-10-11 [email protected]:/data/backup/full/

   innobackupex --decompress /data/backup/full/2019-04-23_03-10-11

   innobackupex --apply-log  /data/backup/full/2019-04-23_03-10-11

   innobackupex --copy-back  /data/backup/full/2019-04-23_03-10-11

  3. 停服保证数据一致性,再将期间产生的binlog拷贝至新的服务器并执行

  mysqlbinlog --start-position=1108  mysql-bin.000007 |mysql -uroot -p123456 -v

方案三、主从架构复制的方式

  1.用全备份恢复

   rsync -auzrP /Data/dbbak/db/2019-04-23/2019-04-23_03-10-11 [email protected]:/data/backup/full/

   innobackupex --decompress /data/backup/full/2019-04-23_03-10-11

   innobackupex --apply-log  /data/backup/full/2019-04-23_03-10-11

   innobackupex --copy-back  /data/backup/full/2019-04-23_03-10-11

  2. 授权新服务器复制权限

  GRANT REPLICATION SLAVE ON *.* TO ‘rep20‘@‘10.8.9.20‘ IDENTIFIED BY ‘123456‘;

  3. 给所有表加上只读锁

  flush tables with read lock;

  4. 配置主从

   stop slave;

   change master to master_host=‘172.16.1.88‘, master_user=‘rep20‘, master_password=‘ 123456‘, master_log_file=‘mysql-bin.000614‘,  master_log_pos=296235077;

   start slave;

  5. 查看主从状态

  Master_Log_File和Relay_Master_Log_File所指向的文件必须一致

  Relay_Log_Pos和Exec_Master_Log_Pos的为止也要一致才行

  Slave_SQL_Running_State:显示为wait 意思是中继日志的sql语句已经全部执行完毕

  6. 验证部分表的记录条数,和最后一条数据的内容

  select count(*) from student;

  select * from student order by create_time desc limit 1;

  7. 解锁

  UNLOCK TABLES;

  

总结: 方案一是增备的方式,步骤复杂了一些,操作失误就得重新恢复,停服的时间也需要更长,出错的概率也相对大;

      方案二 停服前全备份(还是热备),真正停服的时间是拷贝binlog和恢复binlog的时间,速度快,2步骤,出错概率低;(推荐)

   方案三 停服时间最短,但是相对更难校验数据的一致性,一旦数据不一致还有写入,会造成很大的麻烦。

  

   

原文地址:https://www.cnblogs.com/Jack1023/p/10905888.html

时间: 2024-11-25 08:24:38

mysql 5.7 迁移数据方案的相关文章

从MySQL到Redis 提升数据迁移的效率

场景是从MySQL中将数据导入到Redis的Hash结构中.当然,最直接的做法就是遍历MySQL数据,一条一条写入到Redis中.这样可能没什么错,但是速度会非常慢.而如果能够使MySQL的查询输出数据直接能够与Redis命令行的输入数据协议相吻合,可能就省事多了.根据测试800w的数据迁移,时间从90分钟缩短到2分钟.具体案例如下:MySQL数据表结构: CREATE TABLE events_all_time (id int(11) unsigned NOT NULL AUTO_INCREM

在MySQL和分布式TiDB之间迁移数据

在MySQL和分布式TiDB之间迁移数据,这里用到mydumper工具. 迁移分为2步: 第1步:dump到本地,需要保证本地有足够的磁盘空间 import os import sys import datetime import subprocess src_db1 = 'test1' src_table1 = 'table1' dump_time1 = datetime.datetime.now().strftime("%Y%m%d_%H%M") file_path1 = '/ho

MYSQL大小写(由于数据由windows迁移到Linux导致)

今日从sqlserver上迁移了一个数据库到Linux的MySQL中,迁移成功了,但是应用却跑不通,查看日志发现,提示找不到表,我注意到,表名都是存在大小写的,而MySQL中的表名都是小写的.这提醒了我,莫非MySQL 中表名是大小写敏感的?一查果然如此.解决方案如下: 1.用ROOT登录,修改/etc/my.cnf 2.在[mysqld]下加入一行:lower_case_table_names=1 3.重新启动数据库即可 其中 lower_case_table_names=1 参数缺省地在 W

分库分表?如何做到永不迁移数据和避免热点?

一.前言 中大型项目中,一旦遇到数据量比较大,小伙伴应该都知道就应该对数据进行拆分了.有垂直和水平两种.垂直拆分比较简单,也就是本来一个数据库,数据量大之后,从业务角度进行拆分多个库.如下图,独立的拆分出订单库和用户库. 水平拆分的概念,是同一个业务数据量大之后,进行水平拆分. 上图中订单数据达到了4000万,我们也知道mysql单表存储量推荐是百万级,如果不进行处理,mysql单表数据太大,会导致性能变慢.使用方案可以参考数据进行水平拆分.把4000万数据拆分4张表或者更多.当然也可以分库,再

mysql复制(高可用架构方案的基础)

mysql复制:把一个数据库实例上所有改变复制到另外一个数据库库服务器实例的过程特点:1.没有改变就无所谓复制 ;改变是复制的根本与数据源2.所有的改变:是指可以复制全部改变,也可以复制部分改变 可以在全部改变中根据业务需求选择部分库和部分表的复制复制的场景: 1.数据库容灾 2.需求:创建一个从数据服务器,做数据的测试和分析 3.负载均衡 4.复制时高可用架构方案的基础 mysql高可用架构特点1.数据库故障的检测与排除2.主从数据库的切换3.数据的备份和保护 mysql高可用架构常用方案1.

SEP迁移升级方案

方案一.灾难恢复后升级 实施前提条件:更换服务器系统/重装服务器系统,但保持主机名和IP地址不变. 实施步骤: 1.先备份原有SEPM服务器数据库 1.1到文件夹C:/program files/Symantec /Symantec endpoint protection manager/data/backup下检查是否有下面三个文件keystoreXXX.jsk,serverxxx.xml,及xxx.zip文件,xxx为当日日期.将此三分文件拷贝到其他位置备用. 2.在新的服务器上安装SEPM

TiDB 作为 MySQL Slave 实现实时数据同步

由于 TiDB 本身兼容绝大多数的 MySQL 语法,所以对于绝大多数业务来说,最安全的切换数据库方式就是将 TiDB 作为现有数据库的从库接在主 MySQL 库的后方,这样对业务方实现完全没有侵入性下使用 TiDB 对现有的业务进行备份,应对未来数据量或者并发量增长带来的单点故障风险,如需上线 TiDB,也只需要简单的将业务的主 MySQL 地址指向 TiDB 即可. 下面我们详细介绍了如何将 MySQL 的数据迁移到 TiDB,并将 TiDB 作为 MySQL 的 Slave 进行数据同步.

MySQL中快速复制数据表方法汇总

本文将着重介绍两个MySQL命令的组合,它将以原有数据表为基础,创建相同结构和数据的新数据表. 这可以帮助你在开发过程中快速的复制表格作为测试数据,而不必冒险直接操作正在运行 的数据表. 示例如下: 将 production 数据库中的 mytbl 表快速复制为 mytbl_new,2个命令如下: CREATE TABLE mytbl_new LIKE production.mytbl; INSERT mytbl_new SELECT * FROM production.mytbl; 第一个命令

一步完成MySQL向Redis迁移

在把一个大表从 MySQL 迁移到 Redis 时,你可能会发现,每次提取.转换.导入一条数据是让人难以忍受的慢!这里有一个技巧,你可以通过使用管道把 MySQL 的输出直接输入到 redis-cli输入端,这可以使两个数据库都能以他们的最顶级速度来运行. 使用了这个技术,我把 800 万条 MySQL 数据导入到 Redis 的时间从 90 分钟缩短到了两分钟. Mysql到Redis的数据协议 redis-cli命令行工具有一个批量插入模式,是专门为批量执行命令设计的.这第一步就是把Mysq