MySQL/MariaDB数据库备份与恢复

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

前言

数据库一般存放着企业最为重要的数据,它关系到企业业务能否正常运转,数据库服务器总会遇到一些不可抗拒因素,导致数据丢失或损坏,而数据库备份可以帮助我们避免由于各种原因造成的数据丢失或着数据库的其他问题。本文将讲解MySQL/MariaDB数据库的几种备份方法。

基础知识

备份类型

完全备份:备份整个数据库

部分备份:仅备份其中的一张表或多张表

增量备份:仅备份从上次完全备份或增量备份之后变化的数据部分

差异备份:备份上次备份后变化的数据部分,和增量备份区别在于差异备份只可以相对完全备份做备份

热备份、温备份和冷备份:

热备份:在线备份,读写操作不受影响

温备份:在线备份,读操作可继续进行,但写操作不允许

冷备份:离线备份,数据库服务器离线,备份期间不能为业务提供读写服务

物理备份和逻辑备份:

物理备份:直接复制数据文件进行的备份

    优点:无需额外工具,直接copy即可,恢复直接复制备份文件即可

    缺点:与存储引擎有关,跨平台能力较弱

逻辑备份:从数据库中“导出”数据另存而进行的备份

    优点: 能使用编辑器处理,恢复简单,能基于网络恢复,有助于避免数据损坏

    缺点: 备份文件较大,备份较慢,无法保证浮点数的精度,使用逻辑备份数据恢复后,还需手动重建索引,十分消耗CPU资源

备份对象

数据文件

代码:存储过程,存储函数,触发器等

OS相关的配置文件,如crontab配置计划及相关脚本

跟复制相关的配置信息

二进制日志文件

备份工具

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

cp, tar等文件系统工具:物理备份工具,适用于所有存储引擎,冷备、完全备份、部分备份

lvm2的快照:几乎热备,借助于文件系统工具实现物理备份

mysqlhotcopy: 几乎冷备,仅适用于MyISAM存储引擎

数据库备份

备份方案

①mysqldump+binlog: 

完全备份,通过备份二进制日志实现增量备份

②lvm2快照+binlog:

几乎热备,物理备份

③xtrabackup: 

对InnoDB:热备,支持完全备份和增量备份

对MyISAM:温备,只支持完全备份

备份须知

备份某一个数据库和备份所有库是有区别的,要备份某一个库要确保所有的InnoDB存储引擎的表都是存放在单个表空间中,否则必须执行全库备份

1
2
MariaDB [none]> show global variables like  'innodb_file_p%' #查看是否开启单独表空间
MariaDB [none]>  set  global innodb_file_per_table=1;  #开启单独表空间,也可在配置文件设置

mysqldump+binlog

命令的语法格式

1
2
3
mysqldump [OPTIONS] database [tables]:备份单个库,或库指定的一个或多个表
mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]:备份一个或多个库
mysqldump [OPTIONS] --all-databases [OPTIONS]:备份所有库

其他选项

1
2
3
4
5
6
7
8
9
10
11
12
-x, --lock-all-tables:锁定所有表
-l, --lock-tables:锁定备份的表
--single-transaction:启动一个大的单一事务实现备份
-C, --compress:压缩传输
-E, --events:备份指定库的事件调度器
-R, --routines:备份存储过程和存储函数
--triggers:备份触发器
--master-data={0|1|2}
     0:不记录
     1:记录CHANGE MASTER TO语句;此语句未被注释
     2:记录为注释语句
-F,--flush-logs:锁定表之后执行flush logs命令

注意:二进制日志文件与数据文件不应该放置于同一磁盘,这里是实验便不可以修改

备份过程

准备备份目录

wKiom1Vdju7Ss1idAAB_kLgyrAo223.jpg

准备备份数据库及表

wKioL1VdkQfzZkUAAACgZmPb1PI275.jpg

进行完整备份

wKiom1VdkXWgGX_WAACTf9D9SIs505.jpg

向表中插入数据

