作者马建智，目前任职拉勾网DBA，从2014年至今一直从事DBA行业，我的老部下，以前技术团队每周有固定的分享，曾分享过 “如何避免删库跑路”。
俗话说的好，常在河边走，难免不湿鞋。出过数据库事故的业界大佬有顺丰、腾讯云、炉石、携程等，所以DBA是个高危职业，轻易不出事，出事就是大事......造成公司xx万损失的那种。那么，不小心删了库，一定要跑路吗？业界前辈给的答案：
删库跑路的后果摆在眼前，所以为了避免重走业界前辈的路，得好好想下怎么避免删库跑路？答案就是：备份！
为什么要备份？
数据备份是容灾的基础，是为了防止出现操作失误或系统故障导致数据丢失，而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。内心戏：是为了避免数据丢了只能跑路。
备份的重要性是TOP1级别，DBA首要保障数据的安全，其次才是服务的稳定、响应的性能问题。不过备份只有在真正需要的时候才是英雄，目前大部分互联网公司用的基本是mysql数据库，所以今天就聊一聊mysql备份那些事。
1. MySQL文件备份类型
按照备份方式分冷备和热备
冷备：数据必须下线后备份，也就是停止MySQL实例，直接备份数据目录
热备：数据不离线，读写都能正常进行，在不停数据库实例、不影响业务的情况下备份。
按照备份类型分逻辑备份和物理备份
逻辑备份：可以理解为将数据转换为SQL语句导出到文本文件中，是基于语句的操作。采用SQL级别的备份机制，将数据表导成SQL脚本文件。逻辑备份速度比较慢，占用空间比较小，逻辑备份的恢复成本高
物理备份：物理备份就是备份数据文件，是基于文件的操作。形象点形容就是cp下数据文件，但真正备份的时候自然不是的cp这么简单，物理备份又分冷备份和热备份。物理备份恢复速度比较快，占用空间比较大。
2. MySQL文件备份工具
逻辑备份工具
mysqldump是官方自带的逻辑备份工具，可以进行实例级、库级、表级的数据与结构或单表结构备份，还能添加where筛选条件等。
例：mysqldump -uXXX -pXXX --databases abc --tables abc1 --where='id>10' > /tmp/backup.sql
备份的内容1：
备份的内容2：
从上述文件内容上看，mysqldump备份出来的文件，其实就可以看作一个可执行的SQL文件，只要把这个文件在数据库里执行一遍，就是在做数据恢复操作。
mysqldump有个缺点是，单线程执行备份，速度较慢。在生产环境使用中，做一些小库的备份或者表的备份比较灵活，但是无法应对大数据量的备份。因此生产环境里用的较多的是mydumper（备份）/myloader（恢复）。
mydumper（Facebook开源）最大的特点就是可以多线程执行备份和压缩，速度相对快很多，空间占用也较小（压缩率是10%-15%）。本质上mydumper备份原理与mysqldump类似，也是把数据转换成SQL语句的形式输出到文件中。不过文件展示形式有区别：mysqldump整体只有一个文件；mydumper则是每个表对应两个文件（一个是表结构文件，也就是create table语句，一个是表数据文件，也就是insert 语句）。
物理备份工具
Xtrabackup是Percona公司开发的开源备份工具，可以实现物理热备份，可全量备份也可以增量备份。
例：innobackupex --defaults-file=XXX--user=XXX --password=XXX --parallel=4 --slave-info /backup/
备份的内容
图中的文件夹 mysql、performance_schema、sys、test、test1，就是备份出来的一个个数据库文件所在的目录。ibdata1是共享表空间文件，backup-my.cnf是配置文件，其他是Xtrabackup工具生成的文件。
注意：不管是逻辑备份还是物理备份，都有锁表的操作，一般是在从库做备份，主库上操作要慎重！
3. MySQL文件恢复
利用逻辑备份恢复
逻辑备份的文件，是一条条的SQL，包含了建库、建表、插入等语句，所以恢复的时候，只要把这些SQL重新执行一遍即可。
mysqldump备份恢复命令：mysql -uXXX -pXXX < /tmp/backup.sql （俗称“灌数据”）
mysqldump恢复时间：串行恢复，按所有表的恢复时间总和计算
mydumper备份的文件，需要myloader工具进行恢复，命令与上面不同，但恢复原理类似。
mydumper恢复时间：多进程恢复，按最大的表恢复时长计算
利用物理备份恢复
物理备份的文件，是数据库的物理文件的备份，所以恢复的时候，是把这些目录“cp”回原目录。 “cp”之前，要确保数据一致性，所以要先进行崩溃恢复机制，在备份文件上先应用日志把数据恢复成一致性，再“cp”回去。应用日志的命令：innobackupex--defaults-file=XXX --apply-log /home/backup/<备份目录>
恢复命令： innobackupex --defaults-file=XXX --user=XXX --password=XXX--copy-back /home/backup/<备份目录>
极速恢复命令：--copy-back改成 --move-back （区别：copy-back是cp回原目录，move-back是move回原目录）
问：这算恢复结束吗？
答：看需求确定。以上两种恢复，是基于备份文件的恢复，数据只能恢复到备份的那一刻。如果恢复到这一刻数据可以满足，就算恢复完成了。还有一些需求场景，比如误操作恢复和精准恢复，就必须使用日志来恢复。
4. MySQL日志备份与恢复
阿基米德：给我一个支点，我可以翘起地球。
DBA：给我所有的binlog，我可以恢复一个整库到任意时间。
精准恢复方法总结：数据基础 + binlog日志，注意：binlog用官方语句只能解析实例级和db级，无法直接解析到表级。
binlog恢复的过程：
先按照某种条件（时间、POS点等）解析出符合条件的binlog转储到一个文件，例如recover.log，采用类似逻辑恢复的方式进行恢复：mysql -uXXX -pXXX < recover.log
误操作恢复（insert、delete、update）
恢复方式：
-
直接解析binlog，筛选出误操作的语句，反向编译成恢复语句，恢复到生产环境。
-
利用备份+binlog日志，在测试环境恢复出单表数据，再筛选出符合条件的记录，恢复到生产环境。
-
利用binlog2sql工具，反解析binlog日志的语句，直接生成回滚语句。比如delete语句反解析成insert语句。
5. MySQL架构备份
实际上，主从结构在某种意义上讲也算是一种备份，属于高可用保障。
这种是保障整体数据库的可用性，防止主库故障大面积影响业务。若要防止删库及时恢复，要设置“延迟复制库”，为了保证数据安全，比较完整的架构图如下（两地三中心）。
补充下数据库团的行为规范：
-
任何数据库的线上操作，必须走工单
-
禁止在主库上执行统计类的功能查询；
-
禁止有super权限的应用程序账号存在；
-
有大规模市场推广、运营活动必须提前通知DBA进行流量评估；
-
对单表的多次alter操作必须合并为一次操作；
-
不在MySQL数据库中存放业务逻辑；
-
重大项目的数据库方案选型和设计必须提前通知DBA参与；
-
数据必须有备份机制；
-
不在业务高峰期批量更新、查询数据库；
推荐阅读：
