InnoDB 个性化备份

如果想知道如何使用xtrabackup，请翻阅之前的文章 xtrabackup核心文档

xtrabackup原理深入浅出

为什么要使用xtrabackup

  • 常用的备份有哪些

  • 性能对比

  • 逻辑备份 vs 物理备份

    逻辑备份优点: 占用空间小，安全
    逻辑备份缺点: 恢复速度慢
    物理备份优点: 备份，恢复速度快
    物理备份缺点: 占用空间大

  • 如何选择，全凭业务场景

    如果类似facebook这种量级（PB，EB），考虑成本，建议逻辑备份
    如果只是上T级别，建议物理备份
    本人用的是物理备份，还有一个原因就是： 逻辑备份会遭到DDL的破坏
    试想，晚上经常有DDL这样的操作，备份任务不可能随意调整，这样带来的运维成本很大

  • 物理备份：InnoDB vs Myisam

    Myisam引擎，只需要flush tables后，就可以随意拷贝文件
    InnoDB可通过xtrabackup来拷贝文件

    在5.6之前，我比较喜欢用Myisam引擎来做备份，原因是就是备份和恢复的速度以及随意拷贝的便利性
    在5.6之后，由于可传输表空间的出现，让恢复单表变得简单，我更加愿意用InnoDB备份。关于可传输表空间，可阅读transportable tablespace详解
    用Myisam的一个致命弱点是：如果要还原成innoDB表，需要转换表引擎，痛苦的开始
    至于InnoDB和Myisam的选择，就不用纠结了，因为之后的MySQL会废弃掉Myisam

什么是一致性备份

简单来说，就是备份的数据都处在同一时间点

percona xtrabackup基本概念

innobackupex 是一个perl写的脚本，为了方便，封装了xtrabackup，所以一般备份都用innobackupex
xtrabackup 只备份innoDB表 ，其余的都交给innobackupex
新版本如：2.4，2.3.xx 已经将innodbex用c 重写了，然后链接到xtrabackup

xtrabackup for 5.6 备份原理

  1. innobackupex 调用 xtrabackup --suspend-at-end
  2. xtrabackup 开始拷贝 innodb 数据文件,共享表空间
  3. 当xtrabackup拷贝完innodb文件后，会创建 xtrabackup_suspended_2
  4. 当innobackupex看到xtrabackup_suspended_2文件被创建后，进行加锁
    a. FLUSH NO_WRITE_TO_BINLOG TABLES
    b. FLUSH TABLES WITH READ LOCK
  5. innobackupex开始检查db server支持的特性，如：gtid，backup locks，changed page bitmap等
  6. 然后开始拷贝非innodb文件，以及表结构frm
  7. 当所有的文件都备份完成后，结束redo 事务的拷贝。
  8. 接下来释放锁
    a. FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
    b. UNLOCK TABLES
  9. 删除xtrabackup_suspended_2文件 , 并且退出

从上述流程图可以看出，FLUSH TABLES WITH READ LOCK【FTWRL】 这个时间点，就是备份恢复的时间点，即一致性点
因为数据再拷贝的过程中是不一致的，MySQL利用其自身的crash recover机制，用redo来保证最终一致性

这里，假设一种场景，InnoDB是16k的刷新，当刷新到4k的时候，拷贝线程来讲这个页拷贝走，这样不就人为的造成了一次partial-write了吗？
对于partial-write的场景，由于redo日志是物理逻辑的，通过redo没有办法恢复，这可如何是好呢？

这里是核心：

  1. xtrabackup方式： xtrabackup里面做了很多事情，它在拷贝的过程中使用innodb的buf_page_is_corrupted()函数检查此页的数据是否正常，如果不正常，再重新拷贝，尝试N次重试之后还不行，就退出报错。
  2. flush-method=O_direct，会直接从innodb buffer 写入到 磁盘，这个操作可能就会发生partial-write了。一旦发生这样的事情，MySQL是无法恢复的，所以，我们的备份必须保证脏页全部刷新完，也就是在备份程序中 a）必须保证没有写了 b）必须验证和检测Modified db pages是否等于0。 如果以上都ok，那么这个页肯定是完整的。除此之外，我们还有一招，就是多次rsync，确保完整。
  3. flush-method=默认 ， 默认的会先从innodb buffer 写入到 OS缓存，这个操作是原子的，由操作系统保证。

生产环境如何备份

