1.在线备份2.离线备份2.1.关闭MySQL做备份是最简单、最安全的2.2.所有获取一致性副本的方法中最好的2.3.损坏或不一致的风险最小2.4.根本不用关心InnoDB缓冲池中的脏页或其他缓存2.5.不需要担心数据在尝试备份的过程中被修改2.5.1.服务器不对应用提供访问3.备份时间3.1.将备份复制到目的地需要多久4.备份负载4.1.在将备份复制到目的地时对服务器性能的影响有多大4.2.在备份服务器上压缩而不是在MySQL服务器上4.3.Percona XtraBackup和MySQL Enterprise Backup这样的工具都有限流选项，可在使用p v时加–rate-limit选项来限制备份脚本的吞吐量5.牺牲其一以增强另外一个6.恢复时间6.1.把备份镜像从存储位置复制到MySQL服务器、重放二进制日志等，需要多久7.逻辑备份7.1.导出7.2.以一种MySQL能够解析的格式来包含数据7.2.1.SQL语句7.2.2.以某个符号分隔的文本7.3.优点7.3.1.逻辑备份备份的文件是可以用编辑器或像grep和sed之类的命令查看和操作的普通文件7.3.2.恢复非常简单7.3.3.可以通过网络来备份和恢复，也就是说，可以在与MySQL主机不同的另外一台机器上操作7.3.4.可以在类似云数据库这样不能访问底层文件系统的系统中使用7.3.5.灵活7.3.6.与存储引擎无关7.3.6.1.消除了底层数据存储引擎的差异7.3.7.有助于避免数据损坏7.3.7.1.如果MySQL在内存中的数据还没有损坏，当不能得到一个正常的裸文件备份时，或许可以得到一个可以信赖的逻辑备份7.4.缺点7.4.1.必须由数据库服务器完成生成逻辑备份的工作，因此要占用更多的CPU周期7.4.1.1.某些场景下比数据库文件本身更大7.4.2.无法保证导出后再还原出来的一定是同样的数据7.4.2.1.浮点表示的问题、软件Bug等都会导致问题7.4.3.从逻辑备份中还原需要MySQL加载和解释语句，将它们转化为存储格式，并重建索引，所有这一切会很慢7.4.3.1.MySQL中导出数据和通过SQL语句将其加载回去的庞大开销7.4.3.2.如果使用逻辑备份，测试恢复需要的时间将非常重要7.4.3.3.逻辑备份最可怕的地方就是不确定的还原时间8.裸文件备份8.1.原始文件是指存放于硬盘上的文件8.2.直接复制原始文件8.3.优点8.3.1.基于文件的物理备份，它只需将需要的文件复制到其他地方即可完成备份，不需要其他额外的工作来生成原始文件8.3.2.非常容易跨平台、操作系统和MySQL版本工作8.3.3.从裸文件备份中恢复会更快8.3.3.1.MySQL服务器不需要执行任何SQL语句或构建索引8.3.3.2.如果有很大的InnoDB表，无法完全缓存到内存中，则裸文件备份的恢复要快得多8.3.3.2.1.至少要快一个数量级8.4.缺点8.4.1.InnoDB的原始文件通常比相应的逻辑备份要大得多8.4.1.1.表空间往往包含很多未使用的空间8.4.2.不总是可以跨平台、操作系统及MySQL版本的8.4.2.1.文件名大小写敏感和浮点格式是可能会遇到麻烦的8.4.2.2.对于需要长期保留或者是用于满足法律合规要求的备份，尽量不要完全依赖裸文件备份8.4.2.3.每隔一段时间需要做一次逻辑备份8.4.3.除非经过测试，不要假定备份（特别是裸文件备份）是正常的8.4.3.1.CHECK TABLES8.4.3.2.不建议仅对文件运行innochecksum9.混合使用9.1.使用裸文件备份9.2.用得到的数据启动MySQL服务器实例并运行mysqlcheck9.3.周期性地使用mysqldump执行逻辑备份9.4.优点是不会使生产服务器在导出时有过度负担9.5.如果能够方便地利用文件系统的快照，也可以生成一个快照，将该快照复制到另外一台服务器上并释放，然后测试原始文件，再执行逻辑备份10.备份什么10.1.恢复的需求决定需要备份什么10.2.最简单的策略是只备份数据和表定义，但这是一个最低的要求10.3.非显著数据10.3.1.二进制日志和InnoDB事务日志10.3.2.在理想情况下，应该把整个数据目录和MySQL一起备份起来10.4.代码10.4.1.现代的MySQL服务器可以存储许多代码，例如，触发器和存储过程10.4.2.实际是存放在mysql数据库中的10.5.服务器配置10.5.1.对于服务器配置来说，备份中对生产服务器至关重要的任何外部配置，都十分重要10.6.选定的操作系统文件10.6.1.在UNIX服务器上，这可能包括cron任务、用户和组的配置、管理脚本，以及sudo规则11.部分备份11.1.一般不包含完整的数据集11.1.1.因为某些数据没有改变11.1.2.对减少服务器开销、备份时间及备份空间而言都很适合11.2.Percona XtraBackup和MySQL Enterprise Backup，仍然会扫描服务器上的所有数据块，因而并不会节约太多的开销11.2.1.确实会减少一定量的备份时间和大量用于压缩的CPU时间11.2.2.会减少磁盘空间的使用11.3.差异备份11.3.1.自上次全备份后所有改变的部分而做的备份11.4.增量备份11.4.1.对自任意类型的上次备份后的所有修改做的备份11.4.2.缺点11.4.2.1.会增加恢复的复杂性11.4.2.2.额外的风险11.4.2.3.更长的恢复时间12.建议12.1.使用Percona XtraBackup和MySQL Enterprise Backup中的增量备份特性12.2.备份二进制日志12.2.1.在每次备份后使用FLUSH LOGS来开始记录一个新的二进制日志，这样就只需要备份新的二进制日志12.3.如果有一些“引用”表，例如，包含不同语种、各个月的名称列表，或者州或区域的简写等，可以考虑将它们单独放在一个数据库中，这样就不需要每次都备份这些表12.3.1.一个更好的选择可能是把这些数据放到程序代码中，而不是保存在数据库中12.4.某些数据根本不需要备份12.4.1.相对于从全备份中可能获得的快速恢复时间，避免备份可以节约更多时间开销12.4.2.临时数据也不用备份12.5.备份所有的数据，然后发送到一个有去重特性的地方12.6.如果可以做全备份，考虑到简便性，建议尽量做全备份12.6.1.建议至少一周一次13.复制13.1.从副本中备份最大的好处是可以不干扰源库，避免在源库上增加额外的负载13.1.1.这是一个建立副本服务器的好理由，即使不需要用它做负载均衡或提供高可用性13.2.用GTID是非常明智的13.2.1.避免了必须保存有关复制过程的所有信息13.3.故意将一个副本延迟复制一段时间对于某些灾难场景非常有用13.4.源库与副本数据不匹配是很常见的，并且MySQL没有方法检测这个问题13.4.1.唯一方法是使用Percona Toolkit中的pt-table-checksum之类的工具13.4.2.防止这种情况的最好方法是使用super_read_only来确保只有复制可以写入副本13.5.复制不是备份