wKiom1VdkqvSMntSAAGEtI8YJrY763.jpg

进行增量备份,备份二进制日志

wKiom1VdlSni34YJAACoVEP8f7Y819.jpg

继续插入数据,在没备份的情况下删除数据库,模拟误操作

wKioL1VdmR7hmadMAACawmzueLY692.jpg

数据恢复

1
2
#建议关闭二进制日志,关闭其它用户连接
MariaDB [(none)]>  set  session sql_log_bin=0;

由于最后我们没有备份就删除了数据库,所以我们首先需要保护最后的二进制日志,查看删除操作之前的position值

1
[root@MariaDB ~] # mysqlbinlog /mydata/data/mysql-bin.000015

wKioL1Vd_EfApMsMAAE-IM_0uts412.jpg

将最后操作的二进制日志备份

wKiom1VdmaWC1-6wAAC2F0o3iT0363.jpg

导入之前的所有备份

wKioL1VdnMnjlyQ7AACpzl8js74689.jpg

查看数据库及数据

wKioL1VdnROgS2hJAACLbJn68Fs831.jpg

OK,至此数据成功恢复

注意:此方法不适用于大型数据库,备份速度太慢

lvm2快照+binlog

备份过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#请求锁定所有表
MariaDB [ test ]> flush tables with  read  lock;
#滚动日志
MariaDB [ test ]> flush logs;
#记录二进制日志位置
MariaDB [ test ]> show master status;
#创建快照卷
[root@MariaDB ~] # lvcreate -s -L 100M -n mydata-snap /dev/myvg/mydata -p r 
#释放全局锁
MariaDB [ test ]> unlock tables;
#创建快照挂载点
[root@MariaDB ~] # mkdir /snap
#挂载快照卷
[root@MariaDB ~] # mount /dev/myvg/mydata-snap /snap
#备份数据库
[root@MariaDB ~] # cp -a /snap /backup/
#增量备份,查看完整备份之前的二进制日志位置和最后出错操作前一位置
[root@MariaDB ~] # mysqlbinlog --start-position=245 --stop-position=534 /mydata/data/mys
ql-bin.000016 >  /backup/binlog/binlog- ` date  +%F_%T`.sql

数据恢复

1
2
3
4
5
[root@MariaDB ~] # service mysqld stop
[root@MariaDB ~] # rm -rf /mydata/data/*
[root@MariaDB ~] # cp -a /backup/snap/* /mydata/data
[root@MariaDB ~] # service mysqld start
[root@MariaDB ~] # mysql < /backup/binlog/binlog-2015-05-21_20\:23\:41.sql

基于物理备份,数据恢复完成

xtrabackup(推荐)

Xtrabackup是由percona提供的mysql数据库备份工具,据官方介绍,这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。

特点:

(1)备份过程快速、可靠

(2)备份过程不会打断正在执行的事务

(3)能够基于压缩等功能节约磁盘空间和流量

(4)自动实现备份检验

(5)还原速度快

安装

1
[root@MariaDB ~] # yum install percona-xtrabackup-2.2.3-4982.el6.x86_64.rpm -y

创建最小权限备份用户

wKiom1Vd3BqRuEodAACzCGg7NKw014.jpg

备份过程

完全备份

1
2
3
4
5
[root@MariaDB ~] # innobackupex --user=bakupuser --password=bakuppass /backup/
innobackupex: Backup created  in  directory  '/backup/2015-05-21_21-55-08'
innobackupex: MySQL binlog position: filename  'mysql-bin.000017' , position 245
150521 21:55:16  innobackupex: Connection to database server closed
150521 21:55:16  innobackupex: completed OK!

wKiom1Vd5XHTrk7uAACqhpePaRQ631.jpg

如果出现如下错误,请在my.cnf文件[mysqld] 中添加innodb_log_file_size = 5M 并重启服务

1
2
3
InnoDB: Error: log  file  . /ib_logfile0  is of different size 5242880 bytes
InnoDB: than specified  in  the .cnf  file  50331648 bytes!
innobackupex: Error: The xtrabackup child process has died at  /usr/bin/innobackupex  line 2672.

