适用于MySQL8版本的两种备份方式（mysqldump，Xtrabackup8）

Posted i鲸落i

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了适用于MySQL8版本的两种备份方式（mysqldump，Xtrabackup8）相关的知识，希望对你有一定的参考价值。

CentOS 7.9 + MySQL8.0 + mysqldump /  Xtrabackup8 备份回顾篇

# 注意低于 Xtrabackup8 的版本不适用与MySQL8以上版本

       今天给大家回顾一下mysql8的两种备份方式，第一种为逻辑备份，也就是自带的mysqldump 方法，另一种为物理备份XBK（Xtrabackup），废话不多说直接上干货~！

目录

数据库干货篇

备份的种类

一   mysqldump逻辑备份

开启二进制日志：

日志操作

mysqldump参数：

mysqlbinlog参数

二进制日志截取恢复

时间戳恢复

二  物理备份 XBK安装（Xtrabackup）

XBK备份原理及使用（Xtrabackup）

xtrabackup参数

全备

增量备份

恢复

MySQL8 模拟操作（#注意有风险不要在生产上随意操作，了解即可）

数据库干货篇

备份的种类

热备：

在数据库正常对外提供服务的时候进行备份，并且能够一致性的恢复，MySQL中的话现在只支持Innodb，这种方式对数据库影响很小。

冷备：

把数据库业务关闭进行备份，数据库没有数据变化的情况下进行数据备份。

温备：

相对于表影响，会锁表，只能读不能写，影响写的操作。

一   mysqldump逻辑备份

   mysqldump是mysql用于备份和数据转移的一个工具。它主要产生一系列的SQL语句，可以封装到文件，该文件 包含有所有重建你的数据库所需要的 SQL命令如CREATE DATABASE，CREATE TABLE，INSERT等等。

   可以用来 实现轻量级的快速迁移或恢复数据库。 mysqldump 是将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之 间升级时相对比较合适，这也是最常用的备份方法。

   mysqldump一般在数据量很小的时候（几个G）可以用于 备份。当数据量比较大的情况下，就不建议用mysqldump工具进行备份了，因为是针对于存储引擎，需要读取数据使用SQL语句进行数据转换，比较耗费系统资源，数据量太大了效率就比较低。

mysqldump是MySQL自带的备份方式无需下载

逻辑备份工具

mysqldump           备份工具
mysqlbinlog         二进制工具
逻辑备份=mysqldump+mysqlbinlog

开启二进制日志：

  在MySQL8中安装完成自动将二进制日志开启的，存放默认路径在：/var/lib/mysql/binlog

查看默认日志存放位置：

show variables like 'log_bin%';
# 查询结果：
+---------------------------------+-----------------------------+
| Variable_name                   | Value                       |
+---------------------------------+-----------------------------+
| log_bin                         | ON                          |
| log_bin_basename                | /var/lib/mysql/binlog       |
| log_bin_index                   | /var/lib/mysql/binlog.index |
| log_bin_trust_function_creators | OFF                         |
| log_bin_use_v1_row_events       | OFF                         |
+---------------------------------+-----------------------------+
# 详情
log_bin是二进制日志的开关,用来记录所有的修改数据的dml语句,以备恢复数据库和复制数据库使用.
如果不指定log_bin_basename,则binlog使用主机名命名binlog日志
==> log_bin_basename 二进制日志文件名
==> log_bin_index 二进制的索引文件名

      如果你想自定义存放位置，首先创建一个专门存放文件的文件夹，记得将属主属组改为mysql或者将文件夹的权限设置为777否则将会出现以服务无法启动的情况

修改配置文件 /etc/my.cnf 中间一行加入：

log_bin=你创建的文件夹路径/你起的日志名称
例如：
log_bin=/mysqldump/binlogs # 开启二进制日志
binlog_format=row   # 将日志格式设置为row

了解内容：

binlog_format格式：分为行级和语句级

     默认 statement 语句级，binlog会记录每次一执行写操作的语句。 相对row模式节省空间，但是可能产生不一致性，比如update tt set create_date=now() 如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。 优点： 节省空间 缺点： 有可能造成数据不一致。 设置 row后 行级， binlog会记录每次操作后每行记录的变化。 优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。 缺点：占用较大空间。

