细说MySQL备份的基本原理(系列一 ) 备份与锁

时间:2024-03-04 16:19:37

数据库作为一个系统中唯一或者主要的持久化组件,对服务的可用性和数据的可靠性要求极高。 作为能够有效应对因为系统软硬件故障、人工误操作导致数据丢失的预防手段,备份是目前最为常见的数据库运维操作。 考虑到备份操作对数据库可用性的影响, MySQL官方将备份方式划主要划分为以下三类:

  • 热备:备份过程中,MySQL实例始终是运行的,所有用户的读写请求都不会受到影响。

  • 冷备:备份前首先需要停止MySQL实例的运行,整个备份过程中,用户均无法访问数据库。

  • 温备:备份过程中,虽然MySQL实例是运行的,但是为了保证数据的一致性,允许用户通过加锁的方式来防止可能的更新或者修改操作。备份过程中,数据是只读的,所有的写请求会被阻塞。

针对MySQL数据库,目前主流的备份软件主要有mysqldump和XtraBackup两种。
 
mysqldump
 
mysqldump是MySQL自带的备份工具,通过create table、drop table和insert into 等SQL语句,将数据库中的数据导出成.sql文件。由于该文件是可读的,所以称之为逻辑备份。为了保证备份数据的一致性,mysqldump为用户提供了以下参数:
  • --add-locks 为了保证一张表的数据一致性,对该表执行lock table xxx read,无论是innodb表还是myisam表,插入、删除、更新、带X锁的读(select for update)和DDL(alter)请求均会被阻塞,不影响快照读和S锁读(select lock in share mode)请求。该参数不保证表之间的数据一致性,如果涉及到跨表的查询,备份不能保证表之间数据是一致的。

  • --lock-tables  锁定某一个数据库的所有的表,能够保证某一个库中的所有表的数据一致性,但是不保证库之间的数据一致,相当于在一个数据库的所有表上执行了--add-locks参数,此外该库的DDL语句均会给阻塞。

  • --lock-all-tables 锁定某个实例的所有表,可以保证所有库的数据一致性,相当于所有的库同时指定lock tables参数,此外,实例的所有DDL语句(create database)均会阻塞。除非指定--single-transaction选项,如果指定,则mysqldump仅在备份开始时,加一个flush tables with read lock的全局锁,防止所有的DDL和写操作,在开启事务后,释放该锁,备份过程中,如果是innodb表则不受影响。

  • --single-transaction 针对支持MVCC(多版本)事务的存储引擎,例如innodb,mysqldump提供了在导出数据之前,开启一个事务,由数据库保证单次导出数据的一致性,此时针对Innodb表的所有读写操作,均不会被阻塞。

  • --master-data 获取备份数据的Binlog位置和Binlog文件名,用于通过备份恢复的实例之间建立复制关系时使用,该参数会默认开启。

从对mysqldump参数的分析我们可以看出,之所以备份过程中要上锁,主要基于以下几个原因:

  • 备份的数据库中包含不支持事务的表,需要通过锁来保证单个表、一个库中的表之间、同一个实例的不同库的表之间的数据一致性。该锁可以表锁、库级别的锁甚至实例级别的锁,应根据实际业务对一致性的需求选择不同粒度的锁,最大程度的减少锁对用户读写请求的影响。

  • 为了保证备份时,表结构的一致性,需要通过锁来阻止对表、库和实例的DDL操作。

  • 为了保证获取正确的Binlog位置和文件名,需要短暂的锁定整个实例的所有库,因为Binlog是实例级别的,一个实例的所有库是共享Binlog文件和位置的。同时值得注意的是,无论是innodb表还是myisam表,此都为必须步骤,只是innodb表可以在开启事务后即释放该锁,而myisam需要在整个备份过程中,一直持有该锁,对用户访问的影响时间长短区别。

mysqldump由于依赖数据库层的转换,所以并不关心底层的存储引擎,既适用于支持事务的,也适用于不支持事务的,并且可以同时在不同MySQL版本之间进行转换,由于是逻辑备份,用户可以在备份的过程中,同时对数据进行修改。但是也正是因为需要经过数据库层的转换,mysqldump生成的备份文件往往很大,而且速度较慢,备份过程对数据库的访问有较大的影响,对于数据量大、业务压力高的实例并不适用。