增量备份

每个InnoDB的页面都会包含一个LSN信息,每当相关的数据发生改变,相关的页面的LSN就会自动增长。这正是InnoDB表可以进行增量备份的基础,即innobackupex通过备份上次完全备份之后发生改变的页面来实现

innobackupex命令会在备份目录中创建一个新的以时间命名的目录以存放所有的增量备份数据。另外,在执行过增量备份之后再一次进行增量备份时,其--incremental-basedir应该指向上一次的增量备份所在的目录

注:增量备份仅能应用于InnoDB或XtraDB表,对于MyISAM表而言,执行增量备份时其实进行的是完全备份

添加数据

wKiom1Vd6siC_h2JAACh2TBsIaI746.jpg

做增量备份

1
2
3
4
5
6
[root@MariaDB ~] # innobackupex --incremental /backup/ --incremental-basedir=/backup/201
5-05-21_21-55-08/
innobackupex: Backup created  in  directory  '/backup/2015-05-21_22-26-42'
innobackupex: MySQL binlog position: filename  'mysql-bin.000017' , position 788
150521 22:26:57  innobackupex: Connection to database server closed
150521 22:26:57  innobackupex: completed OK!

再次添加数据

wKiom1Vd7BbzKaWcAAC9iyCq3Qw920.jpg

再次做增量备份

1
2
3
4
5
6
[root@MariaDB ~] # innobackupex --incremental /backup/ --incremental-basedir=/backup/201
5-05-21_22-26-42/  #在第一次增量备份的基础上做增量备份
innobackupex: Backup created  in  directory  '/backup/2015-05-21_22-32-01'
innobackupex: MySQL binlog position: filename  'mysql-bin.000017' , position 1056
150521 22:32:10  innobackupex: Connection to database server closed
150521 22:32:10  innobackupex: completed OK!

wKiom1Vd-vHyXbBKAABkq3z_4kY487.jpg

数据恢复

准备阶段

一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此,此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态

“准备”(prepare)增量备份与整理完全备份有着一些不同,尤其要注意的是:

(1)需要在每个备份(包括完全和各个增量备份)上,将已经提交的事务进行“重放”。“重放”之后,所有的备份数据将合并到完全备份上。

(2)基于所有的备份将未提交的事务进行“回滚”。

于是,操作就变成了:

1
# innobackupex --apply-log --redo-only BASE-DIR

接着执行:

1
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1

而后是第二个增量:

1
# innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2

其中BASE-DIR指的是完全备份所在的目录,而INCREMENTAL-DIR-1指的是第一次增量备份的目录,INCREMENTAL-DIR-2指的是第二次增量备份的目录,其它依次类推,即如果有多次增量备份,每一次都要执行如上操作

wKiom1Vd81nAIeoUAABVi6V8loE804.jpg

完整备份准备

1
2
3
4
5
[root@MariaDB ~] # innobackupex --apply-log /backup/2015-05-21_21-55-08/
InnoDB: FTS optimize thread exiting.
InnoDB: Starting  shutdown ...
InnoDB: Shutdown completed; log sequence number 2766618
150521 23:02:43  innobackupex: completed OK!

增量备份准备

1
2
3
4
5
[root@MariaDB ~] # innobackupex --apply-log --redo-only /backup/2015-05-21_21-55-08/
[root@MariaDB ~] # innobackupex --apply-log --redo-only /backup/2015-05-21_21-55-08/ 
--incremental- dir = /backup/2015-05-21_22-26-42/
[root@MariaDB ~] # innobackupex --apply-log --redo-only /backup/2015-05-21_21-55-08/ 
--incremental- dir = /backup/2015-05-21_22-32-01/

恢复阶段

还原备份,即完全备份

1
2
3
[root@MariaDB ~] # innobackupex --copy-back /backup/2015-05-21_21-55-08/
[root@MariaDB ~] # chown -R mysql.mysql /mydata/data/
[root@MariaDB ~] # service mysqld start

