数据库备份、还原与恢复

开篇一张图，内容全靠编。一本正经de胡说八道：数据库备份、还原与恢复基本概念

如果了解过其它数据库（如oracle）的备份，肯定见过类似这样的一句话：普通完全备份不可以做为增量备份的基备份；或者，执行增量备份时，系统会自动做一次0级的备份（如果没有0级备份）。那为什么其它数据库不可以使用普通全备作为增量备份的基备份，而DM数据库没有这样限制，可以使用完全备份做为增量备份的基备份，差异在哪，又或者DM模糊、弱化了哪些点呢？

回答这个问题前，先普及一下备份的概念。备份是......（请自行百度）。备份按不同的数据库、不同的维度，有N种不同的区分方法、N+1种不同的叫法。常见的：联机备份、脱机备份；热备、冷备、温备；物理备份、逻辑备份（物理逻辑备份）；又或者完全备份、增量备份（差异、累积增量备份）......。下面就按联机、脱机这个维度展开吧。

通常我们所说的数据库备份一般都是指联机备份（至于脱机备份爱怎么玩怎么玩，不讨论），也就是在不影响业务的情况下（这里指的是业务不停机，实际上仍可能影响CPU、网络、IO、内存等资源）完成数据库备份。那么，从备份开始（<=CKPT_LSN）,到备份结束（END_LSN）的这段时间里，业务是不中断的，数据库依然可读、可写，对应数据库的增、删、改肯定会记录重做日志（redo log）；而且，这期间必然有部分事务已经提交（日志已经落盘，但数据不一定落盘），有部分事务还没有提交（日志可能一部分已落盘；可能有部分还没有落盘，仍存在redo log buffer中）。那么，最终利用该完全备份做数据库恢复的时候，在BEGIN_LSN到END_LSN期间的事务(<=CKPT_LSN的日志已落盘、数据已落盘，因为CKPT)，在recover阶段，对于已经提交的事务，会redo；而所有还没有提交的事务，如果日志已经落盘，那么构造undo后，会做rollback处理；如果日志还没有落盘，备份时仍然存在redo log buffer中的，丢失了也就丢失了。

注：异常情况下，所有数据库都会丢失数据，关键在于丢失的是什么数据，是哪一部分数据；也许你可能会说：XX数据库不是说可以严格保证数据完整性、一致性，不会丢失数据吗？那可能是你没仔细看，XX数据库说的应该是不会丢失已提交的数据，对于未提交的数据，都是得不到保证的，也没有必要。

但关键问题就出在END_LSN这个时间点对应的这部分还没有提交的事务，在某个>END_LSN的时间点会最终commit或rollback。这部分未提交的事务，对于>END_LSN时间点再次发起的完全备份不会有任何影响（因为会重复本次完全备份的所有逻辑），但对想以此完全备份做为基备份的增量备份来说，就可能导致数据不一致，因为利用该完全备份做数据库还原、恢复的时候，这部分还未提交的事务，肯定会rollback（因为还没有commit），所以这个全量备份不能做为增量备份的基备份使用。

那为什么DM数据库可以使用这个完全备份做为增量备份的基备份呢？仔细看下图红色大框框部分，DM做增量备份的时候，实际上会将上一次全备CKPT_LSN至本次增量备份CKPT_LSN之间的所有产生数据变化的数据页全部拷备出来，作为备份集的一部分。同时，DM官方文档还有一个前置限制条件：（至于日志部分，原理同全量备份，不再赘述）

DM 要求执行增量备份时，<=基备份 END_LSN 的所有数据页已经写入磁盘。

那么，这些条件是不是就是上面花了很大篇幅说的在END_LSN时间点还没有提交的事务？现在，变化的数据页有了（恢复时会覆盖基备份内容），联机备份时的日志有了（这两部分构成增量备份集内容），加上作为基备份的完全备份的数据内容，就可以用作增量备份点做数据库恢复可用的备份集了。

至此，我所了解的关于数据库备份恢复的基本概念应该都聊到了（实际上更多的是关于Redo log 、LRU脏页刷新、CKPT等），但实际上仍然有很多细的地方没有写太清晰，比如：

日志已经落盘，对应的数据一定已经落盘了吗？（不一定）

数据已经落盘，对应的日志一定已经落盘了吗？（一定，WAL，日志先于数据落盘）

CKPT_LSN时间点的事务都提交了吗？或者再明确一点，<=CKPT_LSN的数据肯定已经落盘了，日志肯定也已经落盘了，但对应的事务一定全部已经都提交了吗？（不一定，淘汰脏页极端情况）

OVER，如果上面有什么不对的地方，请一定一定告诉我，谢谢。

OVER，如果上面有什么不对的地方，请一定一定告诉我，谢谢。

OVER，如果上面有什么不对的地方，请一定一定告诉我，谢谢。

重要的事情说三遍！！！重要的事情说三遍！！！重要的事情说三遍