我想在高负载下断电后testingRDBM的灾难恢复。
我的想法是将数据目录挂载到新的挂载点下，然后在加载过程中执行umount -f并调查文件的结果/状态。
我的期望是，对于非持久configuration，数据应该是不一致的，否则就是一致的。
有没有人认为这是好主意，也许还有其他相关的提示（例如哪个文件系统更好使用，或者我的期望是不相关的，那么为什么）？
据推测你实际上是去除了权力。 umount -f几乎不足以模拟许多故障。
在Linux上，umount（2）解释强制只支持networking文件系统。
MNT_FORCE (since Linux 2.1.116) Ask the filesystem to abort pending requests before attempting the unmount. This may allow the unmount to complete without waiting for an inaccessible server, but could cause data loss. If, after aborting requests, some processes still have active references to the filesystem, the unmount will still fail. As at Linux 4.12, MNT_FORCE is supported only on the following filesystems: 9p (since Linux 2.6.16), ceph (since Linux 2.6.34), cifs (since Linux 2.6.12), fuse (since Linux 2.6.16), lustre (since Linux 3.11), and NFS (since Linux 2.1.116).
以下是关于如何对数据库系统做非常讨厌的事情的更多想法：
物理拔掉主机的所有电源。 任何进程和共享内存将非常不正常地消失。
通过精简configuration过度使用存储，并将其运行至100％。 即使存储在这种情况下做了一些理智的事情，如果数据库的卷只在写入过程中被读取，那么DBMS可能会不高兴。
拔下到SAN的所有path，以模拟不“非破坏性”的存储维护。
find一个写入并发送SIGKILL信号或等效的进程。
崩溃的操作系统。 例如，在Linux上echo 'c' > /proc/sysrq-trigger
testing之后剩余的数据的状态取决于存储和DBMS。 要么他们可以有一个日记，他们可以重播，或者也许他们没有。 您可能想要在文件系统上执行fsck或等效function。 如果数据库可以恢复到一致的时间点，从日志或其他什么，你可能想这样做。 如果您拥有DBMS的完整性检查器，请将其用作完整性检查。
希望你已经做好了备份的恢复testing以防万一。 不要以为某些事情会导致事故的恢复，就是在所有情况下都能正常工作。