测试数据是否恢复

wKiom1Vd-BiCuz8JAACAz3UA59k539.jpg

OK,数据恢复成功

The end

好了,MySQL/MariaDB数据库备份与恢复就总结到这里了,以上总结的三种方法各有各的特色,读者可根据实际需求进行选择,再啰嗦一句,实际生产环境中数据和二进制日志文件一定要分开存放。以上仅为个人学习整理,如有错漏,大神勿喷~~~



本文转自 北城书生  51CTO博客,原文链接:http://blog.51cto.com/scholar/1653792

相关文章
|
27天前
|
关系型数据库 MySQL Java
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
|
1月前
|
关系型数据库 MySQL 数据库连接
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
259 82
|
3天前
|
Java 关系型数据库 MySQL
JDK、Tomcat、MariaDB数据库和Profile多环境的配置与使用
以上就是JDK、Tomcat、MariaDB数据库和Profile多环境的配置与使用的基本步骤。这些步骤可能会因为你的具体需求和环境而有所不同,但是基本的思路是一样的。希望这些信息能够帮助你更好地理解和使用这些工具。
39 17
|
2天前
|
SQL 关系型数据库 MySQL
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL 数据库 SQL 语句调优方法详解(2-1)
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划,如使用 EXPLAIN 命令及理解关键指标;优化查询语句结构,包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识,如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章,强调 SQL 语句调优重要性。为提升数据库性能提供实用方法,适合数据库管理员和开发人员。
|
2天前
|
关系型数据库 MySQL 大数据
大数据新视界--大数据大厂之MySQL 数据库课程设计:MySQL 数据库 SQL 语句调优的进阶策略与实际案例(2-2)
本文延续前篇,深入探讨 MySQL 数据库 SQL 语句调优进阶策略。包括优化索引使用,介绍多种索引类型及避免索引失效等;调整数据库参数,如缓冲池、连接数和日志参数;还有分区表、垂直拆分等其他优化方法。通过实际案例分析展示调优效果。回顾与数据库课程设计相关文章,强调全面认识 MySQL 数据库重要性。为读者提供综合调优指导,确保数据库高效运行。
|
1月前
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
1月前
|
SQL 关系型数据库 MySQL
MySQL生产环境迁移至YashanDB数据库深度体验
这篇文章是作者将 MySQL 生产环境迁移至 YashanDB 数据库的深度体验。介绍了 YashanDB 迁移平台 YMP 的产品相关信息、安装步骤、迁移中遇到的各种兼容问题及解决方案,最后总结了迁移体验,包括工具部署和操作特点,也指出功能有优化空间及暂不支持的部分,期待其不断优化。
|
2月前
|
监控 关系型数据库 MySQL
云数据库:从零到一,构建高可用MySQL集群
在互联网时代,数据成为企业核心资产,传统单机数据库难以满足高并发、高可用需求。云数据库通过弹性扩展、分布式架构等优势解决了这些问题,但也面临数据安全和性能优化挑战。本文介绍了如何从零开始构建高可用MySQL集群,涵盖选择云服务提供商、创建实例、配置高可用架构、数据备份恢复及性能优化等内容,并通过电商平台案例展示了具体应用。
|
30天前
|
存储 SQL 关系型数据库
从 MySQL 到时序数据库 TDengine:Zendure 如何实现高效储能数据管理?
TDengine 助力广州疆海科技有限公司高效完成储能业务的数据分析任务,轻松应对海量功率、电能及输入输出数据的实时统计与分析,并以接近 1 : 20 的数据文件压缩率大幅降低存储成本。此外,taosX 强大的 transform 功能帮助用户完成原始数据的清洗和结构优化,而其零代码迁移能力更实现了历史数据从 TDengine OSS 与 MySQL 到 TDengine 企业版的平滑迁移,全面提升了企业的数据管理效率。本文将详细解读这一实践案例。
45 0
|
2月前
|
SQL 关系型数据库 MySQL
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。

热门文章

最新文章