数据库备份和恢复是否必要

数据库可能发生各种各样的故障

1)事务内部故障
2)系统范围内的故障
3)介质故障
4)计算机病毒

这些都可能会对数据库产生影响，要么是数据库本身被破坏，要么是数据库没有被破坏，但是数据库有可能不正确，这是因为事务的运行被终止所造成的。

 

方法1：数据备份
备份(转储)是指database administrator 定期地将整个书库复制到磁带或者另一个磁盘上保存起来的过程
备份分为静态备份(冷备份)和动态备份(热备份)。静态备份是指备份期间不允许(或不存在)对数据库进行任何存取、修改活动。静态备份简单，但备份必须等待用户事务结束才能进行，同样，新的事务必须等待备份结束才能执行。显然，这会降低数据库的可用性；动态备份是指备份期间允许对数据库进行存取或修改，即备份和用户事务可以并发执行。动态备份可客服静态备份的缺点，但是，备份结束时候原副本上的数据并不能保证正确有效。
备份还分海量备份和增量备份。海量备份是指每次备份全部数据库。增量备份则指每次只备份山慈备份以后更新过的数据。如果数据库很大，事务处理又十分频繁，则增量备份方式很有效。
方法2：日志文件
事务日志是针对数据库改变所做的记录，他可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。根据这些记录可以将数据文件恢复成事务前的状态。从事务运动开始，事务日志就处于记录状态，事务执行过程中对数据库的任何操作都记录在内，直到用户提交或回滚后才结束记录。

为了安全，应该首先把修改记录写到日志文件上，然后再写数据库的修改。这就是先写日志文件的原则

 

有了备份就可以进行数据恢复了

如果是日志文件的记录的话，对出错数据进行修改，然后再进行后面数据进行重新导入。这样就能恢复数据了
 

但是这个仅仅适用于单线程，多线程会特别麻烦的。

为什么这么说，多线程产生的SQL语句是顺序假设是a、b、c，但是由于多线程的原因，到达数据库的顺序不一定是a、b、c，传输时间不一定相同，有可能是 C、A、B。所以要做多线程的会比较麻烦，我们无法捕捉到达数据库的顺序，只能捕捉从程序中发生的顺序的。这样肯定会造成错误。

那怎么办呢？

数据库本身有个bin log就是用来记录发生的事情，可以退回到当前的位置。