MysqlEnterpriseBackup_meb初学

Mysql Enterprise Backup

简介

meb是用于备份mysql的官方工具，是一个跨平台高性能的工具，提供热备，增备，差异备份和恢复等功能，能够直接备份到云存储，也能压缩加密等多种功能。

优化后，meb不仅可以用于Innodb，而且对于其它的存储引擎也非常适配，多线程读写和块级别的多线程读写让其有非常好的性能，特别是与传统备份工具mysqldump相对比时。

本文学习的内容：

如何安装meb
如何使用meb进行各种备份
如何使用meb进行特殊情况下的备份和恢复

备份种类

根据数据库是否中断服务分类：

热，不中断服务
温，只读
冷，关闭数据库

根据备份数据覆盖面分类：

全备
增备：备份上次备份（不论是全备还是增备均可）到目前变化的数据
差异备份：备份上次全备到目前变化的数据

meb备份的中文件类型

ibdata* Inoodb表空间，可能包含多个表和索引
*.ibd Innodb表空间，包含一个表和其索引
*.ibz 压缩的innodb数据文件
backup-my.cnf 记录源数据库配置文件参数以及数据文件分布
ibbackup_ibd_files 在增备中记录idb文件和其空间id
ibbackup_logfile logfile的压缩版本
ib_logfile* 在备份过程中，在apply-log阶段创建的日志文件
server-my.cnf 包含源数据库中非默认值的全局变量
server-all.cnf 包含源数据库中所有的全局变量
backup-auto.cnf auto.cnf的拷贝

注意：在负载比较大的数据库中，在备份的时候，应该尽可能使用--only-innodb来备份innodb数据库和其文件

备份MyISAM和其它数据库引擎的条件：

数据库支持Innodb，并且最少有一个innodb数据库

MyISAM和其它引擎只能温备

meb备份过程

拷贝InnoDB数据文件，redo日志，二进制日志和relay日志文件（除了正在使用的文件）；由于在拷贝过程中，数据和表结构可能会发生变化，所以下面的步骤有些是为了保证这些变化会被备份知晓
服务器实例会上备份锁，冻结InnoDB表的DDL操作（create，alter，drop等），不会冻结DML操作（select，insert，delete，update等），大部分数据库读写操作都是可以的；加锁之后，meb扫描在步骤1之后被DDL操作修改的InnoDB表，对应修改备份
对所有用户创建的非InnoDB表上只读锁然后拷贝，如果没有用户创建的非InnoDB表，跳过
非常短暂的冻结日志活动，meb收集日志相关的信息比如：当前InnoDB的LSN号，二进制日志位置，GTID，复制源或者状态等
释放非InnoDB的读锁
使用上述第4步的信息，将当前正在使用的二进制或中继日志文件的相关部分进行复制。这样可以确保捕获自第1步以来对InnoDB表的所有最近更改，以便稍后将其应用于原始备份数据，以使还原的服务器达到一致状态
释放备份锁，数据库恢复正常状态
之前尚未复制的重做日志文件以及备份的所有元数据文件被复制或创建
备份完成，meb返回成功信息

安装

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参数时需要

备份用户权限

select，在所有数据库和表上的select权限，用于表锁，防止多线程DDL操作导致的数据不一致
BACKUP_ADMIN，所有数据库和表上的BACKUP_ADMIN权限
RELOAD，所有数据库和表上的RELOAD权限
SUPER，用于开启和关闭日志
REPLICATION CLIENT，用于找到binlog位置存储在备份中
PROCESS，处理带有ALGORITHM=INPLACE语句的DDL操作
CREATE, INSERT, DROP，UPDATE；在 mysql.backup_progress和mysql.backup_history表上具有CREATE, INSERT, DROP，UPDATE权限；在 mysql.backup_history表上还要具有 SELECT和 ALTER权限

官方示例（具体情况具体修改）

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表：

LOCK TABLES权限来备份表，CREATE权限来恢复表
DROP权限用于当恢复失败时删除临时表
FILE权限用于恢复在数据目录外的额外的表空间中的表

使用了redo log日志来备份时：

INNODB_REDO_LOG_ARCHIVE权限来执行innodb_redo_log_archive_start()函数