mixed模式(混合)

     实际上就是前两种模式的结合，在mixed模式下，mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在statement和row之间选一种。新版本中的statement level还是和以前一样，仅仅记录执行的语句。而新版本的mysql中对row level模式被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete 等修改数据的语句，那么还是会记录所有行的变更。

日志操作

清除日志

reset master;

查看全部日志

show binary logs;

查看当前再用日志

show master status;
+----------------+----------+--------------+------------------+-------------------+
| File           | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------+----------+--------------+------------------+-------------------+
| binlogs.000001 |     1845 |              |                  |                   |
+----------------+----------+--------------+------------------+-------------------+
# binlog_do_db：此参数表示只记录指定数据库的二进制日志，默认全部记录。
# binlog_ignore_db：此参数表示不记录指定的数据库的二进制日志。
# Executed_Gtid_Set：已经执行的事务编号

mysqldump参数：

# -A 全库备份
mysql -uroot -p123456 -A > ./test.sql
# --all-databases 全库备份
mysqldump  -uroot -p --all-databases > ./test.sql
# -B 单库备份
mysqldump -uroot -p123456 -B test > ./test.sql
# -R 备份存储过程和函数 
mysqldump -uroot -p123456 -B test -R > ./test.sql # 将-B换成-A也行
# --add-drop-database 在每个创建数据库之前添加drop语句
mysqldump  -uroot -p123456 -B test --add-drop-database > test.sql
# /*!40000 DROP DATABASE IF EXISTS `test`*/;  /*  #找到文件中的这一行
# --add-drop-table 每个数据表创建之前添加drop数据表语句。(默认为打开状态，使用--skip-add-drop-table取消选项)
mysqldump  -uroot -p123456 -B test --skip-add-drop-table > test.sql
# --events, -E 导出事件
mysqldump  -uroot -p123456 -B test --events > test.sql
mysqldump  -uroot -p123456 -B test -E > test.sql
#--triggers 导出触发器。该选项默认启用，用--skip-triggers禁用它
mysqldump  -uroot -p123456 sql--all-databases --triggers > test.sql
# --no-data 只备份表结构
mysqldump -uroot -p123456 --no-data -B test > test.sql
# gzip压缩 
mysqldump -hhostname -uroot -p123456 test | gzip > mysqlbackup.sql.gz\\
# gzip 导入到数据库
gunzip < test.sql.gz | mysql -uroot -p123456 test;
# 导入倒数备份文件
mysql -uroot -p123456  < test.sql  # 从外面导入
source  /root/db_name.sql;  # 需要登录到数据库，这里注意要绝对路径

#什么是存储过程（MySQL---存储过程详解_ʜғ的博客-CSDN博客_mysql存储过程）

#什么是触发器（MySQL数据库8（二十七）触发器 - 帅的雅痞 - 博客园）

#什么是GTID全局事务标识符(超详细的mysql数据库GTID介绍—概念、优缺点、原理、生命周期等（好文章！！）_HD243608836的博客-CSDN博客_gtid)

mysqlbinlog参数

#使用方法 例如  mysqlbinlog -vv + 日志 > 1.sql
-v  
   # 会显示dml语句具体做了什么操作,例如：insert语句,会显示出insert具体插入了什么数据;
   # 但是看不到完整的dml语句,例如：insert into t1(id) values(1);
   # 但还是会看到dml语句的"伪"sql语句，也看不懂;
​
-vv
   # 会显示dml语句具体做了什么操作,例如：insert语句,会显示insert具体插入了什么数据;
   # 且可以看到完整的dml语句,例如：insert into t1(id) values(1);
   # 但还是会看到dml语句的"伪"sql语句
​
--base64-output=decode-rows
   # 看不到dml语句的"伪" SQL语句
   # 看不到dml语句具体操作了什么数据
​
​
######## -v -vv --base64-output结合使用
-v --base64-output=decode-rows 
   # 看得到dml语句具体做了什么操作(例如:insert时具体插入了什么数据)
   # 看不到dml语句的完整sql语句(例如：insert into t1(id) values(1);)
   # 看不到dml语句的"伪"sql语句