备份的意图：备份master或者slave上的数据，然后传输到一个挂有大磁盘的服务器上，保留若干天

问题1，如何传输到其他服务器呢？

  1. 这个问题，xtrabackup也考虑到了，用xbstream + ssh 的方式，但是有一个致命的缺点，就是无法断点续传，如果网络断掉，那就悲剧
  2. 另外一个方式就是：先xtrabackup到本地一个目录，然后用rsync【支持断点续传】来传送到远端服务器。 这种方法的致命缺点是：本地磁盘需要浪费一半的空间,且copy了两遍备份数据

以上两种方式都存在缺陷，那么我们不得不思考第三种方式，是否可以直接copy到远端机器呢？

  • 如果是在master上备份，那么直接copy是不行的，因为redo一直再变且轮询

  • 如果是在slave上，或者etl&backup机器上呢？ 不难发现，xtrabackup记录了redo的变化，如果我们人为的让redo不再增长，stop slave，这样的备份原理是否和xtrabackup一样呢？

这样做的好处是，不用浪费一半的空间，也不需要传送2次

你所不知道的秘密

通过以上流程图，可以发现一个重要的线索：我们的物理备份，是不会备份binlog的【重要】
所以，友谊的小船说翻就翻

对于5.1 & 5.5，用xtrabackup for 5.1 or 5.5 ，如果innodb_flush_log_at_trx_commit=1 ,应该没问题

对于5.6 ， 用xtrabackup for 5.1 or 5.5 ， 即便如果innodb_flush_log_at_trx_commit=1，有可能会丢失事务

对于5.6 ， 用xtrabackup for 5.6， 不会丢失事务

直接copy innoDB的方式备份

好了，现在进入正题，我们是否可以类似Myisam的方式随意拷贝呢？

答案：可以

  • 第一种方法： 保持和Myiam一致就可以。

Myisam之所以可以随意拷贝，那是因为通过flush tables后，所有文件都会fsync到磁盘，这时候拷贝肯定没有问题。
InnoDB则不是，通过flush tables根本没有办法控制redo的刷新，data page的刷新以及ibdata的刷新。
所以，这里我们只要解决这三个问题即可。
redo: 我们可以通过innodb_flush_log_at_trx_commit=1来保证。
data page: 通过自身的checkpoint可以保证。
ibdata里面包含了：innodb table的数据字典信息，change buffer，doublewrite ，undo logs，这些目前好像还没有什么可以强制全部刷新。

所以，我们可以通过stop slave的方式，至少可以保证数据不丢失。至于ibdata里面的文件不刷新，也没太大关系，通过自身的crash-recover机制，自动修复。
所以，我们通过stop slave后，直接copy文件恢复的时候，你可能会看到这样的信息：

2016-05-26 13:47:24 15818 [Note] InnoDB: The log sequence numbers 2446418 and 2446418 in ibdata files do not match the log sequence number 2446945 in the ib_logfiles!
2016-05-26 13:47:24 15818 [Note] InnoDB: Database was not shutdown normally!
2016-05-26 13:47:24 15818 [Note] InnoDB: Starting crash recovery.
2016-05-26 13:47:24 15818 [Note] InnoDB: Reading tablespace information from the .ibd files...
2016-05-26 13:47:24 15818 [Note] InnoDB: Restoring possible half-written data pages
2016-05-26 13:47:24 15818 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Last MySQL binlog file position 0 506, file name tjtx-101-141.000018
2016-05-26 13:47:25 15818 [Note] InnoDB: 128 rollback segment(s) are active.
2016-05-26 13:47:25 15818 [Note] InnoDB: Waiting for purge to start
2016-05-26 13:47:26 15818 [Note] InnoDB: 5.6.27 started; log sequence number 2446945
2016-05-26 13:47:26 15818 [Note] Recovering after a crash using /data/mysql.bin/tjtx-101-141
2016-05-26 13:47:26 15818 [Note] Starting crash recovery...
2016-05-26 13:47:26 15818 [Note] Crash recovery finished.

当你看到Crash recovery finished完成后，基本也就ok了。

好了，这里还有一个疑问我不太清楚，就是到底有多少个LSN

Log sequence number 2446945  -- redo log buffer 中的lsn，内存中记录
Log flushed up to   2446945  -- redo log file 的lsn，redo的每个lock block都会记录
Pages flushed up to 2446945  -- flush list中最后一个指针对应的page's newest modification(lsn)【last checkpoint newest modification】, 每个page的头部都会记录
Last checkpoint at  2446945  -- flush list中最后一个指针对应的page's oldest modification(lsn)【last checkpoint oldest modification】, 第一个redo的头部固定位置，存在头部的两个地方

