likes
comments
collection
share

数据库备份

作者站长头像
站长
· 阅读数 19

数据库备份

数据库备份

MYSQL数据备份相信大家都很熟悉，听过、见过、玩过，我们这次就来对 MYSQL 备份做一个介绍

首先理一下备份有哪些类型，可以按不同的维度来做解释

备份类型

  • 按根据服务器状态

    • 热备份：读、写不受影响
    • 温备份：仅可以执行读操作
    • 冷备份：离线备份；读、写操作均中止

  • 按从结果对象

    • 物理备份：复制数据文件
    • 逻辑备份：将数据导出至文本文件中

接下来，对应这些备份类型可以用哪些备份工具来操作呢

备份工具

MySQL自带的备份工具

  • mysqldump 逻辑备份工具，支持所有引擎，MyISAM引擎是温备，InnoDB引擎是热备，备份速度中速，还原速度非常非常慢，但是在实现还原的时候，具有很大的操作余地。具有很好的弹性。
  • mysqlhotcopy 物理备份工具，但只支持MyISAM引擎，基本上属于冷备的范畴，物理备份，速度比较快。

文件系统备份工具

  • cp 冷备份，支持所有引擎，复制命令，只能实现冷备，物理备份。使用归档工具，cp命令，对其进行备份的，备份速度快，还原速度几乎最快，但是灵活度很低，可以跨系统，但是跨平台能力很差。 可以冷备份的前提是表刷完脏数据并且全局锁表（mysql> FLUSH TABLES WITH READ LOCK; UNLOCK TABLES;）又或者是直接停止服务
  • LVM 几乎是热备份，支持所有引擎，基于快照(LVM，ZFS)的物理备份，速度非常快，几乎是热备。只影响数据几秒钟而已。但是创建快照的过程本身就影响到了数据库在线的使用，所以备份速度比较快，恢复速度比较快，没有什么弹性空间，而且LVM的限制：不能对多个逻辑卷同一时间进行备份，所以数据文件和事务日志等各种文件必须放在同一个LVM上。而ZFS则非常好的可以在多逻辑卷之间备份。

收费工具

  • ibbackup 商业工具 MyISAM是温备份，InnoDB是热备份 ，备份和还原速度都很快，这个软件它的每服务器授权版本是5000美元。
  • mysqlbackup ORACLE公司也提供了针对企业的备份软件MySQL Enterprise Backup简称：mysqlbackup

开源工具

  • xtrabackup 开源工具 MyISAM是温备份，InnoDB是热备份 ，是ibbackup商业工具的替代工具。
  • mydumper 支持多线程导出，速度更快。

既然有这么多备份工具，那么应该怎么去备份呢，他们又是怎么去做备份的，我们选三种备份方式来介绍一下他们的操作方式和原理

备份介绍

基于LVM快照备份

LVM原理

当源数据改变的时候呢，cow就会记录下改变的值，当从快照读出的时候，如果数据没有改变那还是读取原来lvm的数据，如果数据改变了，那么该读取cow上面的数据。所以原来的lvm，也就是创建快照之前的lvm和现在cow快照上的数据是一致的。

优点

  • 几乎是热备，不需要停mysql服务器，但是在执行快照时，依然要加上锁虽然时间很短
  • 备份速度快
  • 无需使用其他软件

缺点

  • 无法预计服务停止时间，上锁时间，取决于上锁前执行最长的查询语句
  • 数据如果分布在多个物理卷上就可能复杂的多

操作步骤

  mysql>FLUSH TABLES WITH READ LOCK;
2.刷新一下二进制日志，便于做时间点恢复
  mysql>FLUSH LOGS；
3.然后创建快照卷
  lvcreate –L 1G –s –n data-snap –p –r /opt/mysql/3306/data
4.最后进入数据库释放读锁
  UNLOCK TABLES;
5.挂载快照卷进行备份
  mount –r /dev/myvg/data-snap /mnt/snap
最后然后对/mnt/snap下的文件进行打包备份

mysqldump

mysqldump客户端可用来转储数据库或搜集数据库进行备份或将数据转移到另一个SQL服务器(不一定是一个MySQL服务器)。转储包含创建表和/或装载表的SQL语句。

mysqldump可提供两种格式的文件输出，分别是sql格式的标准输出和文件分隔符形式的输出。也可直接在两个mysql数据库之间进行数据复制。

