meb是用于备份mysql的官方工具，是一个跨平台高性能的工具，提供热备，增备，差异备份和恢复等功能，能够直接备份到云存储，也能压缩加密等多种功能。
优化后，meb不仅可以用于Innodb，而且对于其它的存储引擎也非常适配，多线程读写和块级别的多线程读写让其有非常好的性能，特别是与传统备份工具mysqldump相对比时。
本文学习的内容：
根据数据库是否中断服务分类：
根据备份数据覆盖面分类：
注意：在负载比较大的数据库中，在备份的时候，应该尽可能使用--only-innodb来备份innodb数据库和其文件
备份MyISAM和其它数据库引擎的条件：
数据库支持Innodb，并且最少有一个innodb数据库
MyISAM和其它引擎只能温备
meb安装在所有想要备份的mysql服务器上，通常备份和恢复都是在本地进行；meb的软件包也是打包成tgz格式
当用压缩包安装时，解压之后会有meb的文件夹，将文件夹拷贝到想要安装的目录即可，然后在系统环境变量中添加路径。
当用rpm包安装时，安装之后，meb命令是/usr/bin/mysqlbackup
cnf配置文件位置：一般mysqld使用--defaults-file指定文件目录
mysql端口
数据文件目录
备份用户账号密码
创建备份目录，用于存储备份过程中的临时文件
redo log文件大小：8.0.29以及之前版本需要，计算方式：配置文件中的innodb_log_file_size和innodb_log_files_in_group相乘得到。只有当执行增备时，使用 --incremental-with-redo-log-only参数时需要
redo log生成速率：8.0.29以及之前版本需要，使用 --incremental-with-redo-log-only参数时需要
官方示例（具体情况具体修改）
CREATE USER 'mysqlbackup'@'localhost' IDENTIFIED BY 'password'; GRANT SELECT, BACKUP_ADMIN, RELOAD, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE, SELECT, ALTER ON mysql.backup_history TO 'mysqlbackup'@'localhost';
对于部分mysql特性，需要其它的权限来备份，如下：
使用了TTS特性来备份和恢复InnoDB表：
使用了redo log日志来备份时：
使用了TLR和non-TTS备份特性：
示例：
GRANT LOCK TABLES, CREATE, DROP, FILE, INSERT, ALTER ON . TO 'mysqlbackup'@'localhost'; GRANT CREATE, DROP, UPDATE ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost'; GRANT ENCRYPTION_KEY_ADMIN ON . TO 'mysqlbackup'@'localhost'; GRANT INNODB_REDO_LOG_ARCHIVE ON . TO 'mysqlbackup'@'localhost';
升级后的权限配置：
GRANT ALTER ON mysql.backup_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_progress_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP ON mysql.backup_history_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_history_new TO 'mysqlbackup'@'localhost';
使用磁带备份需要的权限：
GRANT ALTER ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_sbt_history_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_sbt_history_new TO 'mysqlbackup'@'localhost';
在备份主机上需要一个备份目录，用于存放备份产生的文件，可以是nas文件系统等，需要有足够的空间，在备份时用——-backup-dir来指定；
如果想要使用时间戳来区别不同的备份，可以在备份时使用--with-timestamp
对于Linux和Unix-like系统，meb不会关注文件权限，所以为了备份顺利进行，最好使用运行mysql服务的用户来执行备份
shell# 创建备份用户
CREATE USER 'mysqlbackup'@'localhost' IDENTIFIED BY 'Admin@123';
GRANT SELECT, BACKUP_ADMIN, RELOAD, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP, UPDATE, SELECT, ALTER ON mysql.backup_history TO 'mysqlbackup'@'localhost';
# 全备
[root@hecs-34400 ~]# mysqlbackup --user=mysqlbackup --password --host=127.0.0.1 --backup-dir=/backup/ --backup-image=/backup/bak.mbi --with-timestamp backup-to-image
MySQL Enterprise Backup Ver 8.0.33-commercial for Linux on x86_64 (MySQL Enterprise - Commercial)
Copyright (c) 2003, 2023, Oracle and/or its affiliates.
...
IMPORTANT: Please check that mysqlbackup run completes successfully.
At the end of a successful 'backup-to-image' run mysqlbackup
prints "mysqlbackup completed OK!".
Enter password: 输入密码
230705 10:56:04 MAIN INFO: Establishing connection to server.
...
230705 10:56:05 MAIN INFO: MySQL binlog position: filename binlog.000014, position 1491.
-------------------------------------------------------------
Parameters Summary
-------------------------------------------------------------
Start LSN : 118173696
Last Checkpoint LSN : 118174200
End LSN : 118243953
-------------------------------------------------------------
mysqlbackup completed OK!
备份成功
# 命令解析
mysqlbackup --user=mysqlbackup --password --host=127.0.0.1 --backup-dir=/backup/ --backup-image=/backup/bak.mbi --with-timestamp backup-to-image
--user和--password是执行mysql数据库用户和密码
--host指定登录ip
--backup-dir是指定临时存放备份文件的目录
--backup-image是指将整个备份做成一个文件，执行这个文件的位置，需要backup-to-image配合使用
backup-to-image 指明将整个备份做成一个单独的文件
--with-timestamp 备份携带时间戳
简析：
要做什么？备份mysql
使用什么工具？mysqlbackup
备份到哪里？/backup
使用mysqlbackup备份mysql（连接mysql语句user和password）到/backup/bak.mbi，备份的形式是backup-to-image
临时文件用/backup目录存储
# -------------------
可以发现meb备份的几个重要参数：
--user
--password
--backup-dir 临时目录
--backup-image
backup-to-image
# -------------------
# 备份结果展示
[root@hecs-34400 ~]# tree /backup/
/backup/
├── 2023-07-05_10-56-04
│ ├── backup-my.cnf
│ ├── datadir
│ ├── meta
│ │ ├── backup_content.xml
│ │ ├── backup_create.xml
│ │ ├── backup_variables.txt
│ │ ├── image_files.xml
│ │ └── MEB_2023-07-05.10-56-04_backup-to-image.log
│ ├── server-all.cnf
│ └── server-my.cnf
├── bak.mbi //备份执行的单独文件
├── full
└── incr
使用命令可以验证备份的完整性，但是是否真的可以使用还是需要做备份恢复测试才能真正确定！
shell# 验证备份文件完整性
[root@hecs-34400 ~]# mysqlbackup --backup-image=/backup/bak.mbi validate
MySQL Enterprise Backup Ver 8.0.33-commercial for Linux on x86_64 (MySQL Enterprise - Commercial)
Copyright (c) 2003, 2023, Oracle and/or its affiliates.
...
230705 11:02:37 MAIN INFO: Source Image Path = /backup/bak.mbi
mysqlbackup completed OK!
恢复前的准备工作：
关闭mysql服务器
删除mysql数据文件，如果使用了以下相关参数：--innodb_data_home_dir, --innodb_log_group_home_dir, --innodb_undo_directory，也需要删除相关文件夹内容
恢复
shell[root@mysqldb833 data]# mysqlbackup --backup-image=/data/bak.mbi --datadir=/data/mysql --backup-dir=/data/baktmp copy-back-and-apply-log 解析： 使用mysqlbackup将mbi文件恢复到数据目录，恢复的方式是copy-back-and-apply-log，指定临时目录 [root@mysqldb833 data]# chown -R mysql.mysql /data/mysql
shell# 有一个告警：
230705 14:11:31 MAIN WARNING: If you restore to a server of a different version, the innodb_data_file_path parameter might have a different default. In that case you need to add 'innodb_data_file_path=ibdata1:12M:autoextend' to the target server configuration.
修改配置文件：
因为源服务器和目标服务器配置不一致，有时候需要修改部分参数，建议将backup-my.cnf中的配置添加到目标服务器中
backup-my.cnf在备份临时目录中，或者将mbi文件解压也可以得到：
mysqlbackup --backup-image=/data/bak.mbi --backup-dir=/data/bak extract
mysqlbackup --backup-image=/data/bak.mbi --backup-dir=/data/bak image-to-backup-dir
[root@mysqldb833 data]# ls bak
backup-my.cnf datadir meta server-all.cnf server-my.cnf
推荐使用备份为单个文件，因为备份为单个文件才能重定向到云存储和磁带，以及压缩等，存储更方便
指定配置文件备份为单个文件：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-image=/backups/sales.mbi --backup-dir=/backup-tmp backup-to-image
这里仍然需要使用--backup-dir，用来存储备份过程中的临时文件
不将备份存储在mbi文件中，输出出来
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-image=- --backup-dir=/backup-tmp backup-to-image
--backup-image=- :表示将备份数据输出到output中，这样可以用于重定向
# 下面就是通过重定向将备份传输到另一台机器
mysqlbackup --defaults-file=~/my_backup.cnf --backup-image=- --backup-dir=/tmp backup-to-image | ssh <user name>@<remote host name> 'cat > ~/backups/my_backup.img'
增备有两个选项：
--incremental-with-redo-log-only：从redo log中读取上次备份后的改变，但是redo log会被覆盖，所以为了阻止被覆盖，可以在MySQL中注册mysqlbackup，不支持压缩
注册方式： DO innodb_redo_log_consumer_register(); 但是这种方式一般需要和DBA商量，这种修改估计不好整，pass
页跟踪
mysql存储数据是按页存储的，页跟踪可以有效找到上次备份后有更改的页，备份更快
但是页跟踪需要在数据库中启用页跟踪选项，且需要占用内存和cpu，提高机器负载，当数据库修改的页太多时，效率不高
使用方式：在数据库中开启页跟踪选项，备份时：--incremental=page-track
全盘扫描
--incremental=full-scan
使用全盘扫描，mysql会扫描所有页找到上次备份后有修改的页，进行复制，当修改不大的，这样的备份方式效率低。
乐观扫描
--incremental=optimistic
只扫描上次备份后有改动的页，但是这种方式也有限制：
使用增备备份所有数据库和表，有个二选一参数：--incremental-base和--start-lsn；
增备示例：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --incremental --incremental-base=history:last_backup \ --backup-dir=/home/dbadmin/temp_dir \ --backup-image=incremental_image1.bi \ backup-to-image
使用乐观备份进行增备：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/dbadmin/temp_dir \ --backup-image=incremental_image1.bi backup-to-image
使用文件夹形式进行增备：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --incremental-base=dir:/incr-backup/wednesday \ --incremental-backup-dir=/incr-backup/thursday \ backup 增加了一个--incremental-backup-dir参数，用于执行增备结果存储的目录
使用--start-lsn参数，meb将会扫描所有页，找到所有在这个LSN之后被修改过的页，将其备份
lsn号：存储在上次备份目录下的meta/backup_variables.txt中
shell[root@hecs-34400 meta]# cat /backup/2023-07-05_10-56-04/meta/backup_variables.txt | grep -i lsn end_lsn=118243953
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --start-lsn=2654255716 \ --with-timestamp \ --backup-dir=/incr-tmp \ --backup-image=/incr-backup/incremental_image.bi \ backup-to-image
如果命令中没有执行清楚增备bi文件存储的位置，那么就会将结果放在--backup-dir中：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --start-lsn=2654255716 \ --with-timestamp \ --backup-dir=/incr-images \ --backup-image=incremental_image1.bi \ backup-to-image
实际示例：
shell[root@hecs-34400 backup]# mysqlbackup --defaults-file=/etc/my.cnf --socket=/var/lib/mysql/mysql.sock --user=mysqlbackup -pAdmin@123 --incremental-with-redo-log-only --incremental-base=history:last_backup --backup-dir=/backup/inc2 --backup-image=/backup/inc1.bi backup-to-image
压缩功能只针对InnoDB表；mysql中已经压缩的表不会在备份的时候再次压缩；
一个表空间有空间没有被表使用，使用压缩的时候，不会备份这部分空间；如果在备份中没有使用压缩，那么这部分没有使用的空间也会被备份；
二进制日志和中继日志在压缩备份过程中，也被压缩为.bz文件
压缩功能和redo功能冲突（比如，在选用压缩后，不能使用--incremental-with-redo-log-only）
示例：
shell# 简单使用压缩功能
mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress --backup-image=backup.img backup-to-image
# 选择压缩等级
mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress-method=zlib --compress-level=5 backup
# 备份并应用redo日志
mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress-method=zlib --compress-level=5 backup-and-apply
通常情况下，数据目录下的所有文件都会被备份，如果想要选择性备份可以使用如下方式：
示例：
shell# 只备份表名称包含emp的表
mysqlbackup \
--host=localhost --user=mysqluser --protocol=TCP --port=3306 \
--backup-dir=$MEB_TEMP_BACKUP_DIR --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --include-tables="\.emp" \
backup-to-image
# 实例：只备份名称开头为my的数据库
[root@hecs-34400 test]# mysqlbackup --user=mysqlbackup -pAdmin@123 --socket=/var/lib/mysql/mysql.sock --backup-dir=/backup/test/full --backup-image=/backup/test/part.mbi --include-tables="\.my" backup-to-image
shell# 备份所有数据库，除了mysql和performance_schema库中的表
mysqlbackup \
--host=localhost --user=mysqluser --protocol=TCP --port=3306 \
--backup-dir=$MEB_TEMP_BACKUP_DIR --backup-image=$MEB_BACKUPS_DIR/my.mbi \
--exclude-tables="^(mysql|performance_schema)\." \
backup-to-image
shell# 备份sales数据库，但是sales库中的harware表不备份
mysqlbackup \
--host=localhost --user=mysqluser --protocol=TCP --port=3306 \
---backup-dir=$MEB_TEMP_BACKUP_DIR --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --include-tables="^sales\." --exclude-tables="^sales\.hardware$" \
backup-to-image
shell# 备份所有的Innodb表
mysqlbackup \
--host=localhost --user=mysqluser --protocol=TCP --port=3306 \
--backup-dir=$MEB_TEMP_BACKUP_DIR --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --only-innodb \
backup-to-image
在备份大型数据库的过程中，会有大量的超过meb处理能力的redo log生成，这个时候，备份实际上已经失败了，因为redo log会不断的被覆盖、重写；并且在恢复预准备阶段，也会花费很长的时间。
乐观扫描备份的参数：
前者执行上次备份的结束时间，这个时间可以在meta文件夹下的backup_variables文件中的end_time得到
后者是手动指定哪些表被指定为忙碌表
optimistic-time的意思是：在这个时间后，有修改操作的表被认定为忙碌表，其它表为空闲表
optimistic-busy-tables的意思是：指定哪些表为忙碌表，其它表为空闲表
同时指定了这两个参数的时候，optimistic-busy-tables优先级高
当指定这两个参数或之一的时候，就会启动乐观备份
乐观扫描分为两个阶段：
注意，在乐观扫描备份过程中，不要进行DDL操作（即不要该表数据库结构），否则会备份失败
备份数据库，从2011年5月6日后没有变动的表为空闲表
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516120000 --backup-image=<image-name> --backup-dir=<temp-dir> backup-to-image
备份数据库，所有的表都被标记为空闲表备份
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=now --backup-image=<image-name> --backup-dir=<temp-dir> backup-to-image
指定忙碌表进行备份
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" --backup-image=<image-name> --backup-dir=<temp-dir> backup
使用乐观备份进行全备和增备：
shell# A full optimistic backup performed on 2017/02/04, Sat, at 1130 PM.
# The --optimistic-time option is used to specify an optimistic time of 2016/08/16, 0800 PM
mysqlbackup --defaults-file=/home/admin/my.cnf --optimistic-time=160816200000 \
--backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
--with-timestamp \
backup-to-image
# A sequence of optimistic incremental backups are then performed on each the following six days at 1130 PM
# On Sunday, 2017/02/05
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
--with-timestamp \
backup-to-image
# On Monday, 2017/02/06
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
--with-timestamp \
backup-to-image
# On Tuesday, 2017/02/07
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
--with-timestamp \
backup-to-image
# On Wednesday, 2017/02/08
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702082330.bi \
--with-timestamp backup-to-image
# On Thursday, 2017/02/09
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702092330.bi \
--with-timestamp \
backup-to-image
# On Friday, 2017/02/10
mysqlbackup --defaults-file=/home/admin/my.cnf \
--incremental=optimistic --incremental-base=history:last_backup \
--backup-dir=/home/admin/temp_dir \
--backup-image=/home/admin/backups/mydb_incremental__201702102330.bi \
--with-timestamp \
backup-to-image
# Another full optimistic backup is performed on Saturday, 2017/02/11
mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516200000 \
--backup-dir=/home/admin/temp_dir --backup-image=/home/admin/backups/mydb_full_201702112330.bi \
--with-timestamp \
backup-to-image
# Restore the database to its state at Tuesday, 2017/02/07, at 11:30 PM
# First, restore the full optimistic backup taken on the Saturday before, which was 2017/02/04:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_full_201702042330.bi \
--backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \
--with-timestamp \
copy-back-and-apply-log
# Next, restore the optimistic incremental taken on the Sunday, Monday, and Tuesday that follow:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \
--backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
--with-timestamp \
copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \
--backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
--with-timestamp \
copy-back-and-apply-log
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \
--backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental \
--with-timestamp \
copy-back-and-apply-log
备份的作用就是在数据库出问题的时候可以恢复数据
恢复前，需要确定的问题：
恢复的参数有两个：
copy-back-and apply-log
copy-back
恢复的条件：数据库需要关闭，至少不能有操作；恢复进程会把备份的数据文件、日志和其它的备份的文件恢复至它们原始位置并对其执行恢复后操作
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<image_name> --backup-dir=<backupTmpDir> --datadir=<restoreDir> copy-back-and-apply-log
解释：使用meb将image中的备份恢复到datadir中，并应用redo日志
copy-back-and-apply-log会执行两件事：
恢复过程要注意的事情：
恢复全备镜像：
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<image_name> --backup-dir=<backupTmpDir> --datadir=<restoreDir> --uncompress copy-back-and-apply-log
和上面的命令的差别就是有个 --uncompress参数
恢复全备压缩目录备份
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> --datadir=<restoreDir> --uncompress copy-back-and-apply-log
一个全备目录已经应用了redo日志，只拷贝：
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> --datadir=<restoreDir> --uncompress copy-back
shellmysqlbackup --defaults-file=<my.cnf> --backup-image=<image_name> --backup-dir=<backupTmpDir> --datadir=<restoreDir> --decrypt --key-file=<keyFile> copy-back-and-apply-log
恢复增备有两种方式：
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<inc_image_name> \ --backup-dir=<incBackupTmpDir> --datadir=<restoreDir> --incremental \ copy-back-and-apply-log
说明：
shell# 先恢复全备，应用redo日志
$ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log
..many lines of output...
101208 17:15:10 mysqlbackup: Full backup prepared for recovery successfully!101208 17:15:10 mysqlbackup: mysqlbackup completed OK!
shell# 恢复增备，并应用redo日志
$ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 --backup-dir=/full-backup/2010-12-08_17-14-11 apply-incremental-backup
...many lines of output...
101208 17:15:12 mysqlbackup: mysqlbackup completed OK!
这个时候全备就可以恢复到数据目录了，使用之前的copy-back即可
shellmysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> copy-back meb可以自己从cnf文件中找到数据文件
表级别恢复：只将备份中的部分表恢复到目标服务器
对备份的要求：
对恢复的要求：
缺陷：
示例
shell# 从备份中恢复pets库的cat表
mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^pets\.cats" --backup-dir=/dba/backuptmp --backup-image=/dba/my.mbi copy-back-and-apply-log
# 从备份中恢复sales的所有表，除了sales的hardware表
mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^sales\." --exclude-tables="^sales\.hardware$" --backup-dir=/dba/backuptmp --backup-image=/dba/my.mbi copy-back-and-apply-log
shell# Using fully qualified table names:
mysqlbackup --socket=/tmp/restoreserver.sock \
--backup-dir=/BackupDirTemp --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
--include-tables="^sales\.cars" --rename="sales.cars to sales.autos" copy-back-and-apply-log
# It works the same if database names are omitted in the argument for --rename:
mysqlbackup --socket=/tmp/restoreserver.sock \
--backup-dir=/BackupDirTemp --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
--include-tables="^sales\.cars" --rename="cars to autos" copy-back-and-apply-log
# A table can be restored into another database; the target database is created if it is not existing on the server:mysqlbackup --socket=/tmp/restoreserver.sock \
--backup-dir=/BackupDirTemp --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \
--include-tables="^sales\.cars" --rename="sales.cars to new_sales.autos" copy-back-and-apply-log
目录备份和单个文件备份一样，可以使用copy-back-and-apply-log，但是对于目录备份有另一种操作：
在恢复到数据目录之前，任何时间，任何地点，都可以先应用日志，比如：目标服务器压力性能一般，可以现在性能好的服务器上应用日志，再拷贝到目标机器上执行后面的copy-back操作
shellmysqlbackup --backup-dir=/export/backups/2011-06-21__8-36-58 apply-log
或者对于压缩备份，也可以先在其它地方进行解压缩和应用日志：
shellmysqlbackup --backup-dir=/export/backups/compressed --uncompress apply-log
然后，在目标机器上，使用copy-back操作
shellmysqlbackup --defaults-file=/usr/local/mysql/my.cnf --backup-dir=/export/backups/full copy-back
这其实就是将copy-back-and-apply-log分开执行
使用备份中的binlog可以将备份恢复到任意时间点
恢复条件：
步骤：
恢复所有的备份到服务器，除了最后一个包含恢复点的备份；完成后，记录当前binlog的位置点：这个信息在临时目录的backup_variables.txt文件的binlog_position中
解压增备镜像到文件夹，查看镜像文件中包含的binlog日志
从这个binlog日志中找到恢复到的binlog点
进行恢复
注意：
shellmysqlbinlog --start-position="3078" --stop-position="3583" /backup/inc1/datadir/mysql-bin.000002 /backup/inc1/datadir/mysql-bin.000003 /backup/inc1/datadir/mysql-bin.000004 | mysql -uroot -p
实例：
shell# 开启binlog
[mysqld]
log_bin=/data/binlog/mysql-bin
# 重启mysql服务后查看是否开启
mysql> show variables like '%log_bin%';
+---------------------------------+------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------+
| log_bin | ON |
| log_bin_basename | /data/binlog/mysql-bin |
| log_bin_index | /data/binlog/mysql-bin.index |
| sql_log_bin | ON |
+---------------------------------+------------------------------+
6 rows in set (0.00 sec)
# 创建备份用户
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'Admin@123';
GRANT SELECT, BACKUP_ADMIN, RELOAD, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'backup'@'localhost';
GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'backup'@'localhost';
GRANT CREATE, INSERT, DROP, UPDATE, SELECT, ALTER ON mysql.backup_history TO 'backup'@'localhost';
# 创建数据库和表
create database db1;
create table db1.t1(id int);
# 插入数据
insert into db1.t1(1);
insert into db1.t1(2);
insert into db1.t1(3);
mysql> select * from db1.t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)
# 做全备
/opt/mysqlbackup/mysql-commercial-backup-8.0.30-el7-x86_64/bin/mysqlbackup --user=backup -p --host=127.0.0.1 --backup-dir=/backup/full --backup-image=/backup/full.mbi backup-to-image
# 插入数据
mysql> insert into db1.t1 values(11);
Query OK, 1 row affected (0.01 sec)
mysql> insert into db1.t1 values(22);
Query OK, 1 row affected (0.01 sec)
mysql> insert into db1.t1 values(33);
Query OK, 1 row affected (0.00 sec)
mysql> select * from db1.t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 11 |
| 22 |
| 33 |
+------+
6 rows in set (0.00 sec)
# 做增备
[root@node240-31 bin]<20230710 12:25:30># /opt/mysqlbackup/mysql-commercial-backup-8.0.30-el7-x86_64/bin/mysqlbackup --user=backup -p --host=127.0.0.1 --incremental --incremental-base=history:last_full_backup --backup-dir=/backup/inc1 --backup-image=/backup/inc1.mbi backup-to-image
# 当前目标，恢复到全备后到增备前的某个时间点
# 删除所有数据文件和binlog文件
# 恢复全备
[root@node240-31 full]<20230710 12:40:34># /opt/mysqlbackup/mysql-commercial-backup-8.0.30-el7-x86_64/bin/mysqlbackup --backup-image=/backup/full.mbi --datadir=/var/lib/mysql/ --backup-dir=/data/full copy-back-and-apply-log
# 记录全备的binlog点
[root@node240-31 meta]<20230710 12:41:54># cat /data/full/meta/backup_variables.txt
[backup_variables]
binlog_position=mysql-bin.000002:3078
所以全备的binlog点是mysql-bin.000002的3078
# 解压增备
[root@node240-31 inc1]<20230710 12:44:22># /opt/mysqlbackup/mysql-commercial-backup-8.0.30-el7-x86_64/bin/mysqlbackup --backup-image=/backup/inc1.mbi --backup-dir=/backup/inc1/ image-to-backup-dir
# 找到增备中的binlog文件
[root@node240-31 datadir]<20230710 12:44:55># ls /backup/inc1/datadir/mysql-bin.000002
/backup/inc1/datadir/mysql-bin.000002
# 启动mysql
[root@node240-31 ~]<20230710 12:58:38># chown -R mysql.mysql /var/lib/mysql/
[root@node240-31 ~]<20230710 13:00:09># chown -R mysql.mysql /data/
[root@node240-31 ~]<20230710 13:00:18># systemctl restart mysqld
# 从binlog日志中找到插入22时的binlog点时3583
### INSERT INTO `db1`.`t1`
### SET
### @1=22
# at 3583
# 所以增备从全备的mysql-bin.000002的3078恢复到3583
mysqlbinlog --start-position="3078" --stop-position="3583" /backup/inc1/datadir/mysql-bin.000002 | mysql -uroot -p
[root@node240-31 backup]<20230710 13:03:22># mysql -uroot -p
mysql> select * from db1.t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 11 |
+------+
4 rows in set (0.00 sec)
当mysql启用加密功能时，如果使用的keyring_file或keyring_aws插件，使用meb的系统用户必须具有keyring文件的写权限
备份命令示例：
shellmysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-image=/home/admin/backups/my.mbi --backup-dir=/home/admin/backup-tmp --encrypt-password="password" backup-to-image
备份过程：
注意：
命令：
shellmysqlbackup --defaults-file=/usr/local/mysql/my.cnf --backup-image=/home/admin/backups/my.mbi --backup-dir=/home/admin/restore-tmp --encrypt-password="password" copy-back-and-apply-log
和普通的恢复命令的区别就是多了--encrypt-password="password"这个参数
恢复过程：
当在备份服务器上使用除了keyring_file之外的任何密钥环插件时，mysqlbackup会将加密的密钥环数据文件恢复到服务器的正确位置。恢复后的服务器必须使用keyring_encrypted_file插件以及keyring_encrypted_file_data和--keyring_encrypted_file_password选项启动（这些选项应该提供与恢复期间使用--encrypt-password选项相同的密码）。在服务器启动并运行后，如果需要另一个密钥环插件或组件（例如，备份用户使用keyring_aws，恢复后的服务器也应该使用它），可以执行密钥环迁移操作。
当在备份服务器上使用keyring_file密钥环插件时，mysqlbackup使用--encrypt-password选项提供的密码解密密钥环数据文件，然后将其恢复到服务器上的适当位置供keyring_file插件使用。
当在备份服务器上使用component_keyring_encrypted_file.cnf密钥环组件时，mysqlbackup将加密的密钥环数据文件恢复到服务器的正确位置，并在恢复后的服务器上创建一个清单文件和配置文件component_keyring_encrypted_file.cnf（其中包含恢复过程中使用的--encrypt-password选项的密码），以便服务器在重新启动时加载component_keyring_encrypted_file组件。
当在备份服务器上使用component_keyring_file密钥环组件时，mysqlbackup使用--encrypt-password选项提供的密码解密密钥环数据文件，然后将其恢复到服务器的适当位置。它还在恢复后的服务器上创建一个清单文件和配置文件component_keyring_file.cnf，以便服务器在重新启动时加载component_keyring_file组件。
如果在恢复的服务器上使用了密钥环组件，请执行以下额外步骤：
meb可以通过对主节点的备份来搭建一个新的从节点，并且不用停止主节点。
步骤：
对主数据库进行全备，并恢复到从节点还要记得应用日志；注意不要使用--no-locking参数来备份数据库，否则binlog位置点可能不对
在配置文件的[mysqld]下添加：skip-replica-start和event_scheduler=off(如果主节点使用了event_scheduler的话)
启动mysql从节点，这时会在日志中看到binlog相关的信息，但是这些信息是不准确的，因为Innodb没有记录DDL和非innodb的操作，所以不要使用这里出现得信息
查看备份临时目录下得datadir/meta/backup_variables.txt文件中的binlog_position；从这个参数可以得到真正的binlog日志文件和位置点
执行change replication source to命令：
CHANGE REPLICATION SOURCE TO
SOURCE_LOG_FILE='hundin-bin.000006',
SOURCE_LOG_POS=128760128;
ALTER EVENT mysql.event DISABLE ON REPLICA;设置从节点停止事件
删除配置文件中的skip-replica-start和event_scheduler=off(如果主节点使用了event_scheduler的话)
重启从节点
对主数据库进行全备，并恢复到从节点还要记得应用日志；注意不要使用--no-locking参数来备份数据库，否则binlog位置点可能不对
在配置文件的[mysqld]下添加：skip-replica-start和event_scheduler=off(如果主节点使用了event_scheduler的话)
启动mysql从节点
连接到从节点并清楚从节点上的主从信息：reset master;暂停binlog日志：set sql_log_bin=0
使用gtid备份的时候，将镜像恢复到从节点，在从节点上的临时文件中，有一个backup_gtid_executed.sql文件，这里面包含了设置GTID_PURGED参数的sql语句
shell# On a new replica, issue the following command if GTIDs are enabled:
SET @@GLOBAL.GTID_PURGED='f65db8e2-0e1a-11e5-a980-080027755380:1-3';
这个文件中也包含了已经被注释的主从配置语句：
shell# Use the following command if you want to use the GTID handshake protocol:
# CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1;
取消上面change replication语句的注释，并修改为主节点的信息：
shell# Use the following command if you want to use the GTID handshake protocol:
CHANGE REPLICATION SOURCE TO SOURCE_HOST='127.0.0.1', SOURCE_USER='muser', SOURCE_PASSWORD='mpass', SOURCE_PORT=18675, SOURCE_AUTO_POSITION = 1;
解释：SOURCE_HOST：主节点地址；SOURCE_USER复制用户名称，SOURCE_PASSWORD：复制用户密码，SOURCE_AUTO_POSITION：自动寻找同步位置，不用特意指定
然后在从节点上执行这个sql脚本，mysql> source backup_gtid_executed.sql
ALTER EVENT mysql.event DISABLE ON REPLICA;设置从节点停止事件
重启从节点mysql
MGR：mysql group replication
对于MGR架构，备份信息被所有节点知晓，因为备份信息写入 backup_history, backup_sbt_history， backup_progress三个表中，然后同步到所有节点上。
所以备份MGR架构，有几个注意的点：
所有的机器名称和ip地址能够被meb解析，也就是说hosts中要有所有节点的信息
对每个节点开放表performance_schema.replication_group_members的访问权限
shell# 创建用户
CREATE USER 'mysqlbackup'@'host1' IDENTIFIED BY 'password';
CREATE USER 'mysqlbackup'@'host2' IDENTIFIED BY 'password';
CREATE USER 'mysqlbackup'@'host3' IDENTIFIED BY 'password';
# 赋予权限
GRANT SELECT ON performance_schema.replication_group_members TO 'mysqlbackup'@'host1';
GRANT SELECT ON performance_schema.replication_group_members TO 'mysqlbackup'@'host2';
GRANT SELECT ON performance_schema.replication_group_members TO 'mysqlbackup'@'host3';
# 注意项：
'mysqlbackup'@'host1'，'mysqlbackup'@'host2'，'mysqlbackup'@'host3'和'mysqlbackup'@'localhost'的密码都必须是一样的，因为在命令中只会指定一次密码，所以必须是一样的
每次磁带备份都会在 mysql.backup_history ，mysql.backup_progress，mysql.backup_sbt_history这三个表中有记录
恢复的时候也需要指定MMS参数：
下面参数对于备份和恢复都是可以设置的，备份时设置就是多线程备份，恢复时设置就是多线程恢复