Mysql 备份与恢复

Mysql Backup and Recover

Table of Contents

• 1. 备份简介
  • 1.1. 备份分类
  • 1.2. 备份工具
• 2. 逻辑备份与恢复
  • 2.1. 备份
    • 2.1.1. 参数说明
    • 2.1.2. 使用示例
  • 2.2. 恢复
• 3. 物理备份与恢复
  • 3.1. percona-xtrabackup
    • 3.1.1. 版本兼容性
    • 3.1.2. 安装
    • 3.1.3. 参数详解
    • 3.1.4. 备份与恢复
  • 3.2. mariabackup
    • 3.2.1. 参数详解
    • 3.2.2. 使用mariabackup搭建主从复制
    • 3.2.3. 增量备份与恢复

1 备份简介

 

1.1 备份分类

数据库备份，分为冷备、热备，全备与增量备份，逻辑备份与物理备份。 以上三种不同的说法，是由于侧重点不同:

类型	侧重点
冷备与热备	数据库是否仍提供服务。不提供服务为冷备,提供服务的同时进行备份为热备
全备与增量备份	备份所有数据为全量，只备份自上次全量备份以来的有变动的数据为增量
逻辑备份与物理备份	取数据方式：逻辑从数据库取出数据然后以某种格式存储
	物理备份直接拷贝数据文件

1.2 备份工具

现在主流的备份工具是mysqldump 和extrabackup(mariabackup). 其中 mysqldump 是逻辑备份工具，将数据从数据库中读取出，然后输出到文本文件。我们可以使用日常的文本编辑工具 直接查看和编辑。

而xtrabackup 是percona 公司开发的Mysql物理备份开源工具。但是随着MySQL被Oracle收购后，原MySQL之父， 重新开发了一款MySQL: MariaDB, 成为MySQL系列数据中的一个重要分支。不仅支持MySQL的所有功能，还拥有MySQL 所不支持的存储引擎，以及拥有更强大的性能。xtrabackup 目前不支持10.1.23之后的版本，因为Mariadb的新特性。 所以Mariadb在xtrabackup的基础上进行了二次开发，并集成到安装包里。该工具支持MySQL数据库的全备和增量备份。

2 逻辑备份与恢复

mysqldump 在不同的分支及版本中, 参数可能不尽相同，但是大部分功能及作用是相同的。 下面是Mariadb 10.2.5 中的Mysqldump的基本用法、参数说明及示例。

2.1 备份

mysqldump 的基本使用方法:

Usage: mysqldump [OPTIONS] database [tables]
OR     mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR     mysqldump [OPTIONS] --all-databases [OPTIONS]

2.1.1 参数说明

这里只列出日常使用的参数,

参数缩略	参数全称	说明
-A	–all-databases	导出所有的数据库,包括系统自带的数据
-Y	–all-tablespaces	导出所有的表空间
-y	–no-tablespaces	不导出表空间信息
	–add-drop-database	在create database语句之前先输出drop database语句
	–add-drop-table	在建表语句之前，有删除表的SQL(DROP TABLE IF EXISTS)
		默认打开
	–add-drop-trigger	创建触发器之前，如果有同名触发器，先删除
	–add-locks	插入数据前，先锁表，默认打开,使用–skip-add-locks关闭
	–allow-keywords	导出时，允许关键词作为表的字段名
	–apply-slave-statements	导出的内容, 在change master语句之前，先输出stop slave
		并且将 start slave 放到导出文件的末尾