使用了TLR和non-TTS备份特性：

INSERT和ALTER权限来更新表

示例：

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';

升级后的权限配置：

当Mysql Server从8.0.18或者更早版本升级到8.0.19后，第一次使用meb8.0.19或later，可能需要如下权限：

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';

当第一次使用meb8.0.12或later，如果Mysql Server是从8.0.11或earlier升级上来，可能需要如下权限：

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';

使用磁带备份需要的权限：

ALTER权限，mysql.backup_sbt_history上的alter权限
CREATE,INSERT,DROP权限，在mysql.backup_sbt_history_old表上的权限
CREATE,INSERT,DROP,ALTER权限，在mysql.backup_sbt_history_new上

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服务的用户来执行备份

备份和恢复整个mysql实例

备份

# 创建备份用户
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

验证备份的完整性

使用命令可以验证备份的完整性，但是是否真的可以使用还是需要做备份恢复测试才能真正确定！

# 验证备份文件完整性
[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，也需要删除相关文件夹内容
恢复

[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

# 有一个告警：
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

备份为单个文件和备份为一个目录的区别

推荐使用备份为单个文件，因为备份为单个文件才能重定向到云存储和磁带，以及压缩等，存储更方便

指定配置文件备份为单个文件：

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-image=/backups/sales.mbi --backup-dir=/backup-tmp backup-to-image

这里仍然需要使用--backup-dir，用来存储备份过程中的临时文件

不将备份存储在mbi文件中，输出出来

mysqlbackup --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
--incremental

--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-with-redo-log-only，因为乐观扫描是读取数据文件的修改时间，而不是使用redo log
如果使用了--start-lsn参数，那么会启动全盘扫描，即使指定了乐观扫描，因为指定了起始lsn号，那么mysqlbackup就不能确定之前的哪些数据在上次这个lsn号之后变动过

示例

使用增备备份所有数据库和表，有个二选一参数：--incremental-base和--start-lsn；

--incremental-base：

使用这个参数是告诉meb到mysql.backup_history表中去找上次备份成功的结束LSN号，使用方式：--incremental-base=history:last_backup或者--incremental-base=history:last_full_backup；
上次备份是备份到目录：--incremental-base=dir:path_to_dir ；那就指定上次备份的目录
上次备份是备份到单独文件：--incremental-base=dir:path_to_tmp_dir ；那就指定上次备份的临时文件目录

增备示例：

mysqlbackup --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

使用乐观备份进行增备：

mysqlbackup --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

使用文件夹形式进行增备：

mysqlbackup --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

使用--start-lsn参数，meb将会扫描所有页，找到所有在这个LSN之后被修改过的页，将其备份

lsn号：存储在上次备份目录下的meta/backup_variables.txt中

[root@hecs-34400 meta]# cat /backup/2023-07-05_10-56-04/meta/backup_variables.txt | grep -i lsn
end_lsn=118243953

mysqlbackup --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中：

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --backup-dir=/incr-images \
  --backup-image=incremental_image1.bi \
  backup-to-image

实际示例：

[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）

示例：

# 简单使用压缩功能
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

部分备份

通常情况下，数据目录下的所有文件都会被备份，如果想要选择性备份可以使用如下方式：

使用--include-tables或者--exclude-tables参数将表纳入或剔除备份；每个表都会以db_name.table_name的形式和这两个参数的正则表达式进行比对，如果符合就进行对应操作
如果只想备份Innodb表，可以使用--only-innodb参数
剔除在数据文件目录中不属于mysql的文件，可以使用 --only-known-file-types参数即可
上述参数可以组合使用
备份可传输表空间（ transportable tablespaces ）需要参数--use-tts

示例：

# 只备份表名称包含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

# 备份所有数据库，除了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

# 备份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

# 备份所有的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会不断的被覆盖、重写；并且在恢复预准备阶段，也会花费很长的时间。

乐观扫描备份的参数：

optimistic-time
optimistic-busy-tables

前者执行上次备份的结束时间，这个时间可以在meta文件夹下的backup_variables文件中的end_time得到

后者是手动指定哪些表被指定为忙碌表

optimistic-time的意思是：在这个时间后，有修改操作的表被认定为忙碌表，其它表为空闲表

optimistic-busy-tables的意思是：指定哪些表为忙碌表，其它表为空闲表

同时指定了这两个参数的时候，optimistic-busy-tables优先级高

当指定这两个参数或之一的时候，就会启动乐观备份

乐观扫描分为两个阶段：

备份空闲表，因为认为空闲表在备份过程中不会变化，所以只备份了数据文件，并且没有上任何锁，redo log、undo log、系统表空间也没有备份
备份忙碌表，这个阶段就和普通备份一样，备份数据库文件，备份各种日志等

注意，在乐观扫描备份过程中，不要进行DDL操作（即不要该表数据库结构），否则会备份失败

示例

备份数据库，从2011年5月6日后没有变动的表为空闲表

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=110516120000  --backup-image=<image-name> --backup-dir=<temp-dir>  backup-to-image

备份数据库，所有的表都被标记为空闲表备份

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=now  --backup-image=<image-name> --backup-dir=<temp-dir> backup-to-image

指定忙碌表进行备份

mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*" --backup-image=<image-name> --backup-dir=<temp-dir> backup

使用乐观备份进行全备和增备：

# 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

恢复的条件：数据库需要关闭，至少不能有操作；恢复进程会把备份的数据文件、日志和其它的备份的文件恢复至它们原始位置并对其执行恢复后操作

恢复全备文件

mysqlbackup --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会执行两件事：

将备份文件从镜像中解压出来，并拷贝到数据目录中
执行应用redo日志操作

恢复过程要注意的事情：

datadir需要是空的
innodb_data_home_dir、innodb_log_group_home_dir、innodb_undo_directory也要是空的
恢复结束需要修改这些目录的权限为启动用户

恢复压缩全备

恢复全备镜像：

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<image_name> --backup-dir=<backupTmpDir> --datadir=<restoreDir>  --uncompress copy-back-and-apply-log

和上面的命令的差别就是有个 --uncompress参数

恢复全备压缩目录备份

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> --datadir=<restoreDir> --uncompress copy-back-and-apply-log

一个全备目录已经应用了redo日志，只拷贝：

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> --datadir=<restoreDir> --uncompress copy-back

恢复加密镜像

mysqlbackup --defaults-file=<my.cnf> --backup-image=<image_name> --backup-dir=<backupTmpDir> --datadir=<restoreDir> --decrypt --key-file=<keyFile> copy-back-and-apply-log

增备恢复

恢复增备有两种方式：

一种是先将全备恢复到数据目录，并且应用了redo日志（过程如同上面的全备恢复）；然后再恢复增备，将增备文件恢复到数据目录并应用日志；命令如下：

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-image=<inc_image_name> \
 --backup-dir=<incBackupTmpDir> --datadir=<restoreDir> --incremental \
 copy-back-and-apply-log

说明：

--backup-image：增备镜像文件
--backup-dir：临时文件目录
--datadir：全备文件目录

另一种是将全备恢复到一个非数据目录的文件夹中，并应用redo日志，然后再将增备恢复到这个全备目录中，最后再将全备恢复到数据目录，如下：

# 先恢复全备，应用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!

# 恢复增备，并应用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即可

mysqlbackup --defaults-file=<my.cnf> -uroot --backup-dir=<backupDir> copy-back
meb可以自己从cnf文件中找到数据文件

表级别恢复

表级别恢复：只将备份中的部分表恢复到目标服务器

对备份的要求：

备份是全备，部分备份，或者使用了TTS的备份；
备份的时候使用了参数：--include-tables或者--exclude-tables

对恢复的要求：

目标服务器上的mysql是正在运行的
需要连接目标mysql的信息，比如端口，soket等，供meb连接使用
目标服务器的mysql必须和源mysql使用相同的页大小
innodb_file_per_table选项在目标mysql上必须被激活
对于非TTS备份：表结构必须已经存在在目标mysql中
对于TTS备份：表结构必须没有存在
当部分恢复时，--datadir参数不是必须的；如果一定要指定，那么这个值就必须是目标mysql的值，否则恢复就失败（当恢复8.0.16及以前的TTS备份，--datadir是必须要的)

缺陷：

部分备份在恢复的时候就不能再拆分恢复，也就是说，部分备份恢复的时候就会将备份的内容全部恢复
不能用增备来执行部分恢复
二进制日志、中继日志和undo日志不会恢复
对于非TTS备份，还有一些缺陷：
- 部分恢复后，数据库中可能存在一些未提交的事物
- 表中自增的值可能和备份过程中不一致
- 加密innodb不能被部分恢复

示例

# 从备份中恢复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

恢复tts备份

# 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操作

mysqlbackup --backup-dir=/export/backups/2011-06-21__8-36-58 apply-log

或者对于压缩备份，也可以先在其它地方进行解压缩和应用日志：

mysqlbackup --backup-dir=/export/backups/compressed --uncompress apply-log

然后，在目标机器上，使用copy-back操作

mysqlbackup --defaults-file=/usr/local/mysql/my.cnf --backup-dir=/export/backups/full copy-back

这其实就是将copy-back-and-apply-log分开执行

恢复到执行时间点

使用备份中的binlog可以将备份恢复到任意时间点

恢复条件：

源数据库开启了binlog
一系列的备份（比如：一个全备，多个增备）中，最后一次备份涵盖了恢复的目标时间点
一系列的备份中，最后一次备份包括了相关的binlog日志（并且没有使用这些参数： --skip-binlog, --use-tts, --no-locking, or --start-lsn）

步骤：

恢复所有的备份到服务器，除了最后一个包含恢复点的备份；完成后，记录当前binlog的位置点：这个信息在临时目录的backup_variables.txt文件的binlog_position中
解压增备镜像到文件夹，查看镜像文件中包含的binlog日志
从这个binlog日志中找到恢复到的binlog点
进行恢复

注意：

尽量使用binlog点(--start-position和--stop-position)来恢复而不是时间点(--start-datetime和--stop-datetime)，因为会有丢失binlog日志的风险
如果有多个binlog日志文件，那么就是用如下方式来恢复

mysqlbinlog --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

实例：

# 开启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文件的写权限

备份

备份命令示例：

mysqlbackup --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

备份过程：

meb连接mysql，确认正在使用的keyring插件
如果mysql使用的是keyring_encrypted_file插件或者component_keyring_encrypted_file组件，备份时候命令必须包含--encrypt-password选线用于解密加密文件，获取数据文件加密密码；也可以执行加密方式的密码：比如使用的是keyring_encrypted_file插件，那么就不需要使用--encrypt-password选项，可以使用--keyring_encrypted_file_password选项代替；如果使用的是component_keyring_encrypted_file组件，那么可以使用component_keyring_encrypted_file.cnf代替。meb会考本加密文件到mete文件夹中，加密的表空间也会拷贝到备份中。
如果mysql不是使用上述两种方式备份，那么加密文件会保存在keyring_kef文件中，并且在备份的时候保存在meta目录中，文件的加密密码可以使用--encrypt-password指定

注意：

对于加密方式不是keyring_encrypted_file插件或者component_keyring_encrypted_file组件的mysql服务器，meb仅支持这些mysql中使用socket或者ip的TLS连接。meb并不支持运行在windows上的mysql或者仅允许共享内存服务器
如果不想在命令行中暴露密码，可以仅使用——-encrypt-password，在进行备份的时候会主动询问密码
解压镜像文件到目录，不论是用extract或者image-to-backup-dir，都不用使用--encrpty-password选项，

恢复

命令：

 mysqlbackup --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组件。

如果在恢复的服务器上使用了密钥环组件，请执行以下额外步骤：
- 使用全局清单和配置文件启动密钥环组件的方法：
- 将恢复的数据目录中的清单文件复制到mysqld二进制文件所在的文件夹中。
- 将恢复数据目录中的配置文件component_keyring_file.cnf复制到组件二进制文件所在的文件夹中。
- 使用本地清单和配置文件启动密钥环组件的方法:
  - 在mysqld二进制文件所在的文件夹中创建一个包含以下内容的新清单文件:
  - 在组件二进制文件所在的文件夹中创建一个包含以下内容的新配置文件component_keyring_file.cnf:

主从复制集群备份

从备份搭建一个新的从节点

meb可以通过对主节点的备份来搭建一个新的从节点，并且不用停止主节点。

对于没有使用gtid的集群

步骤：

对主数据库进行全备，并恢复到从节点还要记得应用日志；注意不要使用--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的话)
重启从节点

对于使用了gtid的集群

对主数据库进行全备，并恢复到从节点还要记得应用日志；注意不要使用--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语句

# On a new replica, issue the following command if GTIDs are enabled:
SET @@GLOBAL.GTID_PURGED='f65db8e2-0e1a-11e5-a980-080027755380:1-3';

这个文件中也包含了已经被注释的主从配置语句：

# Use the following command if you want to use the GTID handshake protocol:
# CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1;

取消上面change replication语句的注释，并修改为主节点的信息：

# 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集群

MGR：mysql group replication

对于MGR架构，备份信息被所有节点知晓，因为备份信息写入 backup_history, backup_sbt_history， backup_progress三个表中，然后同步到所有节点上。

所以备份MGR架构，有几个注意的点：

所有的机器名称和ip地址能够被meb解析，也就是说hosts中要有所有节点的信息

对每个节点开放表performance_schema.replication_group_members的访问权限

# 创建用户
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'的密码都必须是一样的，因为在命令中只会指定一次密码，所以必须是一样的

MMS

备份到MMS

使用--backup-image=sbt:name参数被meb用来识别备份数据，sbt:前缀表示备份到磁带而不是本地，注意name在磁带中一定要是唯一名称
--sbt-lib-path:用来区别不同的MMS软件的磁带lib，相当于驱动，备份到哪个带库中，就需要使用那个带库的驱动lib，不指定的话meb会自动去环境变量中查找
--sbt-environment：用来做lib的参数，连接一个库，需要一些参数，在这个变量中指定各种参数

每次磁带备份都会在 mysql.backup_history ，mysql.backup_progress，mysql.backup_sbt_history这三个表中有记录

恢复到MMS

恢复的时候也需要指定MMS参数：

--backup-image=sbt:name：备份时的名称
--sbt-lib-path：带库的驱动lib
--sbt-environment：驱动lib的参数

多线程

下面参数对于备份和恢复都是可以设置的，备份时设置就是多线程备份，恢复时设置就是多线程恢复

当测试备份性能时，如果在具有raid配置的存储上，可以对比以下两个选项的区别： --read-threads=3 --process-threads=6 --write-threads=3和--read-threads=1 --process-threads=6 --write-threads=1
如果在没有配置raid的存储上，可以考虑使用以下选项： --read-threads=1 --process-threads=6 --write-threads=1
如果提高了任何线程参数，可以考虑提升--limit-memory参数来提升每个线程可使用的内存
如果cpu负载不高，可以改变--porcess-threads来改变使用的线程数
如果数据库存储可以处理更多的I/O请求，可以增加--read-threads参数
如果存储备份的存储可以处理更多的I/O请求，那么可以增加--write-threads参数，但是注意，对于备份为单个镜像的任务无效，因为备份为单个镜像，写就是单线程

posted @ 2023-07-11 15:31 NewBird001 阅读(1357) 评论(0) 收藏举报

刷新页面返回顶部

NewBird001

MysqlEnterpriseBackup_meb初学

Mysql Enterprise Backup

简介

备份种类

meb备份的中文件类型

meb备份过程

安装

备份前操作

收集数据库信息

备份用户权限

附加权限

规划备份目录

备份用户

备份和恢复整个mysql实例

备份

验证备份的完整性

恢复

备份为单个文件和备份为一个目录的区别

增备

示例

--incremental-base：

--start-lsn

压缩

部分备份

乐观扫描

示例

恢复

恢复全备文件

恢复压缩全备

恢复加密镜像

增备恢复

表级别恢复

恢复tts备份

预制备份和恢复备份目录

恢复到执行时间点

备份恢复加密数据库

备份

恢复

主从复制集群备份

从备份搭建一个新的从节点

对于没有使用gtid的集群

对于使用了gtid的集群

MGR集群

MMS

备份到MMS

恢复到MMS

多线程

公告