优点

  • mysql自带，使用方便，备份结果容易操作。少量数据可以使用mysqldump。

缺点  

  • 大量数据下，使用mysqldump恢复较慢，mysqldump再导入数据的时候，都是使用sql语句，需要开启事务，不建议使用。大数据量建议使用XtraBackup。

原理分析

mysql> set global general_log=ON;
Query OK, 0 rows affected (0.10 sec)
​
mysql> show variables like '%general%';
+------------------+------------------------------------+
| Variable_name    | Value                              |
+------------------+------------------------------------+
| general_log      | ON                                 |
| general_log_file | /opt/mysqldata/general.log         |
+------------------+------------------------------------+
2 rows in set (0.01 sec)
​
mysql> \q
Bye

mysqldump备份数据库

mysqldump -S /opt/mysqldata/mysql.sock -p --single-transaction --master-data=2 db_test > db_test.sql

查看general log

数据库备份

  1. Connect   root@localhost on  using Socket 首先连接到数据库connect
  2. FLUSH !40101 LOCAL/ TABLES 如果不加参数 --master-data 就无此步骤关闭所有打开的表，强制关闭所有正在使用的表，并且将所有更新的数据刷新到磁盘，这个时间不会锁表。
  3. FLUSH TABLES WITH READ LOCK 如果不加参数--master-data就无此步骤,执行flush tables操作，并且加一个全局读锁，这个命令貌似与上一个命令重复， 为什么不在第一次执行flush tables操作的时候加上锁呢？

   原因是为了避免较长的事务操作造成FLUSH TABLES WITH READ LOCKS操作迟迟得不 到锁，但同时又阻塞了其他客户端操作。第一次的flush也是为了尽量减少第二次flush持有锁的时间。

  1. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 设置当前会话的事务隔离级别为RR，RR可避免不可重复读和幻读。
  2. START TRANSACTION / !40100 WITH CONSISTENT SNAPSHOT/ 获取当前数据库的快照，这个是由mysqldump命令中的参数—single-transaction决定的。 这个只适用于支持事务的表，在mysql中，只有Innodb

注意：START TRANSACTION和START TRANSACTION WITH CONSISTENT SNAPSHOT并不一样。后者是开启事务的一致性快照。

官方解释：
The WITH CONSISTENT SNAPSHOT modifier starts a consistent read for storage engines that are capable of it. This applies only to InnoDB. The effect is the same as issuing a START TRANSACTION followed by a SELECT from any InnoDB table.

简而言之，就是开启事务并对所有表执行了一次 select 操作，这样可以保证备份时，在任意时间点执行 select * from table 得到的数据和执行 START TRANSACTION WITH CONSISTENT SNAPSHOT 时的数据一致。也就是说 START TRANSACTION 是在第一条 select 执行完后，才得到事务的一致性快照，而 START TRANSACTION with consistent snapshot 则是立即得到事务的一致性快照。

举个栗子

  • 事务 start transaction 数据库备份
  • 事务 start transaction with consistent snapshot; 数据库备份
  1. SHOW MASTER STATUS 这个是由 --master-data 决定的，记录开始备份时， binlog 的状态信息，包括 MASTER_LOG_FILE 和 MASTER_LOG_POS 。
  2. UNLOCK TABLES 释放锁。

再继续看 general log

数据库备份

从上述日志输出可以看出：

  1. 备份的核心是SELECT /*!40001 SQL_NO_CACHE */ * FROM sbtest1语句     该语句会查到表sbtest1的所有数据，在备份文件中生成相应的insert语句。 SQL_NO_CACHE的作用是查询结果不会缓存到查询缓存中。
  2. show create table sbtest1 生成建表语句。
  3. SHOW TRIGGERS LIKE ‘sbtest1' 如果不加-R参数，默认是会备份触发器的。
  4. 设置 SAVEPOINT，然后备份完一个表再回滚到该 SAVEPOINT。前面通过 START TRANSACTION WITH CONSISTENT SNAPSHOT 开启的事务只能通过 commit 或者 rollback 结束，而不是 ROLLBACK TO SAVEPOINT sp 。这样做不会阻塞在备份期间对已经备份表的 ddl 操作，可以提高 DDL 的并发性。

