备份与恢复
定义恢复需求
如果一切正常，那么永远也不需要考虑恢复。但是，一旦需要恢复，只有世界上最好的备份系统是没用的，还需要一个强大的恢复系统。
不幸的是，让备份系统平滑工作比构造良好的恢复过程和工具更容易。原因如下:
- 1.备份在先。只有已经做了备份才可能恢复，因此在构建系统时，注意力自然会集中在备份上
- 2.备份由脚本和任务自动完成。经常不经意地，我们会花些时间调优备份过程。花5分钟来对备份过程做小地调整看起来并不重要，但是你是否天天同样地重视恢复呢？
- 3.备份时日常任务，但恢复常常发生在危急情形下
- 4.因为安全的需要，如果正在做异地备份，可能需要对备份数据进行加密，或采取其他措施来进行保护，安全性往往只关注数据被盗用的后果，但是有没有人想过，如果没有人能对用来恢复数据的加密卷解锁，或需要从一个整块的加密文件中抽取单个文件时，损害又是多大？
- 5.只有一个人来规划、设计和实施备份。当灾难袭来时，那个人可能不在。因此需要培养几个人并有计划地互为备份，这样就不会要求一个不合格的人来恢复数据
这里有一个看到的真实例子:一个客户报告说当mysqldump加上-d选项后，备份变得像闪电一般快，他想知道为什么没有一个人提出该选项可以如此快地加速备份过程。如果这个客户已经尝试还原这些备份，就不难发现其原因:使用-d选项将不会备份数据!这个客户关注备份，却没有关注恢复，因此完全没有意识到这个问题。规划备份和恢复策略时，有两个重要的需求可以帮助思考:恢复点目标(PRO)和恢复时间目标(RTO)。它们定义了可以容忍丢失多少数据，以及需要等待多久将数据恢复。在定义RPO和RTO时，先尝试回答下面几类问题:
- 1.在不导致严重后果的情况下，可以容忍丢失多少数据?需要故障恢复，还是可以接受自上次日常备份后所有的工作全部丢失？是否有法律法规的要求？
- 2.恢复需要在多长时间内完成？哪种类型的宕机是可以接受的？哪种影响(例如，部分服务不可用)是应用和用户可以接受的？当哪些场景发生时，又该如何持续服务?
- 3.需要恢复什么？常见的需求是护肤整个服务器，单个数据库，单个表，或仅仅是特定的事务或语句
建议将上面问题的答案明确地用文档记录下来，同时还应该明确备份策略，以及备份过程
备份误区1:“复制就是备份”
这是我们经常碰到地一个误区。复制不是备份，当然使用RAID阵列也不是备份。为什么这么说？可以考虑以下，如果意外地在生产库上执行了DROP DATABASE，它们是否可以帮你恢复所有的数据？RAID和复制连这个简单的测试都没法通过。它们不是备份，也不是备份的替代品。只有备份才能满足备份的要求
设计MySQL备份方案
备份MySQL比看起来难。最基本的，备份仅仅是数据的一个副本，但是受限于应用程序的要求、MySQL的存储引擎架构，以及系统配置等因素，会让复制一份数据都变得很困难。在深入所有选项细节之前，先来看以下建议:
- 1.在生产实践中，对于大数据库来说，物理备份是必需的:逻辑备份太慢并受到资源限制，从逻辑备份中恢复需要很长实践。基于快照的备份，例如Percona XtraBackup和MySQL Enterprise Backup是最好的选择。对于较小的数据库，逻辑备份可以很好地胜任
- 2.保留多个备份集
- 3.定期从逻辑备份(或者物理备份)中抽取数据进行恢复测试
- 4.保存二进制日志以用于故障时点的恢复,expire_logs_days参数应该设置得足够长。至少可以从最近两次物理备份中做基于时间点得恢复，这样就可以在保持主库运行且不应用任何二进制日志得情况下创建一个备库。备份二进制日志与过期设置无关，二进制日志备份需要保存足够长得实践，宜宾啊能从最近得逻辑备份进行恢复
- 5.完全不借助备份工具本身来监控备份和备份得过程。需要另外验证备份是否正常
- 6.通过演练整个恢复过程来测试备份和恢复。测算恢复所需要的资源(CPU、磁盘空间、实际实践，以及网络带宽等)
- 7.对安全性要仔细考虑。如果有人能接触生产服务器，它是否也能访问备份服务器？反过来呢。
弄清楚PRO(恢复点目标)和RTO(恢复时间目标)可以指导备份策略。是需要基于故障时间点的恢复能力，还是从昨晚的备份中恢复但会丢失此后的所有数据就足够了？如果需要基于故障时间点的恢复，可能要建立日常备份并保证所需要的二进制日志是有效的，这样才能从备份中还原，并通过重放二进制日志来恢复到想要的时间点。
一般来说，能承受的数据丢失越多，备份越简单。如果有非常苛刻的需求，要确保能恢复所有数据，备份就很困难。基于故障时间点的恢复也有积累。一个"宽松"的故障时间点恢复需求意味着需要重建数据，直到"足够接近"问题发生的时刻。一个"硬性"的需求意味着不能容忍任何一个已提交的事务，即使某些可怕的事情发生(例如服务器着火了)。这需要特别的技术，例如将二进制日志保存在一个独立的SAN卷或使用DRBD磁盘复制
在线备份还是离线备份
如果可能，关闭MySQL做备份是最简单最安全的，也是所有获取一致性副本的方法中最好的。而且损坏或不一致的风险最小。如果关闭了MySQL，就根本不用关心InnoDB缓冲池中的脏页或其他缓存。也不需要担心数据在尝试备份的过程被修改，并且因为服务器不对应用提供访问，所以可以更快地完成备份。
尽管如此，让服务器停机的代价可能比看起来要更昂贵。即使能最小化停机时间，在高负载和高数据量下关闭和重启MySQL也可能要花很长一段时间，尽管有一些能使这个影响最小化的技术，但并不能将其减少为零。因此，必需要设计不需要生产服务器停机的备份。即便如此，由于一致性的需要，对服务器进行在线备份仍然会有明显的服务中断。
在众多的备份方法中，一个最大问题就是它们会使用FLUSH TABLES WITH READ LOCK操作，这会导致MySQL关闭并锁住所有的表，将MyISAM的数据文件刷新到磁盘上(但InnoDB不是这样的！)，并且刷新查询缓存。该操作需要非常常的时间来完成。具体需要多长时间是不可预估的；如果全局读锁要等待一个长时间运行的语句完成，或有许多表，那么时间会更长。除非锁被释放，否则就不能在服务器上更改任何数据，一切都会被阻塞和积压(是的，即使SELECT查询也会被阻塞，因为如果有一个查询需要修改某些数据，只要它开始等待表上的写锁，所有尝试获取读锁的查询也必需等待)。FLUSH TABLES WITH READ LOCK不像关闭服务器的代价那么高，因为大部分缓存仍然在内存中，并且服务器一直是"预热"的，但是它也有非常大的破坏性。如果有人说这样做很快，可能是准备向你推销某种从来没有在真正的线上服务器上运行过的东西。避免使用FLUSH TABLES WITH READ LOCK的最好的方法是只使用InnoDB表。在权限和其他系统信息表中使用MyISAM表是不可避免地，但是如果数据改变量很少(正常情况下)，你可以只刷新和锁住这些表，这不会有什么问题。
在规划备份时，有一些与性能相关地因素需要考虑.
- 1.锁时间
需要持有锁多长时间，例如在备份期间持有地全局FLUSH TABLES WITH READ LOCK? - 2.备份时间
复制备份到目的地需要多久? - 3.备份负载
在复制备份到目的地时对服务器性能的影响有多少? - 4.恢复时间
把备份镜像从存储位置复制到MySQL服务器，重放二进制日志等，需要多久?
最大的权衡是备份时间与备份负载。可以牺牲其一以增强另外一个。例如可以提高备份的优先级，代价是降低服务器性能。同样，也可以利用负载的特性来设计备份。例如，如果服务器在完上的8小时内仅仅有50%的负载，那么可以尝试规划备份，使得服务器的负载低于50%且仍能在8小时内完成。可以采用许多方法来完成这个目标，例如，可以用ioice和nice来提高复制或压缩操作的优先级，使用不同的压缩等级，或在备份服务器上压缩而不是在MySQL服务器上。甚至可以使用lzo或pigz以获取更快的压缩。也可以使用0_DIRECT或fadvise()在复制操作时绕开操作系统的缓存，以避免污染服务器的缓存。像Percona XtraBackup和MySQL Enterprise Backup这样的工具都有下六选项，可以使用pv时加上–rate-limit选项来限制备份脚本的吞吐量
逻辑备份还是物理备份
有两种主要的方法来备份MySQL数据:逻辑备份(也叫"导出")和直接复制原始文件的物理备份。逻辑备份将数据包含在一种MySQL能够解析的格式中，要么时SQL，要么时以某个符号分割的文本。(由mysqldump生成的逻辑备份并不一定是文本文件。SQL导出会包含许多不同的字符集，同样也会包含二进制数据，这些数据并不是有效的字符。对于许多编辑器来说，文件行也可能会太长。但是，大多数这样的文件还是可以被编辑器打开和读取，特别是mysqldump使用了–hex-blob选项时)。原始文件是指存在硬盘上的文件。任何一种备份都有其优点和缺点.
逻辑备份
(上图是cat /var/lib/mysql-bin.000001操作所示)
逻辑备份有如下优点:
- 1.逻辑备份是可以用编辑器或像grep 和sed之类的命令查看和操作的普通文件。当需要恢复数据或只想查看数据但不恢复时，这都非常有帮助
- 2.恢复非常简单。可以通过管道把它们输入到mysql，或者使用mysqlimport。
- 3.可以通过网络来备份和恢复——就是说，可以在与MySQL主机不同的另外一台及其上操作
- 4.可以在类似Amazon RDS这样不能访问底层文件系统的系统中使用
- 5.非常灵活，因为mysqldump——大部分人喜欢的工具——可以接受许多选项，例如可以用WHERE子句来限制需要备份哪些行。
- 6.与存储引擎无关。因为是从MySQL服务器中提取数据而生成，所以消除了底层数据存储和不同。因此，可以从InnoDB表中备份，然后只需极小的工作量就可以还原到MyISAM表中。而对于原始数据却不能这么做。
- 7.有助于避免数据损坏。如果磁盘驱动器有故障而要复制原始文件时，你将会得到一个错误并且/或生成一个部分或损坏的备份。如果MySQL在内存中的数据还没有损坏，当不能得到一个正常的原始文件复制时，有时可以得到一个可以信赖的逻辑备份
尽管如此，逻辑备份也有它的缺点:
- 1.必需由数据库服务器完成生成逻辑备份的工作，因此要使用更多的CPU周期
- 2.逻辑备份在某些场景下比数据库文件本身更大(以经验来看，逻辑备份往往比物理备份要小许多，但也并不总是如此)。ASCII形式的数据不总是和存储引擎存储数据一样高效。例如，一个整型需要4字节来存储，但是用ASCII写入时，可能需要12个字符。当然也可以压缩文件以得到一个更小的备份文件，但这样会使用更多的CPU资源。(如果索引比较多，逻辑备份一般要比物理备份小)
- 3.无法保证导出后再还原出来的一定是同样的数据。浮点表示的问题、软件Bug等都会导致问题，尽管非常少见
- 4.从逻辑备份中还原需要MySQL加载和解释语句，转化为存储格式，ing重建索引，所有这一切会很慢。
最大的缺点时从MySQL中导出数据和通过SQL语句将其加载回去的开销。如果使用逻辑备份，测试恢复需要的时间将非常重要。Percona Server中包含的mysqldump，在使用InnoDB表时能起到帮助作用，因为它会对输出格式化，以便在重新加载时利用InnoDB的快速建索引的优点。测试显示这样做可以减少2/3甚至更多的还原事件。索引越多，好处越明显
