《MYSQL性能调优与架构设计》第五章--之--备份策略的设计思路

     针对不同的用途，所需要的备份类型是不一样的，备份策略也各有不同。

针对第五章开头部分所描述的在线应用数据丢失问题，备份就必须快速恢复，而且最好是只需要增量回复就能找回所需数据。对于这类需求，最好是有在线的，而且部分延迟恢复的备用数据库。因为这样可以再最短时间内找回所需要的数据。甚至在某些硬件设备出现故障的时候，将备用库直接开放，对外提供服务都可以。当然，在资源缺乏的情况下，可能难以找到足够的备用硬件设备来承担这个备份责任，也可以通过物理备份来解决，毕竟物理备份的恢复速度要比逻辑备份快很多。

    根据作者提供的经验，针对不同需求，有如下几个思路来设计合理的备份策略：

（1）对于较为核心的在线应用系统，必须有在线备用主机通过MYSQL的复制进行相应的备份，复制线程可以一直开启，恢复线程可以每天恢复一次，尽量让备机的数据延后主机的时间在一定时间段之内。这个延后时间多长适合主要根据实际需求决定，一般来说延后一天是一个比较常规的做法。

（2）对于重要级别稍微低一些的应用，恢复时间要求不是太高的话，为了节约硬件成本，不必使用在线的备份主机来单独运行备用MySQL，可以通过一定的时间周期进行一次物理全备份，同时每小时（或者其他合适的时间段）都将产生的二进制日志进行备份。这样虽然没有第一种备份方法恢复快，但是数据的丢失会比较少。恢复所需要的时间由全备周期长短决定。

（3）对于恢复基本没有太多时间要求，但是不希望太多数据丢失的应用场景，则可以在一定时间周期内进行一次逻辑全备份，同时也备份响应的二进制日志。使用逻辑备份而不使用物理备份的原因是因为逻辑备份实现简单，可以完全再现联机完成，备份过程不会影响应用提供服务。

（4）对于一些大件临时数据库的备份应用场景，仅仅需要通过一个逻辑全备份即可满足需求，都不需要用二进制日志来进行恢复，因为这样的需求对数据并没有太苛刻的要求。

      上面四种备份策略都还比较粗糙，甚至不能算是一个备份策略，目的只是提供一些思路。

总的来说，MySQL的备份与恢复都不太复杂，方法也比较单一，但备份功能方面还不是太完善，没有一个非常易用的增量备份工具。姑且不说逻辑备份，对于物理备份也还不够完善。缺少一耳光较好的开源在线热物理备份软件，一直是一个MySQL一个比较大的遗憾，也是所有MySQL使用者比较郁闷的事情。

不过，在实际应用场景中，大多有一台或多台Slave机器来作为热备。在需要的时候通过Slave来进行备份也不是太难，通过暂时停止Slave上面的SQL线程，即可让Slave机器停止所有数据写入操作，然后就可以在线进行备份操作了。所以即使买不起商业软件或者不太想买也没有关系。