那么错误日志中的The log sequence numbers xx in ibdata files ，又是啥呢？

经过测试：kill -9 mysqld
得到的结论是： 只要是非正常关闭的MySQL，都会出现这样的报错，即便是没有任何数据的MySQL
所以，我猜测，ibdata files中记录的lsn，从MySQL一启动，里面的lsn就会比redo中的lsn小，是专用于检测是否正常关闭MySQL的吗？
anyway，这都不影响我们innoDB在线拷贝的大局了。

好了，通过以上测试，我们已经明白，stop slave后，等一会会，当脏页刷新完的时候，就可以认为数据全部刷新到磁盘了，这样就和Myisam没有任何区别

ok，这里又引入了一个值得思考的问题，那就是： 怎么判断脏页已经刷完了呢？

检查4个lsn，当四个lsn都相等的时候，肯定刷完了。

Log sequence number 2446945
Log flushed up to   2446945
Pages flushed up to 2446945
Last checkpoint at  2446945

没错，当4个lsn都相等的时候，的确可以表示脏页已经刷完。

但是，当4个lsn不完全相等的时候，也有可能表示脏页刷完了。比如：

Log sequence number 2446945
Log flushed up to   2446945
Pages flushed up to 2446945
Last checkpoint at  2446747 --不一样

我来解读一下：
Last checkpoint 指的是最后一个脏页的oldest modification
Pages flushed up to 指的是最后一个脏页的newest modification

当我们再刷最后一个脏页的时候，这个脏页被多次更新，那么就表示该脏页的newest modification > oldest modification .
所以就不相等了，但是的确脏页也都刷新完了。

检查Modified db pages的值，这个值就表示flush list中还有多少个page没有被刷新，如果全为0，表示flush list中脏页全部刷新。

假设一个实例有2个BUFFER POOL instance，那么就要检查两个Modified db pages 是否都为0

---BUFFER POOL 0
Buffer pool size   655359
Free buffers       1000
Database pages     636541
Old database pages 234953
Modified db pages  0  -- 表示这个buffer pool中的脏页已经刷新完
Pending reads 0

---BUFFER POOL 1
Buffer pool size   655359
Free buffers       1000
Database pages     636426
Old database pages 234910
Modified db pages  0 -- 表示这个buffer pool中的脏页已经刷新完
Pending reads 0

两个都刷新完，表示flush list中已经没有脏页了。
  • 第二种方式

stop slave后，如果脏页没有刷新完呢？不相等，我们还能拷贝吗？
答案是：当然可以。
lsn不相等，意味着，我们crash-recover的时候需要通过redo来恢复数据，稍微慢点而已，不影响大局。

重要

所以，不管以上两种方式的哪一种，如果你想通过stop slave的方式，直接拷贝文件的话，最好执行下

FLUSH NO_WRITE_TO_BINLOG TABLES
FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS

这样，就跟xtrabackup没什么区别了

时间： 2024-03-05 07:01:18

InnoDB 个性化备份的相关文章

Xtrabackup使用指南 InnoDB数据备份工具_Mysql

一.Xtrabackup介绍 A.Xtrabackup是什么 Xtrabackup是一个对InnoDB做数据备份的工具,支持在线热备份(备份时不影响数据读写),是商业备份工具InnoDB Hotbackup的一个很好的替代品. Xtrabackup有两个主要的工具:xtrabackup.innobackupex 1.xtrabackup只能备份InnoDB和XtraDB两种数据表,而不能备份MyISAM数据表 2.innobackupex是参考了InnoDB Hotbackup的innoback

MYSQL数库中的MyISAM如何转化为InnoDB

http://dev.mysql.com/doc/refman/5.6/en/converting-tables-to-innodb.html 查出所有表的信息, 显示为MyISAM为MyISAM引擎 SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES where TABLE_SCHEMA = 'dbname'; 第二步就是转化MyISAM, 成为InnoDB引擎 ALTER TABLE tablename ENGINE=InnoDB

金山装机精灵 2.0 beta下载与体验（重装系统、一站式装驱动、备份与还原数据）