XtraBackup

XtraBackup是Percona公司一款开源的数据库备份软件,相对于mysqldump,它是直接通过拷贝物理文件实现数据库备份的,所以速度相比要快很多。XtraBackup包含两部分:xtrabackup的c程序和innobackupex perl脚本;前者主要用于处理innodb表的备份;后者是前者的封装,主要包括一些与MySQL服务器的通信和mysiam表的备份。

首先我们先来简单的了解一下xtrabackup备份的基本原理。xtrabackup能够实现针对innodb表的无锁备份,即所有的读写请求、DDL语句在整个备份过程中都是不受影响的。它的实现是基于innodb对事务的支持,利用其崩溃恢复的功能来实现的。MySQL所有的更新操作都是在内存中完成的,然后异步的刷入磁盘进行持久化。支持事务的存储引擎,为了保证MySQL宕机后内存中还未刷出的更新不会丢失,设计了事务引擎日志(redo log)。通过将该部分的更新记录到日志中,然后记录日志序号(LSN),异步线程在将脏页刷新到磁盘的同时,维护一个检查点LSN,两个LSN之间的差异就是数据宕机后丢失的更新。在数据库启动时,只要事务日志保存完好,就可以根据redo log和undo log将数据库恢复到崩溃前的一致性状态。

      一起走进MySQL备份身后的故事(篇二 无锁的备份) - 网易杭研后台技术中心 - 网易杭研后台技术中心的博客

上图通过在MySQL执行show engine innodb status,我们可以清楚的看到:

  • Log sequence number:表明当前redo log的最新LSN。

  • Log flushed up to:表明当前已经刷新到磁盘上redo log的LSN。

  • Last checkpoint at redo log记录的更新已经刷新到磁盘上的检查点LSN,该LSN之前的redo log上记录的更新已全部刷新到磁盘上,可以被覆盖重复使用。

 

xtrabackup备份时,首先会记录一个当前redo log最新的LSN,该点是备份数据一致最后一个矫正点,在利用该备份进行恢复时,即从该LSN作为起点,之后的所有redo log记录的更新都需要重做或者回滚。记录了LSN之后,xtrabackup就找到了一个数据一致点,然后直接拷贝数据文件。

Innodb存储引擎的表文件主要包括以下几类:

  • ibdata1:默认表空间文件,如果没有设置innodb_file_per_table,则所有的表都是共用同一个文件的。如果启动了innodb_file_per_table,每张表的索引、数据和插入缓冲BITMAP信息是按照表分别独立存放在不同的文件中,但是undo log等其他信息还是存放在默认表空间中。

  • table_name.bid:表文件,存放每张表的数据、索引和插入缓冲。

  • ib_logfile0: 重做日志文件,备份前记录的LSN和备份结束时的LSN之间的redo log xtrabackup是需要保存的,用于在恢复时进行回放或者回滚。

MySQL的redo log是重用的,即检查点之间的redo log存在被覆盖的风险,而备份前和备份结束后之间的redo log是需要完整保存的,不允许被覆盖,如果备份时间比较长,redo log比较小的情况下,存在备份还没结束,原先记录的LSN之后的redo log即被覆盖,导致更新丢失的问题。为了解决该问题,xtrabackup额外启动了一个线程,不断的扫描redo log日志,一旦发现LSN有推进,则立即将该部分redo log拷贝出来,避免被覆盖。之后xtrabackup就开始拷贝包括默认表空间文件在内的所有表文件,直到拷贝结束,然后记录LSN,这样就完成了innodb表的备份。

从前面我们对数据库备份过程上锁的必要性的分析可知,除了解决数据文件的一致性外,还需要解决DDL和获取Binlog的问题。而该问题就需要依赖innobackupex来完成,首先在xtrabackup拷贝完数据文件后,innobackupex在MySQL上执行flush table with read lock,该操作会锁定整个实例的所有带X锁的读,更新、插入、删除和DDL语句,相当于冻结了LSN。此时MySQL 当前LSN不会再推进,然后记录LSN,此为最终一致的LSN;然后记录当前Binlog的文件名和位置;接着开始拷贝MySQL的表定义文件(.frm),myisam表文件;最后unlock tables释放锁,这样就完成了一次完整的备份过程。