0%

MySQL8.0新特性:备份优化

Redo Log Archiving

在MySQL8.0中启用了redo log archive的功能,旨在解决一致性备份问题。在之前的版本中,由于redo是固定大小循环写入的,如果备份速度跟不上redo log生成的速度,则无法保持备份一致性。redo log archive在备份启动时同步启动,备份结束时停止,此时可以利用redo log归档进行数据恢复。

在启用redo log archive之前,需要先通过参数innodb_redo_log_archive_dirs设置redo log归档路径

1
2
root@(none) 21:22:  set global innodb_redo_log_archive_dirs="backup:/service/mysql/archive";
Query OK, 0 rows affected (0.01 sec)

其中backup为tag标记,说明其是用于备份,/service/mysql/archive为redo log归档目录,我们也可以通过分号设置多个路径

接下来我们就DO innodb_redo_log_archive_start(‘backup’)来手动启动redo log archive

1
2
3
4
5
6
7
8
9
root@(none) 21:41:  SELECT innodb_redo_log_archive_start('backup');
+-----------------------------------------+
| innodb_redo_log_archive_start('backup') |
+-----------------------------------------+
| 0 |
+-----------------------------------------+

root@(none) 21:41: DO innodb_redo_log_archive_start('backup');
Query OK, 0 rows affected (0.09 sec)

注:开启archive的会话必须存活才能生成archive日志

通过sysbench性能测试工具模拟数据操作后停止redo log archive

1
2
root@(none) 21:50:  do innodb_redo_log_archive_stop();
Query OK, 0 rows affected (0.05 sec)

这时可以看见在归档目录下生成了对应的归档日志

1
2
3
[root@t-luhx02-v-szzb archive]# ls -lh
total 527M
-r--r----- 1 mysql mysql 527M Jun 14 21:54 archive.fba19872-aa1a-11ea-b40c-005056abb91e.000001.log

Tips:详情请参考:Redo Log

Backup Lock

在MySQL8.0之前,为保证innoDB与非InnoDB表的一致性,通常会使用flush table with read lock来实现一致性备份。在加锁过程中,MySQL变为只读,无法更新。如果使用xtrackup时没加上rsync参数,锁定的时间会更长,影响也就越大。而在MySQL8.0中引入了LOCK INSTANCE FOR BACKUP轻量级备份锁,并且数据字典也全变为InnoDB引擎了,如果没有非InnoDB的表则使用Backup Log来获取一致性位置,期间不允许DDL,但DML可以执行

加锁

1
2
root@(none) 09:12:  lock instance for backup;
Query OK, 0 rows affected (0.00 sec)

解锁

1
2
root@(none) 09:12:  unlock instance;
Query OK, 0 rows affected (0.00 sec)

Page Tracking

Page Tracking是针对增量备份的优化,减少不必要的数据页扫描。有点类似与Oracle中的块跟踪,只是MySQL的最小单位为页。当前有三种扫描方式:

  • page-track:利用LSN跟踪上一次备份之后被修改的数据页,增量备份仅复制这些修改的页
  • optimstic:扫描上一次备份之后被修改的InnoDB数据文件,查找并复制修改的页,依赖于系统时间
  • full-scan:扫描所有数据文件,找出上一次备份之后被修改的数据页

安装备份组件

1
2
root@(none) 09:30:  INSTALL COMPONENT "file://component_mysqlbackup";
Query OK, 0 rows affected (0.16 sec)

全备之前开启page tracking

1
2
3
4
5
6
root@(none) 09:30:  SELECT mysqlbackup_page_track_set(true);
+----------------------------------+
| mysqlbackup_page_track_set(true) |
+----------------------------------+
| 4282913844 |
+----------------------------------+

全备后进行增量备份

1
mysqlbackup --incremental-backup-dir=/service/mysql/backup/inc --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backup

其中–incremental-base有三种选择:

  • last_backup:基于前一次备份做增量备份,前一次可能是全备,也可能是增量备份
  • last_full_backup:基于前一次全备做增量备份
  • dir:基于前一次的备份目录,前一次可能是全备,也可能是增量备份