​
-vv --base64-output=decode-rows
   # 看得到dml语句具体做了什么操作(例如:insert时具体插入了什么数据)
   # 看得到dml语句的完整sql语句(例如：insert into t1(id) values(1);),但是被注释掉了的;
   # 看不到dml语句的"伪"sql语句
# DML(insert(插入) update（改） delete（删）)
​
--stop-datetime 
#表示某个时间之前的全部执行
--start-datetime 
#表示某个时间开始执行下面的日志内容
--skip-gtids=true 
# 是否保留GTID信息，如果为true表示恢复数据时将这些事务看作新事务，会生成新的GTID。常用于目标数据库和源数据库有相同GTID信息的情况，需要指定为true跳过这些GTID，否则会因为这些GTID已经在源数据库执行过了而不会执行（根据GTID的特性，同一个GTID只能执行一次）。如果是恢复到其他实例并且不包含源实例的 GTID 信息，那么使用或者不使用都可以恢复成功
--start-position   --stop-position
# 指定时间节点，需要注意的是--stop-datetime所指定的时间节点并不包含该时间执行的事务，而是前一个事务，在进行还原的时候需要注意正确的位置

二进制日志截取恢复

mysqlbinlog --start-position=1061 --stop-position=1676 binlogs.000001 > test.sql
# set sql_log_bin=0; 暂时关闭写入日志,注意不用的话 恢复途中也会写入日志，造成日志过大

时间戳恢复

首先模拟误删数据

delete from test2 where id=2;
mysqlbinlog --stop-datetime='2022-09-29 14:39:03' binlogs.000001 > 2.sql
# set sql_log_bin=0; 暂时关闭写入日志

然后在日志中找到误删除前的时间

# 将日志导入到文件内查看找到对应日期
mysqlbinlog -vv binlogs.000001  > 1.sql
#将时间选中
mysqlbinlog --stop-datetime="2022-09-28 17:09:56" binlogs.000001 >2.sql
# set sql_log_bin=0; 暂时关闭写入日志

开启GTID事务

#在my.cnf配置文件中增加GTID参数,确保重启不会失效
gtid-mode=ON    # 开启gtid模块
enforce-gtid-consistency=ON  # 开启 gtid一致性

事务恢复

mysqlbinlog --skip-gtids --include-gtids='cd767e3e-3f06-11ed-82db-000c29b67ac3:2-6' binlogs.000001 > test.sql
# set sql_log_bin=0; 暂时关闭写入日志

二  物理备份 XBK安装（Xtrabackup）

​
# 官方安装操作文档 请参考

https://docs.percona.com/percona-xtrabackup/8.0/installation/yum_repo.html
​
# 当然如果嫌麻烦可以直接从我的网站下载一键直接安装 哈哈~ 以下是安装方式


https://www.bdqn.vip/download_one/Xtrabackup8.tar.gz
# 下载好后解压


tar xf ./Xtrabackup8.tar.gz
# 安装

cd XBK && yum -y localinstall *.rpm
# 启用存储库 # 必须启动否则用不成


percona-release enable-only tools release
#想用最新版 

yum install percona-xtrabackup-80  # 当然你想用最新版可以直接下载，自动就替换了 ，这是更新的命令哦

xtrabackup -version # 查看版本号 
​

XBK备份原理及使用（Xtrabackup）

        前面介绍mysqldump备份方式是采用逻辑备份，其最大的缺陷就是备份和恢复速度都慢，对于一个小于50G的 数据库而言，这个速度还是能接受的，但如果数据库非常大，那再使用mysqldump备份就不太适合了。 这时就 需要一种好用又高效的工具，xtrabackup就是其中一款，号称免费版的InnoDB HotBackup。 Xtrabackup实现是 物理备份，而且是物理热备 目前主流的有两个工具可以实现物理热备：ibbackup和xtrabackup；ibbackup是商 业软件，需要授权，非常昂贵。而xtrabackup功能比ibbackup还要强大，但却是开源的。因此我们这里就来介 绍xtrabackup的使用。 Xtrabackup提供了两种命令行工具： xtrabackup：专用于备份InnoDB和XtraDB引擎的 数据； innobackupex：这是一个perl脚本，在执行过程中会调用xtrabackup命令，这样用该命令即可以实现备 份InnoDB，也可以备份MyISAM引擎的对象。 Xtrabackup是由percona提供的mysql数据库备份工具，特点： (1)备份过程快速、可靠； (2)备份过程不会打断 正在执行的事务； (3)能够基于压缩等功能节约磁盘空间和流量； (4)自动实现备份检验； (5)还原速度快。

