13518219792
数据备份是数据容灾的最后一道防线，即便有着两地三中心的架构，备份也依然重要。如果备份出问题，备份时影响了交易业务，备份数据无法恢复，这些也是企业难以承受的。所以选择合适的备份工具尤为重要。
专注于为中小企业提供成都网站建设、网站设计服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业平房免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千余家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
每个企业级数据库都会有配套的备份工具，MEB(MySQL Enterprise Backup)就是MySQL企业版中非常重要的工具之一，是为企业级客户提供的数据备份方案。
Xtrabackup一直作为MEB 开源版备胎而存在，从MySQL 8.0开始情况可能会变得有所不同。
在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB备份/恢复体验会更好，目前xtrabackup还不支持这些特性。
MySQL 企业版还有哪些功能？
特性1：Backup Lock
8.0之前使用xtrabackup或MEB做物理备份，为了保证备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁，再拷贝非InnoDB文件，这期间MySQL会变成只读，数据无法写入。表数量越多，可能加上时间越长，如果使用的xtrabackup 不小心没加rsync参数，逐个拷贝frm文件，锁定时间会更长，对业务影响较大。
我曾遇到过部署在虚拟机的实例有12000多张表，当时使用的xtrabackup，备份脚本中没加rsync参数，结果锁了十几分钟，而MEB就没有这样的问题。
MySQL 8.0支持轻量级备份锁 LOCK INSTANCE FOR BACKUP，数据字典也重构了由InnoDB存储。若不创建非InnoDB表，MEB默认使用备份锁获取binlog日志一致性位置，并阻止DDL操作，但不影响DML操作。
只有InnoDB表，仅上备份锁
请点击输入图片描述
若有非InnoDB表，上全局锁
请点击输入图片描述
特性2：Redo Log Archiving
MEB能做到在线热备，备份时不影响数据库读写，这是利用了InnoDB事务日志，在备份期间持续监视redo log的变化，读取增量变化，写入到ibbackup_logfile，也就不需要上锁来保障备份一致性。(对非InnoDB的文件需要上读锁拷贝)
如果备份期间数据库写入负载特别大，而写入ibbackup_logfile速度较慢，redo log size也不大，很可能会出现ibbackup_logfile的写入速度跟不上redo log记录生成速度，redo log 空间不够时需要覆写日志文件，那么来不及写入ibbackup_logfile的记录会丢失，导致备份失败。
MEB 4.1对此做了优化，将redo log处理线程拆分成多线程分工合作，提高处理redo log的效率，降低了redo log覆写造成备份失败的概率，但redo log新增速度和ibbackup_logfile写入速度悬殊太大，问题依然会发生。
MySQL 8.0.17支持了redo log archiving 彻底解决了此问题，备份前设置innodb_redo_log_archive_dirs，指定redo log归档目录。MEB备份时自动开启日志归档，当checkpoint时会将旧记录归档到此目录，后续从归档文件中读取redo日志记录，避免了覆写可能导致的redo记录丢失。
请点击输入图片描述
注意：innodb_redo_log_archive_dirs 不能在数据目录下，目录权限要求是700
特性3：Page Tracking
Page Tracking 是为优化增量备份效率，减少不必要的数据页扫描。
增量备份当前有3种扫描模式：
page-track：利用LSN精确跟踪上次备份之后被修改页面，仅复制这些页面，效率最快。
optimistic：扫描上次备份之后被修改的InnoDB 数据文件中，找出并拷贝修改的页面。依赖系统时间，使用存在限制。
full-scan：扫描所有InnoDB数据文件，找出并拷贝自上次备份之后修改的页面，效率最慢
1、利用page-track增量备份，需先安装备份组件
mysql INSTALL COMPONENT "";
2、在全备前开启page-track
SELECT mysqlbackup_page_track_set(true);
3、全备之后，做增量备份时指定若满足page tracking条件，默认会使用page-track模式，否则会使用full-scan模式，也可以指定--incremental=page-track。
mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup
incremental-base有3种选择
last_backup：基于前一次备份做增备，前一次备份可能是增备，也可能是全备。这种方式全备之间可能会有多个增备，每次增量可能比较小，但恢复时需要逐个合并。
last_full_backup：基于前一次全备做增备。这种方式增备会越往后体积可能越大，但恢复时只需要合并最后一次增量备份。
dir：基于前一次的备份目录，前一次备份可能是增备，也可能是全备。
测试对比full-scan 和page-track ，在变更页小于总体50%的情况下 ，备份效率至少能有1倍的速度提升。
page-track 模式 磁盘读写均衡，说明读写的都是修改页面。
请点击输入图片描述
full-scan模式 磁盘读写差别很大，说明读了很多未修改的页面。
请点击输入图片描述
1.在 /etc/my.cnf 下面设置开启bin-log
编辑
vim /etc/my.cnf
[mysqld]
binlog_format = MIXED //binlog日志格式
log_bin =目录/mysql-bin.log //binlog日志名
expire_logs_days = 7 //binlog过期清理时间
#max_binlog_size 100m //binlog每个日志文件大小 最大值和默认是1个G
binlog-do-db=game #需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可
binlog-do-db=platform #
#binlog-ignore-db=不需要备份的数据库，如果备份多个数据库，重复设置这个选项即可
2.创建远程登陆数据库帐号
grant all privileges on game.* to 'jack'@'192.168.10.56' identified by 'admin'
grant all privileges on platform.* to 'jack'@'192.168.10.56' identified by 'admin'
3.将服务器上的数据，导入一份进远程服务器中
mysqldump -ujack -padmin -h192.168.10.38 备份数据库地址(/home/mysql/db/mysql.sql);
4.写Linux 计划任务:
vim /etc/crontab
在底部加入
0 3 * * * root sh /home/wwwroot/sh/mysqlbackup.sh #每天3点以root帐号的权限执行目录下的sh
重启服务
小量的数据库我们可以每天进行完整备份，因为这也用不了多少时间，但当数据库很大时，我们就不太可能每天进行一次完整备份了，而且改成每周一次完整备份，每天一次增量备份类似这样的备份策略。增量备份的原理就是使用了mysql的二进制日志，所以我们必须启用二进制日志功能。
一、增量备份
1、比如我们在星期天下午11点做一次完整备份：
mysqldump
--single-transaction
--flush-logs
--master-data=2
--all-databases
fullbackup_sunday_11_PM.sql
在sql文件中我们会看到两行：
–
Position
to
start
replication
or
point-in-time
recovery
from
–
CHANGE
MASTER
TO
MASTER_LOG_FILE=’bin-log.000002′，
MASTER_LOG_POS=107;
第二行包含了我们需要的信息，是指备份后所有的更改将会保存到bin-log.000002二进制文件中。
2、然后在星期一下午11点我们来做一次增量备份：
mysqladmin
flush-logs
这时将会产生一个新的二进制日志文件bin-log.000003，bin-log.000002则保存了自星期天下午11点到现在的所有更改，我们只需要把这个文件备份到安全的地方就行了。然后星期二我们又做增量备份，还是执行同样的命令，这时我们保存bin-log.000003文件。
二、恢复备份
比如星期三中午12点出现了故障，这时需要恢复，我们首先导入星期天的完整备份：
mysql
fullbackup_sunday_3_AM.sql
接着我们导入星期一和星期二的增量备份：
mysqlbinlog
bin-log.000002
bin-log.000003
mysql
这时我们已经恢复了所有备份数据，我们还可以找到bin-log.000004，进一步恢复最新的数据。
1：官方百万级别的测试数据库：
官方测试数据库github网址：
下载到目录，解压即可，运行命令：
2：自己创建简单测试数据库：
快速随机生成测试语言的网站：
选择sql和想生成的字段，点击生成Generate!生成即可。
在MySQL输入生成的语句即可。
3：测试备份还原时用到的命令
删库跑路测试（先备份好）
还原后查询库的表数据是否完整。
采用复制整个数据存放目录
1：查看数据库数据存放位置
有两种方法：
1)：在数据库中用命令 show variables like 'datadir'; 查看
2)：在配置文件中查看，配置了 datadir 目录的可查看。没有配置的默认为 /var/lib/mysql/ 位置
Linux中查看配置文件
2：复制目录或者目录下某个数据库名
3：还原时直接复制文件夹到数据库目录即可
mysqldump又可叫做全量备份。
参数 --databases 同 -B ，单独一个库，也可省略。
1、备份命令mysqldump格式
格式：mysqldump -h主机名 -P端口 -u用户名 -p密码 database 数据库名 文件名.sql
备份testDatabase数据库
2、备份MySQL数据库为带删除表的格式
备份MySQL数据库为带删除表的格式，能够让该备份覆盖已有数据库而不需要手动删除原有数据库。
3、直接将MySQL数据库压缩备份
备份并压缩
4、备份MySQL数据库某个(些)表
备份testDatabase中的myTable表，不需要用参数 --databases 或者 -B
5、同时备份多个MySQL数据库
同时备份testDatabase和 employees两个库
6、备份服务器上所有数据库
参数 --all-databases 同 -A
7、还原MySQL数据库的命令
1) 不指定数据名还原，默认生成原数据库名称，还原所有数据库。
2) 指定数据名还原，还原指定单个数据库，需在数据库种预先创建一个testDatabase名称。
3) 还原压缩的MySQL数据库
4) 进入数据库用source导入
增量备份是针对于数据库的bin-log日志进行备份的，增量备份是在全量的基础上进行操作的。增量备份主要是靠mysql记录的bin-log日志。
1：查看是否开启bin-log日志
进入mysql输入命令可查看。
显示如下为开启状态，日志文件在/var/lib/mysql/以binlog.00001的格式保存。
如未开启，需要在配置文件种配置
2：查看目前使用的bin-log日志文件
进入mysql查看命令。
显示如下，目前使用的是binlog.000022文件，所有操作都记录在此文件。
查看当前testDatabase的表myTable数据如下，
3：刷新日志，使用新的日志文件（备份）
在命令端执行命令
日志文件从 binlog.000022 变为 binlog.000023
这时相当与已经备份成功，备份文件即为上次的binlog.000022日志文件。
4：删除数量，从日志还原数据
1) 删除ABC行
查询以及没有ABC行列。
2) 恢复数据ABC行
退出mysql，在命令端用mysqlbinlog命令恢复到binlog.000022日志状态。
进入数据库再次查看数据，ABC已经恢复。
增量备份完成。
所有mysql实例皆为MYSQL8版本,使用的Xtrabackup备份组件为xtrabackup8.
生产mysql使用基于percona的分支,相对于原版mysql多了一些性能调教和监控视图,版本为:percona-server-server-8.0.22,备份相关工具对mysql8的官方版本也是完全兼容的.percona的分支相关信息:
生产环境mysql一共3个实例,使用MGR组成集群以实现灵活的高可用与读写分离.并由前置的proxysql进行数据的路由与转发.
模拟故障为:在生产环境mysql8 的MGR集群完全不可用,有前一天的Xtrabackup全量备份和增量备份,需要从之前的全量和增量备份完整恢复到故障最近的时间点.本次故障恢复的要求是读取前一天的所有增量和全量数据并恢复.快速重组生产MGR集群.
在这里会用ansible脚本快速搭建3个mysql实例,以模拟生产环境(略过).
backup_func.sh :
策略是每天的0:30做一次全量备份,之后每两个小时的半点会做一次增量备份.
注: 本次恢复属于完整的生产环境集群恢复,下面的 获取备份文件 , 准备备份 , 开始恢复 相关流程,需要在每一台服务器上执行,实际操作中,如果只需要恢复并查看数据则只做一个点就可以了.
这里取的是前一天的打过包的备份文件,根据备份脚本的规则,每天凌晨的全量备份之前,会自动将前一天的全量备份和增量备份目录全部打包并以前一天的日期命名:
20210609.tar.gz
将其scp到待恢复的服务器上并解压:
解压后的目录结构:
确保需要恢复的服务器有mysql实例,xtrabackup8工具已安装,由于备份是经过压缩的,确保qpress也已安装.
由于备份脚本在备份时使用了 --compress 指令,在恢复备份前,需要先解压缩备份,
这里将所有增量和全量备份路径均执行一下解压缩指令:
在同时存在全量和增量备份需要合并的情况下,准备备份时需要带上 --apply-log-only 参数,但是要注意在准备最后一个增量备份的时候,不需要加该参数.
以上操作会将所有的增量备份合并到全量备份中.
根据各自安装时指定的相关路径去删除数据.(data,binglog,logs,undolog),一般在my.cnf中有指定
如果my.cnf不是在默认路径(/etc/my.cnf),需要指定一下mysql配置文件的路径: --defaults-file=${DB_CONF}
至此,备份数据在单节点上的恢复已经完成了.
查看下最后一份增量备份里才会有的一些数据
先确保同样的mysql恢复操作分别在三台服务器上执行完成.(如果在新建服务器上恢复MGR集群,一定要检查my.cnf中MGR集群相关配置,比如 loose-group_replication_local_address , loose-group_replication_group_seeds , loose-group_replication_start_on_boot )
master节点启动:
MGR的三台节点的权重实际上是一样的,选择其中的一台做master即可.
mster节点启动完成后,再分别在两台slave节点启动MGR:
由于3台mysql实例的数据是一样的,节点间状态同步迅速就OK了.
至此,3台mysql的MGR状态均为 online ,整个集群启动完成,全演练流程结束.