-B	–databases	导出指定数据库，多个数据库名之间使用空格分隔
	–default-character-set	指定默认字符集
	–delayed-insert	使用 INSERT DELAYED 语法插入数据
	–dump-slave[=#]	此参数只适用于从节点. 值为1, 会输出"change master"命令,
		值为2,"change master"命令会被注释掉。同时会自动启用
		–lock-all-tables，除非使用了–single-transaction
-F	–flush-logs	将内存中的数据写入磁盘，需要注意的是,如果导出多个数据库
		需要配合–lock-all-tables或者 –master-data参数使用
		否则，每导出一个库就会执行一次flush logs
	–gtid	使用gtid 替代 master_log信息,与–master-data 或者
		–dump-slave配合使用
	–ignore-table	不导出某张表
	–include-master-host-port	与–dump-slave配合使用, 导出时，将mast_host,
		master_port 信息补全,默认是没有的
-x	–lock-all-tables	在导出数据过程中对所有表执行read lock锁。并自动关闭
		–sgingle-transaction和–lock-tables
-l	–lock-tables	对所有表执行read lock，默认开启，可使用
		–skip-lock-tables关闭
	–master-data	连接主库备份时使用, 值为1, 输出change master 命令
		到文件，值为2时，change master 命令被注释。使用此
		选项，会自动开启–lock-all-tables, 除非另外指定了
		–single-transaction,在5.3之前，即使如此，也会
		在刚开始时，有个短暂的全局的read lock.
	–max-allowed-packet	与服务器数据交换时单次包最大容量,一般用于性能优化
	–net-buffer-length	网络buffer大小，一般用于性能优化
-n	–no-create-db	导出内容不包含create database语句
-t	–no-create-info	导出内容，不包含create table语句
-d	–no-data	不导出表里的数据
	–no-data-med	不导出管理外部数据的存储引擎信息，默认开启，
		可以通过–skip-no-data-med关闭
	–order-by-primary	导出的数据按照主键排序(如果有的话),但是导出时间明显加长
-p	–password	MySQL用户密码
-P	–port	mysql 端口
-q	–quick	不查询buffer,直接导出
	–replace	使用replace into语句代替insert into语句
-r	–result-file	将导出内容输出到该文件
-R	–routines	导出函数和存储过程
	–single-transaction	单事务处理，保证数据一致性,会自动关闭–lock-tables.
		仅支持InnoDB
	–dump-date	记录导出时间，默认开启，使用–skip-dump-date可关闭
	–skip-opt	关闭部分默认选项，比如 –add-drop-table, –add-locks,
		–create-options, –quick, –extended-insert,
		–lock-tables, –set-charset, and –disable-keys.
-S	–socket	指定用于连接MySQL的socket file
-T	–tab	只有在MySQL服务器上导出时生效，每张表一个文件
–tables		导出表，替代-B(–datebases)选项
–triggers		导出表时，导出与之相关的触发器，默认开启
		使用–skip-triggers关闭
-u	–user=name	连接MySQL的用户
-v	–verbose	导出时，输出每个阶段的明细
-V	–version	输出Mysqldump的版本
-w	–where=name	根据where指定的条件，导出查询结果

2.1.2 使用示例

• 备份所有库

  mysqldump -uroot -proot --all-databases -r alldb.sql
  

• 备份指定数据库

  mysqldump -uroot -proot -B test -r structure.sql
  

• 备份表

  mysqldump -uroot -proot --tables test.a1 test.a2 > tables.sql
  

• 备份表中部分数据

  mysqldump -uroot -proot --tables test.a1 test.a2 --where="create_date>'2019-01-01'" -r partial_data.sql
  

• 备份函数与存储过程

  mysqldump -uroot -proot --routines --no-create-db --no-data --no-tablespaces --no-create-info -r routines.sql
  

• 备份结构但是不备份数据

  mysqldump -uroot -proot -B test --no-data > structure_$(date "+%Y%m%d_%H%M%S").sql
  

2.2 恢复

逻辑备份的恢复非常简单，因为备份的结果是可读取的sql文件。可以通过mysql 的 source 命令执行, 不过一般使用"<"来进行恢复。假如备份文件是test.sql,恢复 示例如下:

mysql -uroot -proot < test.sql

3 物理备份与恢复

mysql 物理库的物理备份，特别要感谢percona公司开发的xtrabackup 工具，使Mysql 具备 了不停机物理备份(热备)的能力。

而Mariadb在xtrabackup的基础上进行了二次开发。使其能够在10.1.23及之后的版本中进行 在线热备。

3.1 percona-xtrabackup

xtrabackup 只支持innodb和XtraDB 存储引擎。虽然现在innodb 是最流行的。但是为了 追求速度，很多数据库会使用MYSIAM存储引擎。为了支持MYSIAM，我们可以使用innobackupex.

Percona 在2.3 版本用C重写了 innobackupex ，innobackupex 功能全部集成到 xtrabackup 里面，只有一个 binary，另外为了使用上的兼容考虑，innobackupex 作为 xtrabackup 的一个 软链接。版本2.3 摆脱了之前2个进程协作的负担，架构上明显要好于之前版本，该版本之后推荐使用 xtrabackup 脚本进行备份。

3.1.1 版本兼容性

mysql5.1在源码中配备了两个版本的innodb存储引擎源码：innobase和innodb_plugin，编译安装的时候可以通过参数 –with-plugins=innobase,innodb_plugin来指定将innodb存储引擎引入，具体这两个参数引入对编译后的mysql产 生怎样的差异，后面再做解析。然而对于Percona XtraBackup，在release版本中有2.0，2.1，2.2三个大版本，然后每 个版本都是与mysql发布的innodb存储引擎版本对应，举例来说：

percona-xtrabackup-2.0.8在BUILD.txt中指定了utils/build.sh参数如下：

Build an xtrabackup binary against the specified InnoDB flavor.

Usage: build.sh CODEBASE
where CODEBASE can be one of the following values or aliases:
  innodb50         | 5.0                   build against innodb 5.1 builtin, but should be compatible with MySQL 5.0
  innodb51_builtin | 5.1                   build against built-in InnoDB in MySQL 5.1
  innodb51         | plugin                build against InnoDB plugin in MySQL 5.1
  innodb55         | 5.5                   build against InnoDB in MySQL 5.5
  innodb56         | 5.6,xtradb56,         build against InnoDB in MySQL 5.6
                   | mariadb100
  xtradb51         | xtradb,mariadb51      build against Percona Server with XtraDB 5.1
                   | mariadb52,mariadb53
  xtradb55         | galera55,mariadb55    build against Percona Server with XtraDB 5.5

而在percona-xtrabackup-2.1.9在BUILD.txt中指定了utils/build.sh参数如下：

The script needs the codebase for which the building is targeted, you must
provide it with one of the following values or aliases:

  ================== =========  =============================================
  Value              Alias      Server
  ================== =========  =============================================
  innodb51           plugin build against InnoDB plugin in MySQL 5.1
  innodb55           5.5    build against InnoDB in MySQL 5.5
  xtradb51           xtradb     build against Percona Server with XtraDB 5.1
  xtradb55           xtradb55   build against Percona Server with XtraDB 5.5
  innodb56           5.6        build against InnoDB in MySQL 5.6
  ================== =========  =============================================

从以上两个版本对比中，我们知道，从2.1版本开始，percona-xtrabackup 取消对Mysql innodb51_builtin 的支持。

因此在安装percona xtrabackup 的时候，要先确认即将安装的xtrabackup版本是否支持当前的MySQL版本。

3.1.2 安装

• 下载 perconna-xtrabackup
• 下载Mysql 源码包。 因为perconna-xtrabackup 版本与mysql 版本是有对应关系的。如果不知道需要安装哪个版本，可以先进行安装，在 没有mysql 源码包的情况下，会有提示

• 安装 示例如下：

  wget https://www.percona.com/downloads/XtraBackup/XtraBackup-2.1.9/source/percona-xtrabackup-2.0.8.tar.gz
  tar -xf percona-xtrabackup-2.0.8.tar.gz
  cd percona-xtrabackup-2.0.8
  wget https://cdn.mysql.com/archives/mysql-5.1/mysql-5.1.59.tar.gz
  ./utils/build.sh 5.1
  cp ./innobackupex /usr/bin/
  cp ./usr/xtrabackup_51 /usr/bin/xtrabackup
  

3.1.3 参数详解

--apply-log
  通过应用录下的事务日志文件xtrabackup_logfile，在BACKUP-DIR目录准备一个备份。页建立一个新的事务日志文件。innoDB的配置是从innobackupex备份时建立的文件backup-my.cnf读取。
--close-files
  不保持文件被打开。默认备份时tablespace不关闭，但如果表空间很大并且不适合任何限制，有一个可选的方法是关闭不再访问的文件。使用该选项会产生不一致的备份。
--compact
  建立一个忽略耳机索引页的简洁备份。
--compress
建立一个innoDB数据文件的压缩备份。它直接提交给xtrabackup的子进程
--compres-threads=#
并行压缩的工作进场数量，它直接提交给xtrabackup的子进程
--compress-chunk-size=#
指定每个压缩进程的内部工作缓冲区的尺寸，用字节来测量。它直接提交给xtrabackup的子进程
--copy-back
复制所有的备份到他们原来的位置
--databases=LIST
指定将要备份的数据库列表。支持databasename.tablename格式，如果没指定参数，则备份所有数据库
--decompress
解压所有以选项--compress备份的，结尾是.qp的文件。使用参数--parallel允许多个文件同时被解密和或解压。
--decrypt=ENCRPYTION-ALGORITHM
解密用--encrpyt选项加密的以.xbcrypt结尾的文件。
--defaults-file=[my.cnf]
通过制定一个字符串来设置MySQL的默认选项
--defaults-extra-file=[my.cnf]
在从标准的默认文件中取值默认之前的额外文件。接收一个字符串作为选项
--defaults-group=GROUP-NAME
如果用了Mysqld_multi，可设置读取配置文件的特定组
--encrypt=ENCRYPTION-ALGORITHM
该选项指引xtrabackup使用参数ENCRYPTION_ALGORITHM参数制定的算法，加密innoDB数据文件的备份，它直接指向子进程
--encrypt-key=ENCRYPTION_KEY
指示xtrabackup在备份时使用ENCRYPTION_KEY指定的key做--encrypt加密。它直接传给子进程
--encrypt-key-file=ENCRYPTION_KEY_FILE
当用选项--encrpyt加密时使用存储在ENCRYPTION_KEY_FILE里存储的加密key
--encrypt-threads=#
指定并行加密的工作线程数。它直接传给子进程
--encrypt-chunk-size=#
指定每个加密进程使用的内粗工作缓冲区的尺寸，以字节计算大小
--export
它用于导出单个表用于导入另一个server
--extra-lsndir=DIRECTORY
指定xtrabackup_checkpoints文件的保留目录
--force-non-empty-directories
  该参数使得选项--copy-back or --move-back选项传输文件到非空目录。不存在的文件将被覆盖。如果选项--copy-back or --move-back必须从备份目录到一个已经存在的目标目录，则将失败
--galera-info
  该选项在备份时建立包含本地节点状态xtrabackup_galera_info文件。用于执行Percona-XtraDB-Cluster备份
--host=HOST
  执行通过TCP/IP连接访问数据库的主机，它传给mysql的子进程
--ibbackup=IBBACKUP-BINARY
  接收字符串参数，它用来指定要使用的xtrabackup binary、
--include=REGEXP
  指定一个正则表达式，用语匹配格式为databasename.tablename的表名称，它传递给--tables选项
--incremental
  建立一个增量备份，传递给xtrabackup的子进程。该参数可以和参数--incremental-lsn or --incremental-basedir配合使用。
--incremental-basedir=DIRECTORY
  指定一个包换全库备份的目录作为增量备份的基础数据库
--incremental-dir=DIRECTORY
  指定增量备份与全库备份合并去建立一个新的全备份的目录。
--incremental-lsn=LSN
  指定增量备份将要开始的LSN，它替代选项--incremental-basedir
--kill-long-queries-timeout=SECONDS
  该选项指定innobackupex在开始FLUSH TABLES WITH READ LOCK和杀掉这些阻碍他的查询之间的时间的等待时间，以秒计算，默认为0，意味着innobackupex不尝试杀任何查询，
  该选项需要process and super权限
--kill-long-query-type=all|select
  指定解锁全局锁时将被杀掉的查询类型，默认是all
--lock-wait-timeout=SECONDS
  运行FLUSH TABLES WITH READ LOCK之前，innobackupex等待阻塞查询的时间数(秒数)
--lock-wait-threashold=SECONDS
  选项指定查询运行时间阀值，当innobackupex发现长运行查询伴随着--lock-wait-timeout的一个非0值，
--lock-wait-query-type=all|update
  指定innobackupex发出一个全局锁之前什么类型的查询允许完成
--lock-copy-interval=#
  指定日志日志复制线程检车完成的时间间隔，以毫秒计算
--move-back
  移动之前的所有备份从一个备份目录到他们的原始位置
--no-lock
  不允许使用flush tables with read lock表锁。如果你的所有表示INNODB并且你不关心二进制日志备份的位置。如果有任何DDL语句被执行或任何非INNODB表上的update操作，这个选项就不能使用
--notimestamp
  把备份放在一个通过选项backup-root-dir指定的子目录里
--no-version-check
  禁止版本检查
--parallel=NUMBER-OF-THREADS
  该选项接收一个整数，xtarbackup子进程将用于同时备份文件的并发数。如果有多个.ibd文件可以并行，如果只有一个表空间文件，则该选项无效
--password=PASSWORD
  指定连接到数据库的账户密码
--port=PORT
  该选项指定通过TCP/IP连接到数据库时所用的端口
--rebuild-indexes
  只有用--apply-log选项时它才有效，当应用日志后使得xtrabackup重建所有的二级索引。一般用于准备简约备份
--rebuild-threas=NUMBER-OF-THREADS
  当一起使用选项--apply-log and --rebuild-indexes选项时才有用，使用后，当重建索引时，xtrabackup处理表空间时用一定数量的线程的并行模式
--redo-only
  选项用于准备全库备份和合并处最有一个备份外的所有增量备份。它强制xtrabackup忽略“rollback”阶段只做“redo”.
--rsync
  使用rsync工具优化本地文件传输。它让xtrabackup使用rsync复制所有非innoDB文件，而不是使用多个cp
--safe-slave-backup
  停止从SQL进程并等待启动备份直到slave_open_temp_tables的值为0。如果没有打开临时表，备份会进行，否则SQL进程将启动并直到没有打开的临时表时停止。如果slave_open_temp_tables在--
safe-slave-backup-timeout秒后没有变成0，则备份会失败。备份结束后，从SQL进程将重新启动
--safe-slave-backup-timeout=SECONDS
  --safe-slave-backup要等slave_open_temp_tables变成0的时间，默认为300秒
--scopt=SCP-OPTIONS
  当参数--remost-host指定时传递给scp的参数
--slave-info
  当备份一个复制从库操作的时候用，它打印二进制日志的position和主库的名字，它页把这些信息写入xtrabackup_slave_info文件作为一个CHANGE MASTER命令
--socket=SOCKET
  指定连接到本地数据库sever时使用的一个unix domain socket，它没有修改的传入mysql子进程
--sshopt=SSH-OPTIONS
  当使用参数--remost-host时，使用ssh的命令行参数
--stream=STREMNAME
  当使用流备份时使用的特定格式。备份将以特定格式传到STDOUT。支持的格式为tar and xbstream
--tables-file=FILE
  指定备份的表的列表，格式为database.tablename
--throttle=IOS
  指定I/O操作的数量/秒。该参数只适用于备份阶段。不适用于参数--apply-log,--copy-back
--tmpdir=DIRECTORY
  在参数--stream使用时指定，是指临时文件被存储的位置
--use-memory=#
  该参数只能和参数--apply-log配合使用，被用于xtrabackup做creash恢复时准备锁使用的内存量(单位：字节)。也支持其他单位，如：1MB,1M,1GB,1G
--user=USER
  指定连接到mysql时使用的用户名
--version
  显示innobackupex的版本信息和版权等信息
--version-check
  指定该选项后，innobackupex将在建立一个连接后，在备份阶段执行一个版本检查

3.1.4 备份与恢复

备份与恢复的示例与mariabackup的使用方法几乎是一样的。参见增量备份与恢复.

3.2 mariabackup

由于 xtrabackup不支持MariaDB的InnoDB页压缩和静态数据加密技术,所以Mariadb 基于 Percona XtraBackup 2.3.8 开发了开源产品 mariabackup ,并在MariaDB 10.1.23 和 MariaDB 10.2.7, GA版本 MariaDB 10.1.26 and MariaDB 10.2.10 中首次发布。 用于对InnoDB，Aria和MyISAM表进行物理在线备份.

mariabackup是集成在MariaDB安装包中的，因此不需要额外安装

3.2.1 参数详解

mariabackup的参数与extrabackup的参数用法与意义上基本相同，其使用方法与意义在下面 表格中进行详细说明。其中参数选项部分，在使用时，应在其前面加上“–”, 如："mariabackup –backup"。

如下：

参数选项	意义
apply-log-only	在10.1中，增量备份时可以使用此参数，与prepare使用,只应用
	apply stage的binlog,忽略crash recovery stage的binlog
	10.2及以后的版本中不再使用。
backup	执行备份操作,将生成的备份文件存放于target-dir指定的路径中
binlog-info	告诉mariabackup如何读取binlog的信息。有三个可用值：
	OFF: 不读binlog
	ON: 读取binlog,并在可以保证数据一致性的位置执行blocking
	AUTO: 读取binlog,并在支持的情况下使用ON或者lockless选项
	LOCKLESS: mariabackup不支持此值。
close-files	是否关闭文件句柄。打开时，mariabackup可以处理DDL。关闭时
	mariabackup对大文件的备份更加可控,但是有可能导致数据不一致
	,因此个人建议不关闭。保持默认打开状态。
compress	10.2.25中仍是可用的。但是在10.3官方文档中明确说明为
	deprecated.对应的解压参数也过期了。建议使用stream
	使用第三方的压缩库对数据流进行压缩，示例如下:
	备份时进行加密和压缩：
	mariabackup –user=root –backup –stream=xbstream |
	gzip | openssl enc -aes-256-cbc -k mypass >
	backup.xb.gz.enc
	解密和解压缩：
	openssl enc -d -aes-256-cbc -k mypass -in
	backup.xb.gz.enc | gzip -d| mbstream -x
copy-back	将备份恢复至datadir变量指向的路径。要求该路径为空。配合
	参数force-non-empty-directories可恢复至非空路径
core-file	当导出时遇到fatal signals,可以加上此参数，导出内核信息
	便于分析定位和解决问题。
databases	指定需要备份的数据或者表。对的，这个参数支持备份表，其语法:
	–databases="db[.table][db[.table] …]"
	如果要导出大部分库或者表，可以使用databases-exclude选项
	将不需要的库或者表过滤掉，用法与databases是一样的。
databases-file	将需要导出的库或者表放到一个文件中，通过此参数来指定该文件
datadir	指定数据文件路径。mariabackup将从这个路径读取数据进行备份
print-defaults	输出各种参数及变量的值，并退出备份程序
no-defaults	不读MySQL的参数文件。 也就是不读my.cnf文件
defaults-file	指定mariabackup默认读取的参数文件。指的是My.cnf文件,可以不
	用默认的my.cnf. 此参数应在其他所有参数之前。
defaults-extra-file	defaults-file读完后，读取此参数配置的参数文件,通过此参数
	文件可以修改 defaults-file中的默认配置
defaults-group	指定读取参数文件中的哪一部分内容。比如读取[mariabackup]
	中的配置。
export	与prepare配合使用,会生成一个cfg文件。针对file-per-table
	每个表文件(表空间)会生成一个cfg文件，该文件可用于恢复备份
	中的部分内容，比如某张表或者某个分区。
extra-lsndir	复制一份xtrabackup_checkpoints、xtrabackup_info到另
	外一个路径
force-non-empty-directories	与copy-back或者move-back配合使用。当datadir路径非空时
	使用此参数，将强制恢复到datadir路径。
ftwrl-wait-query-type	与backup配合使用,让mariabackup等待相对应的操作完成再
	执行global lock. 有三个可用值: all| update | select
ftwrl-wait-threshold	与ftwrl-wait-query-type配合使用，SQL执行时间大于此参数
	设置的值时，进入等待，直到ftwrl-wait-timeout的时间。
	前提是ftwrl-wait-timeout 大于0.
ftwrl-wait-timeout	默认0，表示不等待任何SQL执行完即执行global lock.
	单位秒。表示mariabackup最多等待时间，超过后不再等待。
incremental-basedir	对该路径进行增量备份(备份上次备份之后有修改过的文件)
	与backup参数配合使用。
incremental-dir	针对已经prepare的路径。对prepare路径进行增量处理。
	主要是应用.delta文件和binlog文件。
incremental-force-scan	与incremental-basedir配合使用，对将要备份的文件进行全
	扫描，即使有对应的位图信息(通过位图信息保存增量对比)
incremental-history-name	为每次增量指定一个逻辑名。
incremental-lsn	备份时只备份比lsn大的文件。
innobackupex	通过此参数，可以启用innobackupex的特性。
innodb-adaptive-hash-index	备份时开启innodb adaptive hash index,也是默认设置
	关闭此特性，使用–skip-innodb-adaptive-hash-index
innodb-autoextend-increment	备份文件自动扩展,每次扩展的大小，单位M。
verbose	输出备份日志明细
version	输出备份工具的版本号
target-dir	备份文件的存储路径
prepare	将备份文件进行数据一致性处理，以进行恢复。在完全备份的情况下
	文件不是时间点一致的，因为它们是在不同时间进行的快照,需要通
	mariabackup –prepare 处理成一致状态。增量恢复时，需要使用
	prepare命令和incremental-dir选项将增量备份应用到全备中去.

3.2.2 使用mariabackup搭建主从复制

默认场景

• 从库的 MariaDB 已安装,并配置好参数文件。
• 主库已运行一段时间,不方便停业务

1. 准备工作
   

   • 主库创建复制用户

     主库创建用于复制数据的用户;

     GRANT replication slave ON *.* TO 'rep1'@'10.1.61.10' IDENTIFIED BY 'repl123';
     

     note

     10.1.61.10 为从库IP。

   • 创建存储备份的路径

     在主备两端都需要创建。

     #创建备份路径, mysql 用户需要有权限访问
     mkdir -p /home/mysql/backup
     

   • 安装依赖包

     备库需要安装qpress工具(前提是备份时使用 compress 参数,如果不使用该参数也可以 ,只要空间足够). 请到qpress官网 下载最新版本。当前是 qpress-11 . 对于 Linux系统只需要以下三步:

     wget http://www.quicklz.com/qpress-11-linux-x64.tar
     tar xvf qpress-11-linux-x64.tar
     cp qpress /usr/bin
     

2. 备份主库
   

   • 备份

     mariabackup -uroot --backup --target-dir=/home/mysql/backup --all-databases --use-memory=10G
     

     备份示例:

     [root@tycxdb2 backup]#  mariabackup -uroot --backup --target-dir=/home/mysql/backup --all-databases --use-memory=10G
     [00] 2019-08-08 23:11:42 Connecting to MySQL server host: localhost, user: root, password: not set, port: not set, socket: not set
     [00] 2019-08-08 23:11:42 Using server version 10.2.25-MariaDB-log
     mariabackup based on MariaDB server 10.2.25-MariaDB Linux (x86_64)
     [00] 2019-08-08 23:11:42 uses posix_fadvise().
     [00] 2019-08-08 23:11:42 cd to /home/mysql/data/
     [00] 2019-08-08 23:11:42 open files limit requested 0, set to 1024
     [00] 2019-08-08 23:11:42 mariabackup: using the following InnoDB configuration:
     [00] 2019-08-08 23:11:42 innodb_data_home_dir =
     [00] 2019-08-08 23:11:42 innodb_data_file_path = ibdata1:12M:autoextend
     [00] 2019-08-08 23:11:42 innodb_log_group_home_dir = ./
     [00] 2019-08-08 23:11:42 InnoDB: Using Linux native AIO
     [00] 2019-08-08 23:11:42 using O_DIRECT
     ........ 内容过多省略 .....
     mariabackup: Stopping log copying thread.[00] 2019-08-08 23:45:00 >> log scanned up to (793437226795)
     
     [00] 2019-08-08 23:45:00 >> log scanned up to (793437226795)
     [00] 2019-08-08 23:45:00 Executing UNLOCK TABLES
     [00] 2019-08-08 23:45:00 All tables unlocked
     [00] 2019-08-08 23:45:00 Copying ib_buffer_pool to /home/mysql/backup/ib_buffer_pool
     [00] 2019-08-08 23:45:00         ...done
     [00] 2019-08-08 23:45:00 Backup created in directory '/home/mysql/backup/'
     [00] 2019-08-08 23:45:00 MySQL binlog position: filename 'mysql-bin.000939', position '48267434', GTID of the last change '0-22-190568113'
     [00] 2019-08-08 23:45:00 Writing backup-my.cnf
     [00] 2019-08-08 23:45:00         ...done
     [00] 2019-08-08 23:45:00 Writing xtrabackup_info
     [00] 2019-08-08 23:45:00         ...done
     [00] 2019-08-08 23:45:00 Redo log (from LSN 793366546585 to 793437226795) was copied.
     [00] 2019-08-08 23:45:00 completed OK!
     

     note

     • 物理备份的速度相当快,mysql datadir 路径218G 数据 34分钟备份完成,备份文件201G， 如果空间充足，建议不使用 compress 选项，虽然虽然节省了空间和传输时间，但是 解压耗时相当长, 另外不可以使用 prepare 选项对备份文件应用日志, 恢复到另外一个 数据库的时候会存在问题。
     • use-memory 可以加快导出的速度，但是要注意本机的可用物理内容。

   • 将备份传送至目标服务器

     scp /home/mysql/backup 192.168.111.20:/home/mysql/backup
     

3. 备份恢复
   

   • 数据文件一致性处理 在完全备份的情况下，文件不是时间点一致的，因为进行快照的时间点不一样。如果尝 试在未prepare数据的情况下还原数据库，虽然操作上支持恢复，但是在启动的时候仍会 进行数据recovery。

     运行带 /prepare/选项的 /mariabackup/命令会使数据文件进行统一，达到数据一 致性的目的，从而将其还原到MariaDB Server后不会有异常。

     使用增量备份时，需要 prepare 选项 和 incremental-dir 选项配合使用 以使用增量备份中的文件进行恢复。

     mariabackup --prepare --target-dri=/home/mysql/backup --user root
     

     示例:

       mariabackup --user root --prepare --target-dir=./
     mariabackup based on MariaDB server 10.2.25-MariaDB Linux (x86_64)
     [00] 2019-08-09 01:07:25 cd to /home/mysql/backup/
     [00] 2019-08-09 01:07:25 This target seems to be not prepared yet.
     [00] 2019-08-09 01:07:25 mariabackup: using the following InnoDB configuration for recovery:
     [00] 2019-08-09 01:07:25 innodb_data_home_dir = .
     [00] 2019-08-09 01:07:25 innodb_data_file_path = ibdata1:12M:autoextend
     [00] 2019-08-09 01:07:25 innodb_log_group_home_dir = .
     [00] 2019-08-09 01:07:25 InnoDB: Using Linux native AIO
     [00] 2019-08-09 01:07:25 Starting InnoDB instance for recovery.
     [00] 2019-08-09 01:07:25 mariabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Uses event mutexes
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Compressed tables use zlib 1.2.7
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Using Linux native AIO
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Number of pools: 1
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Using SSE2 crc32 instructions
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Completed initialization of buffer pool
     2019-08-09  1:07:25 139813501150976 [Note] InnoDB: page_cleaner coordinator priority: -20
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Highest supported file format is Barracuda.
     2019-08-09  1:07:25 139813761947776 [Note] InnoDB: Starting crash recovery from checkpoint LSN=793366562214
     2019-08-09  1:07:27 139813761947776 [Note] InnoDB: Starting a batch to recover 7054 pages from redo log.
     2019-08-09  1:07:40 139813559899904 [Note] InnoDB: To recover: 2396 pages from log
     2019-08-09  1:07:55 139813761947776 [Note] InnoDB: Read redo log up to LSN=793393743872
     2019-08-09  1:07:55 139813761947776 [Note] InnoDB: Starting a batch to recover 6218 pages from redo log.
     2019-08-09  1:08:10 139813543114496 [Note] InnoDB: To recover: 1785 pages from log
     2019-08-09  1:08:21 139813761947776 [Note] InnoDB: Starting final batch to recover 3572 pages from redo log.
     2019-08-09  1:08:25 139813559899904 [Note] InnoDB: To recover: 1325 pages from log
     2019-08-09  1:08:29 139813761947776 [Note] InnoDB: Last binlog file './mysql-bin.000939', position 48267434
     [00] 2019-08-09 01:08:30 Last binlog file ./mysql-bin.000939, position 48267434
     

   • 恢复数据

     mariabackup --defaults-file=/etc/my.cnf --rsync --copy-back --target-dir=/home/mysql/backup/
     

     这里的copy-back 的目标路径是 –defualts-file 中匹配的datadir。就是从target-dir中将备份恢复到 datadir中。

   • 启动从库

     systemctl start mysqld
     

   • 建立主从复制关系

     1. 查看主的binlog起始点 由于之前准备工作中已经创建了复制用户, 这一步只需要修改从库的master信息。而 master 信息我们通过备份文件中的 xtrabackup_binlog_info 文件来查看。 文件内容示例:

        # cat xtrabackup_binlog_info
        mysql-bin.000938        658662639       0-22-190059068
        

        第一列对应master_log_file，第二列对应master_log_pos, 第三列主gtid值。

     2. 启动从库MySQL

        systemctl start mysqld
        

        copy-back 后，首次启动,可能会花费比较长的时间，因为要进行数据一致性处理。 也可能仅一次启动无法完成数据recover,需要多次重新启动。 启动时,注意观察日志,示例如下:

             ...........
        2019-08-08 22:37:41 140011134244608 [Note] InnoDB: To recover: 3497 pages from log
        2019-08-08 22:39:26 140012383484032 [Note] InnoDB: 5 transaction(s) which must be rolled back or cleaned up in total 22784714 row operations to undo
        2019-08-08 22:39:26 140012383484032 [Note] InnoDB: Trx id counter is 383051520
        2019-08-08 22:39:26 140012383484032 [Note] InnoDB: Starting final batch to recover 2661 pages from redo log.
        2019-08-08 22:39:26 140011159422720 [Note] InnoDB: To recover: 2660 pages from log
        2019-08-08 22:39:29 140012383484032 [Note] InnoDB: Last binlog file './mysql-bin.000938', position 658662639
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: 128 out of 128 rollback segments are active.
        2019-08-08 22:39:30 140011067102976 [Note] InnoDB: Starting in background the rollback of recovered transactions
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Creating shared tablespace for temporary tables
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: Waiting for purge to start
        2019-08-08 22:39:30 140012383484032 [Note] InnoDB: 5.7.26 started; log sequence number 793713315141
        2019-08-08 22:39:30 140010019874560 [Note] InnoDB: Loading buffer pool(s) from /home/mysql/data/ib_buffer_pool
        2019-08-08 22:39:30 140012383484032 [Note] Plugin 'FEEDBACK' is disabled.
        2019-08-08 22:39:30 140012383484032 [Note] Semi-sync replication initialized for transactions.
        2019-08-08 22:39:30 140012383484032 [Note] Semi-sync replication enabled on the master.
        2019-08-08 22:39:30 140012383484032 [Note] Recovering after a crash using tc.log
        2019-08-08 22:39:30 140012383484032 [Note] Starting crash recovery...
        2019-08-08 22:39:30 140012383484032 [Note] Crash recovery finished.
        2019-08-08 22:39:30 140012383484032 [Note] Server socket created on IP: '::'.
        2019-08-08 22:39:30 140012383484032 [Note] Reading of all Master_info entries succeeded
        2019-08-08 22:39:30 140012383484032 [Note] Added new Master_info '' to hash table
        2019-08-08 22:39:30 140012383484032 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
        Version: '10.2.25-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution
        2019-08-08 22:39:30 140010019874560 [Note] InnoDB: Buffer pool(s) load completed at 190808 22:39:30
        

     3. 配置主从关系

     change master to master_host='10.1.61.9',master_port=3306,master_user='rep1',master_password='repl123',master_log_file='mysql-bin.000938',master_log_pos=658662639;
     

   • 开始主从复制

     启动主从复制，并确认复制进程是否正常。

     mysql -e "start slave; show slave status\G"
     

3.2.3 增量备份与恢复

进行增量备份与恢复，首先要进行全量备份，再进行增量备份，然后将增量备份应用至全量备份。不支持压缩过的备份。

1. 全量备份

   mariabackup --backup --target-dir=/backup/fullbackup  -uroot -Proot
   

2. 增量备份

   mariabackup --backup --target-dir=/backup/incremental_backup \
    --incremental-basedir=/backup/fullbackup -uroot -Proot
   

3. prepare全量备份

   mariabackup -uroot -Proot --prepare --target-dir=/backup/fullbackup --apply-log-only
   

4. 合并全量备份与增量备份

   mariabackup -uroot -Proot --prepare --target-dir=/backup/fullbackup/ \
     --incremental-dir=/backup/incremental_backup/   --apply-log-only
   

5. 将合并好的文件复制到数据文件路径 恢复之前，先确认一下目标路径是否为空。尽量为空，若确实要恢复至不为空的路径中， 需要额外使用参数 –force-non-empty-directories .

   恢复的目标路径，默认是/etc/my.cnf 中的datadir配置。如果需要恢复到其他位置 可以使用 –datadir 选项重新指定数据文件路径。

   mariabackup -uroot -Proot --copy-back --target-dir=/backup/fullbackup/
   

   恢复完成后，注意查看datadir及其中文件的属组

Author: halberd

Created: 2019-08-23 Fri 19:00

Validate