官方 链接地址：Percona – The Database Performance Experts；

xtrabackup的七大特点

1.直接拷贝物理文件，备份和恢复数据的速度非常快、安全可靠

2.在备份期间执行的事务不会间断，备份InnoDB数据不影响业务

3.备份期间不增加太多数据库的性能压力

4.支持对备份的数据自动校验

5.支持全量、增量、压缩备份及流备份

6.技持在线迁移表以及快速创建新的从库

7.支持几乎所有版本的MySQL和MariaDB

xtrabackup参数

参数值 参数用途
–print-defaults 输出mysql实例的参数配置信息
–no-defaults    不从任何配置文件中读取参数信息，除了登录文件
–defaults-file=#    仅从指定的配置文件读取参数
–defaults-extra-file=#  读取额外的配置信息文件
–defaults-group-suffix=#    Also read groups with concat(group, suffix)
–login-path=#   读取登录文件的路径
-v, --version   打印 xtrabackup版本信息
–target-dir=name    备份文件的目录，默认为当前目录xtrabackup_backupfiles/
–backup 备份操作,备份到target-dir指定的目录
–stats  计算datadir的统计信息(推荐mysqld离线)calc statistic of datadir (offline mysqld is recommended)
–prepare    指定备份的准备阶段 （准备一个在备份上启动mysql服务器的备份。）
–export 当在prepare阶段创建文件到另外的一个数据库 create files to import to another database when prepare.
–apply-log-only 一般情况下,在备份完成后，数据尚且不能用于恢复操作，
因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。
因此，此时数据 文件仍处理不一致状态。
–apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。
–print-param    输出mysqld copyback必须的参数print parameter of mysqld needed for copyback.
–use-memory=#   备份的时候指定的内存，该选项表示和–apply-log选项一起使用，
prepare 备份的时候，xtrabackup做crash recovery分配的内存大小，单位字节。
也可(1MB,1M,1G,1GB)，推荐1G。用于替代buffer_pool_size
–throttle=# 和–backup一起使用，指定每秒操作读写对的数量。
–log[=name] 忽略MySQL选项兼容性的选项
–log-copy-interval=#    日志复制线程完成的检查之间的时间间隔（以毫秒为单位,默认为1秒）。
–extra-lsndir=name  和–backup一起使用,在当前目录保存一份额外的xtrabackup_checkpoints文件
–to-archived-lsn=#  指定prepare备份时apply事务日志的LSN，只能和xtarbackup --prepare选项一起用。
–tables=name    通过正则表达式过滤表
–tables-file=name   按文件中的精确的database.table名称列表进行筛选。
–databases=name 按照数据库进行过滤
–databases-file=name    按照文件中的数据进行过滤
–tables-exclude=name    操作方式和–tables一样，但是匹配的表名将不备份，此参数的优先级高于–tables.
–databases-exclude=name 操作方式和–databases一样，但是匹配的库名将不被备份，优先级高于–databases.
–create-ib-logfile  此参数当前不生效，无效参数
–stream=name    该选项表示流式备份的格式，backup完成之后以指定格式到STDOUT，目前只支持tar(8.0版本仅支持)和xbstream
–decompress 该选项表示解压–compress选项压缩的文件，解压.qp扩展文件。
–compress[=name]    压缩所有输出数据，包括事务日志文件和元数据文件，通过指定的压缩算法，
目前唯一支持的算法是quicklz.结果文件是qpress归档格式，
每个xtrabackup创建的*.qp文件都可以通过qpress程序提取或者解压缩
–compress-threads=# 备份压缩的并行线程，默认为1.并行压缩（‘compress-threads’）可以和并行文件拷贝(‘parallel’)一起使用。
例如:’–parallel=4 --compress --compress-threads=2’会创建4个IO线程读取数据并通过管道传送给2个压缩线程。
–compress-chunk-size=#  压缩线程工作buffer的字节大小，默认是64K
–encrypt=name   该选项表示通过ENCRYPTION_ALGORITHM的算法加密innodb数据文件的备份，
目前支持的算法有ASE128,AES192,AES256。
–encrypt-key=name   该选项使用合适长度加密key，因为会记录到命令行，所以不推荐使用。
–encrypt-key-file=name  该选项表示文件必须是一个简单二进制或者文本文件，
加密key可通过以下命令行命令生成：openssl rand -base64 24。
–encrypt-threads=#  该选项表示并行加密的worker线程数量，默认为1.
–encrypt-chunk-size=#   该选项表示每个加密线程worker buffer的大小，单位是字节，默认是64K。
–decrypt=name   该选项表示解密通过–encrypt选项加密的.xbcrypt文件。
–remove-original    当删除解密和解压完后删除 .qp and .xbcrypt 文件
–rebuild_indexes    在apply事务日志之后重建innodb辅助索引，只有和–prepare一起才生效。
–rebuild_threads=#  在紧凑备份重建辅助索引的线程数，只有和–prepare和rebuild-index一起才生效。
–close-files    该选项表示关闭不再访问的文件句柄，
当xtrabackup打开表空间通常并不关闭文件句柄目的是正确的处理DDL操作。
如果表空间数量巨大，这是一种可以关闭不再访问的文件句柄的方法。使用该选项有风险，会有产生不一致备份的可能。
–core-file  Write core on fatal signals
–copy-back  做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir。
–move-back  这个选项与–copy-back相似，唯一的区别是它不拷贝文件，而是移动文件到目的地。
这个选项移除backup文件，用时候必须小心。使用场景：没有足够的磁盘空间同事保留数据文件和Backup副本
注意：
1.datadir目录必须为空。除非指定innobackupex --force-non-empty-directorires选项指定，否则–copy-backup选项不会覆盖
2.在restore之前,必须shutdown MySQL实例，你不能将一个运行中的实例restore到datadir目录中
3.由于文件属性会被保留，大部分情况下你需要在启动实例之前将文件的属主改为mysql，这些文件将属于创建备份的用户
–galera-info    该选项表示生成了包含创建备份时候本地节点状态的文件xtrabackup_galera_info文件，该选项只适用于备份PXC。
–slave-info 该选项表示对slave进行备份的时候使用，打印出master的名字和binlog pos，
同样将这些信息以change master的命令写入xtrabackup_slave_info文件。可以通过基于这份备份启动一个从库。
–no-lock    该选项表示关闭FTWRL的表锁，只有在所有表都是Innodb表并且不关心backup的binlog pos点，
如果有任何DDL语句正在执行或者非InnoDB正在更新时（包括mysql库下的表），都不应该使用这个选项，
后果是导致备份数据不一致，如果考虑备份因为获得锁失败，可以考虑–safe-slave-backup立刻停止复制线程。
–lock-ddl   若mysql serve支持在备份支持发出LOCK TABLES FOR BACKUP指令阻止所有的DDL操作。
–lock-ddl-timeout=# 若在指定时间内未返回值则终止备份。
–lock-ddl-per-table 在xtrabackup开始复制之前锁定每个表的DDL直到备份完成
–safe-slave-backup  该选项表示为保证一致性复制状态，这个选项停止SQL线程并且等到show status中的
slave_open_temp_tables为0的时候开始备份，
如果没有打开临时表，bakcup会立刻开始，否则SQL线程启动或者关闭知道没有打开的临时表。
–safe-slave-backup-timeout=#    如果slave_open_temp_tables在–safe-slave-backup-timeount（默认300秒）秒
之后不为0，从库sql线程会在备份完成的时候重启。
–rsync  该选项表示通过rsync工具优化本地传输，当指定这个选项，
innobackupex使用rsync拷贝非Innodb文件而替换cp，
当有很多DB和表的时候会快很多，不能–stream一起使用。
–force-non-empty-directories    指定该参数时候，使得 --copy-back或–move-back选项转移文件到非空目录，
已存在的文件不会被覆盖。如果–copy-back和–move-back文件需要
从备份目录拷贝一个在datadir已经存在的文件，会报错失败。
–no-version-check   该选项关闭版本检查，当–version-check选项开启的时候。
–tables-compatibility-check 此选项开启表存储引擎兼容性告警，默认开启。可使用–skip-tables-compatibility-check关闭。
–no-backup-locks    该选项在backup阶段控制锁，替换FLUSH TABLES WITH READ LOCK命令。
默认开启，关闭需使用参数–no-backup-locks。
当mysql服务器不支持backup locks时候此参数无效。
-u, --user=name 备份的用户名
-H, --host=name 备份的IP地址
-P, --port=#    备份的端口
-p, --password[=name]   备份时用户的密码
-S, --socket=name   备份时连接的unix操作系统的socket文件
-h, --datadir=name  数据恢复时候的数据目录.从my.cnf中读取，或者命令行指定。
-t, --tmpdir=name   当使用–print-param指定的时候打印出正确的tmpdir参数。
用于存储临时文件的路径，在轮训模式下可以指定多个路径，使用英文的:分隔
–parallel=# 指定备份时拷贝多个数据文件并发的进程数，默认值为1。
–log-bin[=name] binlog的日志序列
–incremental-lsn=name   和–backup一起使用。
–incremental-basedir=name   和–backup一起使用，仅拷贝.ibd中新增的数据到指定路径，增量备份.
–incremental-dir=name   和–prepare一起使用，将.delta文件和logfile保存在指定的路径.
–incremental-force-scan 该选项表示创建一份增量备份时，强制扫描所有增量备份中的数据页
–incremental-history-name   该选项表示存储在PERCONA_SCHEMA.xtrabackup_history基于增量备份的历史记录的名字。
Percona Xtrabackup搜索历史表查找最近（innodb_to_lsn）成功备份
并且将to_lsn值作为增量备份启动出事lsn.
与innobackupex–incremental-history-uuid、–incremental-basedir、–incremental-lsn互斥。
如果没有检测到有效的lsn，xtrabackup会返回error。
和选项–incremental一起使用。
–incremental-history-uuid   该选项表示存储在percona_schema.xtrabackup_history基于增量备份的特定历史记录的UUID。
和选项–incremental一起使用。
innobackupex遗留参数
​
参数值 参数用途
–ftwrl-wait-query-type  该选项表示获得全局锁之前允许那种查询完成，默认是ALL，可选update。
–ftwrl-wait-threshold   该选项表示检测到长查询，单位是秒，表示长查询的阈值。
若–ftwrl-wait-timeout=0此参数无效，默认值为60s。
–ftwrl-wait-timeout=#   此选项指定innobackupex在运行之前应等待阻止FTWRL的查询的时间（以秒为单位）。
如果超时到期时仍有此类查询，则innobackupex将终止并显示错误。
默认值为0，在这种情况下，innobackupex不会等待查询完成并立即启动FTWRL。
–kill-long-queries-timeout  该选项表示从开始执行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的这些查询之间等待的秒数。
默认值为0，不会kill任何查询，使用这个选项xtrabackup需要有Process和super权限。
–kill-long-query-type   该选项表示kill的类型，默认是all，可选select。
–history    该选项表示percona server 的备份历史记录在percona_schema.xtrabackup_history表。
–debug-sleep-before-unlock=#    仅用于xtrabackup测试套件的debug信息
–check-privileges   在执行查询之前检查数据库用户的权限。
安全备份的参数
​
参数值 参数用途
–server-public-key-path=name    File path to the server public RSA key in PEM format.
–server-public-key-path=name    File path to the server public RSA key in PEM format.
–get-server-public-key  Get server public key
–ssl-mode=name  SSL connection mode.
–ssl-ca=name    CA file in PEM format.
–ssl-capath=name    CA directory.
–ssl-cert=name  X509 cert in PEM format.
–ssl-cipher=name    SSL cipher to use.
–ssl-key=name   X509 key in PEM format
–ssl-crl=name   Certificate revocation list.
–ssl-crlpath=name   Certificate revocation list path.
–tls-version=name   TLS version to use, permitted values are: TLSv1, TLSv1.1,TLSv1.2
–ssl-fips-mode=name SL FIPS mode to use, permitted values are: OFF, ON,STRICT

