MySQL全方位灾备保护应用趋势
在数据库产品的购置上，相对于 Oracle等数据库软件，MySQL的采购费用非常低。
如果企业选择 MySQL 社区版，由于遵循着开源协议，可以理解为免费使用。
在部署环境的建设上，Oracle等数据库对服务器、存储设备的配置要求都远高于MySQL数据库。
所以在建设成本上，MySQL的建设成本占有很大优势。
同时，在数据库的维护上，MySQL的开源属性，让用户更容易去掌握和管理数据库，相对于Oracle等数据库需要购买厂家支持服务来说，维护成本上也占有很大优势。
但是，企业对 MySQL 数据库的使用，一直存在一些问题和困扰。比如说：数据承载能力、数据安全保护等。
对于数据库的承载能力，技术专家们通过业务分拆，分布式存储等多种解决方案来设计和实施，已得到了很好的解决，本文就不细表。
对于 MySQL 的数据安全保护，主要体现在数据的备份保护上，MySQL本身提供的数据备份机制并不多，主要方式有冷备份、逻辑备份等。
冷备份是把数据库停下来，然后使用拷贝、打包或者压缩命令对数据目录进行备份。
逻辑备份是对数据库中多个库、单表或多表进行数据导出备份，也就是采用mysqldump、mydumper等命令处理。
另外，还有一些第三方备份工具，包括：Xtrabackup等。这些工具实现了对MySQL数据的物理备份。
但在实际应用中，这些备份方式和工具都无法满足企业对 MySQL 数据库备份的要求。
冷备份的停机处理，这在生产环境中是不可能的；逻辑备份是温备份，备份时锁表，不允许写操作，影响到了业务的连续性；而第三方工具目前还没有形成企业级的应用体系。
MySQL的数据备份保护的不完善。
一方面原因是由于之前 MySQL 数据库在市场上应用不多，对企业级备份需求疲软；
另一个重要原因是备份的技术壁垒，MySQL没有提供的完善的数据备份接口，如果要想达到企业要求，就需要对MySQL的数据库结构、文件结构、日志结构进行深度分析；
还有一个原因就是很多用户误将MySQL Replication（主从复制）当作了数据灾备保护，这也拖延了对MySQL备份保护的研究。
目前市场上对MySQL备份支持比较全面的备份产品并不多，可以说是凤毛麟角。
鼎甲科技的众多备份容灾产品，都对MySQL提供了数据保护。
包括鼎甲迪备（DBackup）、鼎甲多副本管理（InfoSemper）等。
鼎甲产品创建之初，在对数据库的支持规划上，将MySQL作为一个主流数据库支持项来投入研发，逐步完成了对MySQL的逻辑备份、物理备份（完全备份、增量备份、日志备份）、连续日志备份、合成备份、集成备份等。后期将会从浅到深一一解析，敬请期待！
DBackup产品创建之初，在数据库的支持规划上，MySQL是作为一个主流数据库支持项来投入研发。
那时还很少有企业会把MySQL作为业务数据库，鼎甲未雨绸缪。
逐步完成了对MySQL的逻辑备份、物理备份（完全备份、增量备份、日志备份）、连续日志备份、合成备份、集成备份等。
目前在MySQL数据库的备份支持上硕果累累，且在数据恢复上，可以实现RPO趋向于零，RTO进入了分钟级别。
逻辑备份是最为简单的备份方式，是DBackup最先支持的备份模式。
支持对数据库中表数据、代码的在线备份，用户可以选择整数据库表，或者一个或多个表来制定备份作业。在恢复时同样可以选择整数据库表，或者细粒度到单表进行数据恢复。
逻辑备份主要是调用了MySQL数据库提供的 mysqldump来实现库表数据的备份，并通过DBackup的前端备份服务，实现对数据的去重、压缩等处理，同时在数据传输上提供了限速设置。
逻辑备份的优点：支持对单表备份，可以全量导出表结构，并且对于不同存储引擎的表，都可以采用同样的方法产生备份数据。
因此，当需要把MySQL数据库中数据迁移到不同操作系统平台的同版本数据库中时，可以通过逻辑备份的方式来实现。在逻辑还原中，DBackup不仅支持本机恢复，也支持异机恢复，并且可以自定义是覆盖原数据库和创建新数据库。
逻辑备份的缺点：当MySQL数据量达到10G以上时，执行逻辑备份的“慢”是众所周知，且在备份处理期间，为了保证数据一致性，在备份非innodb表是会调用FTWRL（flushtables with read lock），直至备份完非innodb表后才可以unlock，因此这段时间将会影响到业务数据的写入。
为此，在实现MySQL的逻辑备份后，鼎甲科技即刻投入对MySQL数据库物理备份的研究和实现，通过对数据库文件的备份来提高备份效率和解决锁表问题。
没有最好，只有更好，鼎甲科技对MySQL的数据保护和价值提升上，一直在探索的路上。
在实现MySQL的逻辑备份后，鼎甲即刻投入对MySQL数据库物理备份的研究和实现，通过对数据库文件的备份来提高备份效率和解决锁表问题。
物理备份包括了完全备份、增量备份、日志备份。
主要是通过定制作业策略来备份MySQL的数据文件和日志文件，由于是基于数据文件的复制，所以物理备份比逻辑备份的速度快很多，而且采用的是热备份，在备份过程中也减少影响业务系统对数据库的使用。
DBackup在进行物理备份时，支持自适应MyISAM、InnoDB等多种存储引擎，根据不同的引擎来提取对应的文件进行备份。
在MyISAM存储引擎中，每张数据表都有3个文件，分别为表结构定义文件（frm）,表索引文件（MYI）,表数据文件（MYD）。
对于InnoDB存储引擎，增加了事务处理、回滚、崩溃修复能力和多版本并发控制的事务安全，数据文件更为复杂，每个InnoDB都会存在表结构定义文件（frm），而表索引和表数据存放在表空间文件【共享表空间文件（ibdata1），独享表空间（ibd）】中，另外还有相关的日志文件（binary log、redo log、undo log、errorlog等）。
在MySQL的物理备份中包括两部分的备份数据：对数据文件的完全备份和增量备份，对二进制日志文件的复制。
这两部分备份数据的备份处理流程不一样，需要配置在不同的备份任务中完成。
数据文件备份
DBackup同时支持对InnoDB和MyISAM引擎的数据文件和表数据进行备份，对InnoDB引擎中的数据文件，采用文件复制方式一页一页地复制InnoDB的数据，而且不锁定表，在文件复制的过程中，需要时刻监控着redo log的变化，一旦log发生变化，就即刻同步添加到事务日志文件中，直至复制完所有数据文件，才停止对redo log的监控和同步。
完成对ibd文件的备份后，将开始对非InnoDB表数据进行备份，包括MyISAM表和InnoDB表结构等信息，需要采用flush tables with lock来获得一个读锁，保障复制数据的一致性位点，复制完成后将进行解锁。
DBackup对数据文件的备份处理，通过同步事务日志信息，并整合到备份集中，在进行数据恢复时将保障数据文件和日志文件的一致性。
而对备份中的加锁处理，也进行了优化，实现定向备份锁技术，只有在备份非InnoDB表数据的时候才启动加锁处理，这有效地缩短了备份中的锁表时间，大大降低了因为数据库备份对业务服务的中断影响。
日志备份
日志备份是对二进制日志（binary log）文件的定制备份，二进制日志文件用来记录所有用户对数据库操作，即记录用户对数据库操作的sql语句。
binary log的文件有两种类型：index文件有.index的后缀；log文件用.NNNNNN后缀命名，如mysql-bin.000001等。
对二进制日志文件的备份，首先需要启动开启 MySQL 的二进制日志记录，常规的启动方式是需要在MySQL的服务器上，通过后台指令输入来进行配置启动。
DBackup为了简化配置流程，提升用户使用感知，把二进制日志的启动设置，整合到前台的配置页面中，用户只需做简单配置后即可启动。
物理备份的实现，虽然提升了MySQL的备份效率，且降低了备份过程中对业务访问数据的影响。
但由于备份是定时策略，无法做到密集型的备份，也就是在灾难恢复时，会丢失上次备份到故障点发生之间的数据。
为了提升数据恢复的RPO，鼎甲开始MySQL连续日志实时保护的研究和实现。
