Mysql数据库备份复制

索引

  • 数据库备份类型及备份内容
  • 常用的备份工具
  • mysqldump介绍
  • 实战

在生产环境中我们的数据库可能会遭遇不可预测的灾害从而导致数据库的数据丢失。例如:

  • 硬件故障
  • 软件故障
  • 自然灾害
  • 黑客攻击
  • 误操作 (这种原因占据多数)

不可抗力我们没有办法左右,但是我们可以通过一定手段恢复数据库数据。为了恢复数据,我们就要定期备份数据,备份数据的策略要根据不同的场景制定,大致有以下几个参考因素:

  • 能够容忍丢失多少数据
  • 恢复数据需要多长时间
  • 需要恢复哪些数据

一、数据库备份类型及备份内容

在 mysql 中一般有以下几种备份方式:

  • 热备份

热备份是指当数据库在备份时,数据库的读写功能不受影响。例如 InnoDB 支持热备

  • 温备份

温备份是指当数据库在备份时,数据库的读不影响,但是不能执行写操作。例如 InnoDB,MyISAM 都支持温备

  • 冷备份

冷备份是指当数据库在备份时,数据库的读写功能都不能执行,即数据库要下线。例如 InnoDB,MyISAM 都支持冷备

物理备份:

指通过cp,tar等命令直接打包复制数据库数据

逻辑备份:

指通过特定的工具从数据库中导出数据并另存备份(逻辑备份会丢失数据精度)。逻辑备份一般是备份建表,建库,插入,删除等操作的SQL语句,适用于中小型数据库,效率相对较低。常用工具有:mysqldump,mydumper

逻辑备份优点:

  1. 在备份速度上两种备份要取决于不同的存储引擎 物理备份的还原速度非常快。但是物理备份的最小单位只能到表
  2. 逻辑备份保存的结构通常都是纯ASCII的,所以我们可以使用文本处理工具来处理
  3. 逻辑备份有非常强的兼容性,二物理备份则对版本的要求非常高
  4. 逻辑备份也对保持数据的安全性有保证

逻辑备份缺点:

  1. 逻辑备份要对RDBMS产生额外的压力,而裸备份无压力
  2. 逻辑备份的结果可能要比源文件更大。所以很多人都对备份的内容进行压缩
  3. 逻辑备份可能会丢失数据精度

建议备份的内容:

  • 数据文件日志文件(如二进制日志文件,事务文件等)
  • 存储过程,存储函数,触发器
  • 配置文件(十分重要,各个配置文件都要备份)
  • 用于实现数据库备份的脚本,数据库自申清理的定时计划任务等…

二、常用的备份工具

  1. mysqldump:

逻辑备份,适用于所有存储引擎,支持温备、完全备份、部分备份、对于InnoDB存储引擎支持热备

  1. cp、tar等归档复制工具:

物理备份工具,适用于所有存储引擎,冷备、完全备份、部分备份

  1. lvm2 snapshot:

几乎热备,借助文件系统管理工具进行备份

  1. mysqlhotcopy:

名符不其实的工具,几乎冷备,仅支持"MyISAM"存储引擎

  1. xtrabackup:

一款非常强大的"InnoDB/XtraDB"热备工具,支持完全备份,增量备份

三、mysqldump介绍

1、语法

mysqldump  -h   服务器地址  -u   用户名  -p密码   数据库名   >  备份文件.sql   

2、数据库名分类

选项 含义
- A ,- - all-databases 所有库
备份单库 school ---- 数据库名
备份指定库中的表 school table1 table2 ---- 数据库school的表table1,tables2
- B,- - databases mydb1 mydb2 指定多个库 ---- mydb1,mydb2库
- d 只备份库结构,不包含数据内容
- - single-transaction 该选项可以实现对 InnoDB 的热备
- x,- - lock-all-tables 备份过程中为所有表加锁(MyISAM使用)
- l,- - lock-tables 备份时为指定表加锁
- E,- - events 备份事件调度器代码
- - opt 同时启动各种高级选项
- R,- - routines 备份存储过程和存储函数
- F,- - flush-logs 备份之前刷新日志文件
- - triggers 备份触发器
- - master-data=2 备库,该选项将会记录binlog的日志位置与文件名并追加到文件中,如果为1将会输出change master命令,主从复制时有用

四、实战

---- 增量+全量

环境要求:
(1)两台centos7机器,分别装有mysql (我的版本是8)两台机器版本要一致,否则会备份在还原数据时,会出错。如果是克隆机,要修改mysql-uuid,不能相同。
(2)情景:每天凌晨00:00备份数据库数据,突然在某一天凌晨00:30数据库中某库出现故障,要求还原数据库数据。

备库存放备份目录 /data/mysql/
主库打包数据存放位置 /root/mysql-` data “+%F” `.sql.gz
主库日志文件位置 /data/mysql/data/binlog
主库地址 192.168.139.152
备库地址 192.168.139.153

在主库上创建一个库mydb01,创建一个表test01,并插入数据,备库初始化状态。(假设此状态为数据库原有状态,00:30时mydb01出现故障)

主库:

在这里插入图片描述

备库:

在这里插入图片描述
主库全量备份操作

#编辑配置文件/etc/my.cnf,打开binlog功能
vim  /etc/my.cnf
#定义binlog日志文件存放位置
log_bin = /data/mysql/data/binlog
#重启mysqld
systemctl stop msyqld
systemctl start mysqld    
#压缩备份数据库
mysqldump -uroot -p --single-transaction mydb | gzip > /root/mysql-`data "+%F" `.sql.gz  
#用scp发送到备份端
scp -p /root/mysql-`data "+%F"`.sql.gz [email protected]:/data/mysql/    

备库全量恢复操作

#备库解压压缩数据
gunzip /data/mysql/mysql-`data "+%F"`.sql.gz 
#创建对应数据库
mysql -u root -p  -e "create database mydb01"
#恢复全量备份数据库数据
mysql -u root -p mydb01 < /data/mysql/mysql-`data "+%F"`.sql

主库增量备份操作

#查看数据库日志文件
ls /data/mysql/data/binlog.*

#立即刷新并备份出日志文件
msyqladmin -u root -p flush-logs
cp /data/mysql/data/binlog.*  /server/backup/
根据时间点查出发现问题时刻的binlog文件,假设为binlog.000005   

#恢复binlog生成SQL语句
mysqlbinlog binlog.000005 > binlog-`date "+%F"`.sql

#删除sql语句中误操作语句
vim binlog-`date "+%F"`.sql #找到误操作语句并删除

#发送给备库
scp -p /server/backup/binlog-`date "+%F"`.sql [email protected]:/data/mysql/

备库恢复操作

#备库恢复数据库数据
mysql -u root -p mydb01 < /data/mysql/binlog-`date "+%F"`.sql   

此时备库上已完成数据库数据恢复

猜你喜欢

转载自blog.csdn.net/weixin_45440548/article/details/107430858