使用方法

全备

xtrabackup --user=root --password=123456  --backup --target-dir=/full

内置文件解析：

cd /full && ls  # 进入到备份好的文件当中
# 内置文件：
backup-my.cnf   mysql               undo_001                xtrabackup_logfile
binlog.000002   mysql.ibd           undo_002                xtrabackup_tablespaces
binlog.index    performance_schema  xtrabackup_binlog_info
ib_buffer_pool  sys                 xtrabackup_checkpoints
ibdata1         test                xtrabackup_info
​
# backup-my.cnf
包含了备份数据库如下信息
innodb的一些配置信息
数据库的server ID
数据库服务器的uuid
master key id(安全相关)
# xtrabackup_binlog_info
其记录了备份完成时binlog的位置及GTID信息
用于复制的搭建
# xtrabackup_checkpoints
该文件对于后续增量备份有用
backup_type = full-backuped # 备份类型:全备
from_lsn = 0 # 备份中包含的事务日志序列号的起点
to_lsn = 18173496 # 操作保存时的事务日志序列号的结束点
last_lsn = 18173496 # 备份结束时的事务日志序列号.下次增量备份的起始位置  这里的数值会自动加9点
flushed_lsn = 18173496 # 刷新的lsn点
 

增量备份
 

#--incremental-basedir