当我们 dump 完一个表后后面都不再需要使用这个表，这时其他事务的 DDL 操作不会影响我们 dump 得到数据的正确性，增加 savepoint 的意义在于，假如我们要 dump 表 A，savepoint 记录了 dump 表 A 之前尚未给表A加MDL锁的状态，当开始dump表A时，由于要进行一系列 select 操作，会给表 A 加上 MDL 锁防止其他事务的 DDL 操作改变表结构导致读动作出错；最后当对表 A 的 dump 完成后，后续都不会再访问表A了，此时没有释放的 MDL 锁没有意义，反而会阻塞其他并行事务对表 A 的 DDL 操作。

Xtrabackup

Xtrabackup优点

  • 备份速度快，物理备份可靠
  • 备份过程不会打断正在执行的事务（无需锁表）
  • 能够基于压缩等功能节约磁盘空间和流量
  • 自动备份校验
  • 还原速度快
  • 可以流传将备份传输到另外一台机器上
  • 在不增加服务器负载的情况备份数据

备份操作简述

Xtrabackup 备份原理备份开始时，首先会开启一个后台检测进程，实时检测 mysql redo 的变化，一旦发现有新的日志写入，立刻将日志记入后台日志文件xtrabackup_log 中，之后复制 innodb 的数据文件一系统表空间文件 ibdatax ，
复制结束后，将执行 flush tables with readlock ,然后复制 .frm MYI MYD等文件，最后执行unlock tables,最终停止xtrabackup_log。

接下来看一张图

数据库备份

对照着这张图，再做一次比较详细的解释

  1. innobackupex 启动后，会先 fork一个进程，用于启动 xtrabackup ，然后等待 xtrabackup 备份 ibd 数据文件；
  2. xtrabackup 在备份 innoDB 数据是，有2种线程：redo 拷贝线程和ibd数据拷贝线程。xtrabackup 进程开始执行后，会启动一个 redo 拷贝的线程，用于从最新的checkpoint点开始顺序拷贝 redo.log，查看 checkpoint 点的 redo.log 的初始LSN号。
  3. 启动 ibd 数据拷贝线程，进行拷贝 ibd 数据。这里是先启动 redo 拷贝线程的。在此阶段，innobackupex 进行处于等待状态（等待文件被创建）
  4. xtrabackup 拷贝完成 ibd 数据文件后，会通知 innobackupex （通过创建文件），同时 xtrabackup 进入等待状态（ redo 线程依旧在拷贝 redo.log）
  5. innobackupex 收到 xtrabackup 通知后，执行 FLUSH TABLES WITH READLOCK（FTWRL），取得一致性位点，然后开始备份非 InnoDB 文件（如frm、MYD、MYI、CSV、opt、par等格式的文件），在拷贝非 InnoDB 文件的过程当中，数据库处于全局只读状态。
  6. 当 innobackup 拷贝完所有的非 InnoDB 文件后，会通知 xtrabackup ，通知完成后，进入等待状态；
  7. xtrabackup 收到 innobackupex 备份完成的通知后，会停止 redo 拷贝线程，然后通知 innobackupex ，redo.log 文件拷贝完成，记录 LSN 号；
  8. innobackupex 收到 redo.log 备份完成后，就进行解锁操作，执行：UNLOCK TABLES；
  9. 最后 innbackupex 和 xtrabackup 进程各自释放资源，写备份元数据信息等，innobackupex 等 xtrabackup 子进程结束后退出。

增量备份依赖于全备份

  • xtrabackup实现增量备份的原理是通过比较全备份的终点LSN和当前的LSN，增备时将从终点LSN开始一直备份到当前的LSN。
  • 在备份时也有redo log的监控线程，对于增备过程中导致LSN增长的操作也会写入到日志中。

推荐阅读

重构-把代码写的更漂亮

浅析大数据OLAP引擎-Presto

指标体系的设计和思考

redis 性能分享

基于gitlab ci_cd实现代码质量管理

招贤纳士

政采云技术团队（Zero），一个富有激情、创造力和执行力的团队，Base 在风景如画的杭州。团队现有 500 多名研发小伙伴，既有来自阿里、华为、网易的“老”兵，也有来自浙大、中科大、杭电等校的新人。团队在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com

微信公众号

文章同步发布，政采云技术团队公众号，欢迎关注

数据库备份

转载自:https://juejin.cn/post/7181611401398452283
评论
请登录