标签：nod 回滚 sam 服务器 较差 为什么 结构 客户端 业务
前几天又看到新闻，某厂用户数据又丢了，据说是实习生的锅。数据安全性，是DBA最重要的职责，没有之一，今天系统性的说一下MySQL的备份。
画外音：估计不是DBA和OP对这个问题也不太关注，权当了解知识吧。
MySQL的备份分两大类：
（1）物理备份(Physical Backup)
（2）逻辑备份(Logical Backup)
以拷贝文件的方式备份数据库内容，典型的，可以备份数据库的：
备份数据库的逻辑结构，典型的玩法是，把数据库备份为一系列SQL语句：
一般来说，物理备份：
（1）速度比较快，它只是单纯的文件拷贝备份；
（2）大小比较小，文件往往是经过压缩的；
（3）往往要求数据库实例处于离线状态(offline)，不允许数据库文件变更，以保证数据一致性；
画外音：即使企业版支持所谓的在线物理备份，也会加很大的锁，备份期间数据库可用性较差。
（4）备份的可移植性往往比较差，数据恢复时，必须是几乎相同的硬件体系结构；
画外音：windows下物理备份，不能直接应用恢复到Linux下的MySQL。
说到在线备份一致性，不同存储引擎，对于锁颗粒度要求也是不一样的：
（1）InnoDB引擎，允许一个表一个文件，在线物理备份时可以一个一个表（文件）加锁备份；
（2）MyISAM引擎，一个表对应一组文件，在线物理备份时必须锁一组文件；
（3）MEMORY引擎，额，内容不存在磁盘上；
画外音：强烈建议，还是别搞什么在线物理备份了。
既然是备份文件/目录，常见的文件工具就能搞定，例如：cp，scp，tar，rsync等。
画外音：还有一些MySQL工具，要么是企业版的，要么不支持所有存储引擎（例如：只支持MyISAM引擎的mysqlhotcopy）。
一般来说，逻辑备份：
（1）通过访问MySQL服务，来获得数据库的结构信息与数据内容；
（2）速度比较慢，除了要将数据库信息转化为逻辑格式(logical format)，很可能还要传回客户端备份程序；
（3）备份粒度更细，全库，单库，全表，单表都可以备份，所有存储引擎都能备份（包含MEMORY引擎）；
（4）往往不能备份数据库日志，数据库配置文件；
（5）因为备份的是逻辑格式，可移植性非常好；
画外音：windows下备份，也能快速应用到Linux。
（6）备份时，数据库实例必须处于在线状态(online)；
画外音：在线备份和离线备份，更多被称为“热备(hot)”和“冷备(cold)”。
常见的玩法是：
（1）mysqldump
（2）select … into outfile
画外音：再次强调，MEMORY引擎也可以逻辑备份。
本地备份，是指备份动作实施在MySQL服务器所在的主机上。
远程备份，是指备份动作实施在另一台主机上。
画外音：本地备份往往存在“备份与数据库服务器竞争本地资源”的问题，远程备份往往有较大的网络开销。
mysqldump：即可以在本地，又可以在远程实施。
select … into outfile：同上。
mysqlhotcopy：只能本地实施。
其他物理备份：基本上都是本地实施，因为MySQL服务器要处理离线状态。
MySQL自身不支持。
全量备份，是指备份截止到某一个时间点的全部数据。全量备份方法很多，上文所说的各种方案，全部是全量备份方案。
增量备份，是指从某一个时间点开始，利用binlog记录数据变化的方法，来实施的备份。
作为DBA和OP，数据安全性是第一要务，全量备份和增量备份都是必须的！
几个要点：
（1）全量备份+增量备份+定期演练；
（2）1小时延时从库；
（3）双份1小时延时从库；
这不是本文的重点，细节不展开，具体见《db如何快速回滚+恢复，DBA的神技能》。
画外音：或许，这篇文章大家更感兴趣。
看完本文，可能大部分人觉得没什么用（物理备份，逻辑备份，在线备份，离线备份，热备，冷备，本地备份，远程备份，快照备份，全量备份，增量备份，人都晕了）。
毕竟，更多人使用MySQL而无需运维MySQL，但系统性了解下MySQL备份知识，没有坏处。
画外音：本文基于MySQL5.6版本。
架构师之路-分享技术思路
《并发扣款，如何保证数据的一致性？》
《同样是高并发，不同业务为什么难度不同？》
《每秒100W请求，秒杀业务架构如何优化？》HOT
《58到家MySQL军规升级版》
删过数据库的同学，扣个1。
标签：nod 回滚 sam 服务器 较差 为什么 结构 客户端 业务
原文地址：https://blog.51cto.com/jyjstack/2548520