xtrabackup --user=root --password=123456  --backup --target-dir=/full_01 --incremental-basedir=/full
 

恢复
 

# 将增量备份和全备整理以下合到一个里面
2.1 准备全备份的日志：
xtrabackup --prepare --apply-log-only --target-dir=/full  
2.2 准备增量备份的日志：
xtrabackup --prepare --apply-log-only --target-dir=/full  --incremental-dir=/full_01 #合并
2.3 全备份准备：
xtrabackup --prepare --target-dir=/full
2.4 拷回数据：
xtrabackup --host=192.168.233.132 --user=root --password=123456 --port=3306 --datadir=/var/lib/mysql --copy-back --target-dir=/full
 

MySQL8 模拟操作（#注意有风险不要在生产上随意操作，了解即可）
 

#首先第一步在数据库内容创建库表：

create database test charset utf8mb4 collate utf8mb4_bin;
use test;
create table t1(id int primary key auto_increment comment ' 序 号',name varchar(20) comment '名字' );
insert into t1(name) values('怡宝'),('康师傅'),('农夫三拳');
select * from t1;
 

#第二步全备一下
 

xtrabackup --user=root --password=123456  --backup --target-dir=/full
 

#第三步导入新数据
 

#批量导入一些假数据
source /t100w.sql
 