之前向大家介绍过"一键GHOST"这个系统备份还原工具,并且我也是一直在用,进行系统还原的速度是非常的快的,一般都能在5分钟之内还原好. 金山装机精灵是一款免费的装机软件,能够一键式.一站式地满足普通电脑用户的各类装机要求,定位于电脑第一款必备安装软件.它的主要功能包括装驱 动.装补丁.装软件.硬件检测.备份数据.还原数据.系统重置等.其中,系统重置功能类似重装系统,但不需要安装盘,操作更为便捷:装驱动功能采用"驱动 精灵"的核心技术,拥有国内最全的驱动库:它还可随

MyRocks之备份恢复

title: MySQL · myrocks · myrocks之备份恢复 author: 张远 myrocks支持逻辑备份和物理备份,逻辑备份仍然采用mysqldump,物理备份采用自己开发的myrocks_hotbackup工具,传统的物理备份工具Xtrabackup不支持rocksdb.由于rocksdb的存储特性,myrocks不管是逻辑备份还是物理备份,与innodb的备份恢复均有较大差别. 逻辑备份 myrocks的mysqldump工具支持rocksdb的逻辑备份,其使用方式与原生

MySQL备份原理详解_Mysql

本文为大家介绍了MySQL备份原理,欢迎大家阅读. 备份是数据安全的最后一道防线,对于任何数据丢失的场景,备份虽然不一定能恢复百分之百的数据(取决于备份周期),但至少能将损失降到最低.衡量备份恢复有两个重要的指标:恢复点目标(RPO)和恢复时间目标(RTO),前者重点关注能恢复到什么程度,而后者则重点关注恢复需要多长时间.这篇文章主要讨论MySQL的备份方案,重点介绍几种备份方式的原理,包括文件系统快照(LVM),逻辑备份工具Mysqldump,Mydumper,以及物理备份工具Xtraback

MySQL · myrocks · myrocks之备份恢复

myrocks支持逻辑备份和物理备份,逻辑备份仍然采用mysqldump,物理备份采用自己开发的myrocks_hotbackup工具,传统的物理备份工具Xtrabackup不支持rocksdb.由于rocksdb的存储特性,myrocks不管是逻辑备份还是物理备份,与innodb的备份恢复均有较大差别. 逻辑备份 myrocks的mysqldump工具支持rocksdb的逻辑备份,其使用方式与原生的mysqldump备份innodb没有区别,一般的使用方式如下 mysqldump -uroot

MySQL实战系列4: 主从复制、读写分离、备份恢复全解析

作者介绍 索宁擅长Python开发.MySQL.前端等众多技术领域曾负责众多企业安全架构解决方案 涉猎行业有媒体.出版社.航空运输.医疗.军队.政府.教育等.   一.MySQL主从复制   1.简介   我们为什么要用主从复制   主从复制目的 可以做数据库的实时备份保证数据的完整性 可做读写分离主服务器只管写从服务器只管读这样可以提升整体性能.   原理图 从上图可以看出同步是靠log文件同步读写完成的.   2.更改配置文件   两天机器都操作确保 server-id 要不同通常主ID要小

InnoDB 隔离模式对 MySQL 性能的影响

InnoDB 隔离模式对 MySQL 性能的影响 过去的几个月我写了两篇文章,一篇是InnoDB 事务历史相关的危险债务,另一篇是关于MVCC 可能导致MySQL严重的性能问题的真相.在这篇文章里我将讨论一个相关的主题 – InnoDB 事务隔离模式,还有它们与MVCC(多版本并发控制)的关系,以及它们是如何影响MySQL性能的. MySQL手册提供了一个关于MySQL支持的事务隔离模式的恰当描述 – 在这里我并不会再重复,而是聚焦到对性能的影响上. SERIALIZABLE – 这是最强的隔离

浅谈InnoDB隔离模式的使用对MySQL性能造成的影响_Mysql

在这篇文章里我将讨论一个相关的主题 – InnoDB 事务隔离模式,还有它们与MVCC(多版本并发控制)的关系,以及它们是如何影响MySQL性能的. MySQL手册提供了一个关于MySQL支持的事务隔离模式的恰当描述 – 在这里我并不会再重复,而是聚焦到对性能的影响上. SERIALIZABLE – 这是最强的隔离模式,本质上打败了在锁管理(设置锁是很昂贵的)的条件下,多版本控制对所有选择进行锁定造成大量的开销,还有你得到的并发.这个模式仅在MySQL应用中非常特殊的情况下使用. REPEATA