mysql备份原理详解
本文介绍了mysql备份的原理，欢迎大家阅读。备份是数据安全的最后一道防线。任何数据丢失的情况下，备份并不总是能够恢复百分之一百数据（取决于备份的时间），但至少可以减少损失。有备份恢复的两个重要指标：恢复点目标（RPO）和恢复时间目标（RTO）。在何种程度上可以恢复以前的重点，后者强调的是需要多长时间来恢复。本文主要讨论了MySQL的备份方案，着重对几种备份方法的原理，包括文件系统快照（LVM），逻辑备份工具mysqldump，Mydumper，和物理备份工具XtraBackup，在同时将详细介绍了几种方案的优缺点说明，和可能遇到的问题。
冷备份
备份最简单的方法是关闭MySQL服务器，然后复制并保存数据目录中的所有文件。当你需要恢复，复制目录，需要恢复的机器，这是一种方便的方法，但没有多大效果的生产环境，因为所有的机器都需要提供服务，甚至奴隶有时需要提供只读服务，因此关闭MySQL和花备份是不现实的。对应于冷备份的概念是热备份。所谓热备份就是备份而不影响MySQL的外部服务。热备份是本文的重点。
快照备份
首先，热备份是快照备份，快照备份指的是通过文件系统支持的快照功能对数据库进行备份，备份的原则是将所有数据库文件放在同一分区中，然后为分区执行快照工作。对于Linux，它需要通过LVM（逻辑卷管理器），LVM使用写复制（copy-on-write）例如创建一个片刻，快照技术，对InnoDB存储引擎的整个体积的逻辑副本是类似MVCC的数据库，但LVM快照文件系统层，和MVCC在数据库级别，并且只支持InnoDB存储engine.lvm有快照保留区。如果原始数据量的变化，是保证受影响的块将被复制到快照保留区的任何改变之前写的。简而言之，所有旧的数据一致的快照开始保存在快照区，几个数据库快照将很小。MySQL，为了使用快照备份，你需要把数据文件，日志文件在一个逻辑卷，然后卷的快照备份，快照备份，它只能是本地的，所以快照如果本地磁盘受损。快照备份更偏向防误操作预防。它能快速地将数据库还原到快照生成的时间点，然后与二进制日志结合，恢复到指定的时间点：
逻辑备份
冷快照备份由于其缺点是很少使用在生产环境中，更多的是使用MySQL的逻辑备份和物理备份工具，这部分主要是对逻辑备份，官方的MySQL mysqldump逻辑备份工具，虽然好，但有一个缓慢的备份线程的。较好的逻辑备份工具，mydumper，在社区。其优点主要体现在多线程备份，备份速度更快。
mysqldump
mysqldump是用于备份和已开展的两个关键参数：
单交易：执行备份之前，执行交易指令开始得到一致的备份，只对InnoDB存储引擎是有效的。
-主数据= 2：该站点主要用于记录一致备份。
工作原理的理解就必须使事务表之间的差异（InnoDB）和非事务表（如表），因为备份过程有着密切的关系。而且，到目前为止，我们无法逃避的MyISAM表，即使我们所有的业务表InnoDB，因为MyISAM表这是仍在使用的MySQL库。
备份的基本过程如下：
1。电话ftwrl（FLUSH TABLES WITH READ锁），阅读和写作的全球禁令
2。打开快照，此时得到的快照（只对InnoDB表）
三.备份非InnoDB表数据（*。FRM，*我，*，MVD，等）
4。当非InnoDB表的备份，这ftwrl锁被释放
5。备份InnoDB表的数据一个接一个
6。备份完成。
整个过程中，图片可以参考我的同事，但他的画只考虑备份InnoDB表，甚至在打开表执行，非InnoDB表已经备份，在T1、T2和T3是InnoDB表的本质，并用5.6就节省点机制，每一个表将备份在一台MDL锁释放，避免了较长一段时间表锁。
你可能会有疑问，为什么之前备份InnoDB表有一个锁释放出来，这实际上是InnoDB引擎的MVCC机制的使用，阅读后打开快照，可以得到时间一致的数据，不管多久需要备份，直到交易结束（提交）。
mydumper
mydumper的原理类似于mysqldump原理。最大的区别是引入了多线程备份。每个备份线程备份表的一部分。当然，并行粒度可以去行级实现多线程备份的目的。要解决的最大的问题是如何保证一致性备份，关键是ftwrl。一个非InnoDB表，一个表备份之前需要完成的锁被释放，InnoDB表，我们需要保证多个线程可以得到一致性位点。这个操作也需要在持有全局锁时完成，因为数据库当时没有读写，这就保证了轨迹的一致性，所以基本流程如下：
物理备份（XtraBackup）
逻辑备份相比，使用查询来提取数据中的所有记录，物理备份是更直接，复制数据库文件和日志完成备份，所以速度会更快。当然，开放源代码Mydumper和官方最新的备份工具（5.7.11的mysqlpump）支持多线程备份，所以速度差异可能进一步减少。至少从目前的生产环境，物理备份仍然使用。因为XtraBackup支持备份InnoDB表，我们用在实际生产环境的工具innobackupex，这一层封装的XtraBackup，innobackupex脚本用于备份非InnoDB表，和XtraBackup命令调用备份InnoDB表。基本innobackupex过程如下：
1。打开重做日志复制线程，并从最新的检查点复制重做日志。
2。打开数据库文件复制线程和复制InnoDB表的数据
3.idb文件复制结束，通知称ftwrl获得一致性位点
4。备份非InnoDB表（系统表）和FRM文件
5。因为此时没有新的事务要提交，等待重做日志复制完成。
6。重做日志文件的最新副本完成后，此时的InnoDB和非InnoDB表数据等效是最新的
7。得到binlog网站，此时数据库的状态是一致的。
8。释放锁，备份端。
改进的XtraBackup
从逻辑和物理备份之前介绍的，无论备份工具，他们都强烈地依赖于ftwrl为了获得一致的网站。这个锁是非常致命的，因为整个数据库无法提供写作服务本质上因持有锁的时间。此外，因为ftwrl需要关闭表，如果有一个大的查询，它将导致ftwrl等，从而为DML封锁时间较长。即使它是一个库，有SQL线程，源于主库的更新，而当全球锁，它会导致主库的延迟。从前面的分析，对ftwrl锁定时间是那不是InnoDB表的数据量的主要因素。如果在非InnoDB表的数据量大，备份是缓慢的，时间在锁会很长。即使是InnoDB表，它会锁定某个时间由于对mysql数据库系统表的存在。为了解决这一问题，MySQL服务器层的Percona公司改进，备份的锁，介绍说，locktables备份命令来备份非InnoDB表数据；通过锁binlog备份获得该网站的一致性，尽量减少数据库的备份服务带来的损坏，因为吧。在两锁和FTWRL之间的差异看：
备份表
角色：备份数据
1。禁止非InnoDB表的更新
2。禁止所有表的DDL
优化点：
1。不会被大查询阻塞（关闭表）
2。挡不住的阅读和InnoDB表更新。这是非常重要的。所有的业务表InnoDB，DML完全没有损坏的备份过程。
unlocktables
锁binlog备份
获得一致性位点。
1。禁止对位法更新的操作
优化点：
1。直到binlog写允许DDL和更新。
unlockbinlog
以上是本文的全部内容，希望能对大家有所帮助。