#第四步增量备份一下
 

xtrabackup --user=root --password=123456  --backup --target-dir=/full_01 --incremental-basedir=/full
 

#模拟宕机并将数据库所有数据全部干掉
 

# 查看数据库数据存放位置：


 

show variables like 'datadir';
 

+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| datadir       | /var/lib/mysql/ |
+---------------+-----------------+

# 然后将数据库停止 或者 干掉随意哈


 

systemctl stop mysqld.service #停止数据库，模拟数据库宕机
 

# 进入数据文件并删除全部内容


 

cd /var/lib/mysql/ && rm -rf *
 

# 将刚才备份所有的内容进行整理


 

xtrabackup --prepare --apply-log-only --target-dir=/full # 整合全量备份
 

# 整理增量备份，并合并到全量备份的文件当中


 

xtrabackup --prepare --apply-log-only --target-dir=/full  --incremental-dir=/full_01 
 

#再次整理全量备份


 

xtrabackup --prepare --target-dir=/full 
 

# 将全量的物理备份文件全部考入到 mysql 的数据文件 /var/lib/mysql/


 

xtrabackup --host=192.168.233.132 --user=root --password=123456 --port=3306 --datadir=/var/lib/mysql --copy-back --target-dir=/full
 

# 最后将 mysql数据文件全部赋权 # 不改数据库起不来


 

chown -R mysql.mysql /var/lib/mysql
 

# 启动数据库即可

 

systemctl start mysqld
 

以上是关于适用于MySQL8版本的两种备份方式（mysqldump，Xtrabackup8）的主要内容，如果未能解决你的问题，请参考以下文章
 

 u8系统备份的两种方式


 Centos7.3 下SQL Server  备份及还原的两种方式


 Redis的两种持久化方式详细介绍


 centos svn迁移备份的两种方法


 Mysql数据库备份的几种方法


 ansible的两种命令执行方式 : ad-hoc / playbook以及通过setup模块获取系统参数