☰

通过强制卸载模拟断电？

tag-icon • tag-icon filesystems disaster-recovery rdbms
通过强制卸载模拟断电？

我想测试高负载下断电后 RDBM 的灾难恢复。

我的想法是将数据目录挂载在新的挂载点下，然后umount -f在加载期间执行并调查文件的结果/状态。

我的期望是，在非持久配置下，数据应该不一致，否则应该一致。

是否有人认为这是个好主意并且可能还有其他相关的提示（例如哪个文件系统最好使用或者我的期望无关紧要，那么为什么）？

答案1

假设您实际上正在切断电源。 umount -f这还不够不礼貌，不足以模拟许多失败。

在 Linux 上，umount(2) 解释说强制仅支持网络文件系统。

   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).

这里还有一些关于如何对数据库系统进行非常恶劣的操作的想法：

  • 物理上拔掉主机的所有电源。所有进程和共享内存都会不雅地消失。

  • 使用精简配置过度使用存储，并将其运行到 100%。即使存储在这种情况下做了一些理智的事情，如果其卷在写入过程中变为只读，DBMS 可能会不高兴。

  • 拔下到 SAN 的所有路径，以模拟实际上不存在的“无中断”存储维护。

  • 找到执行写入的进程并向其发送 SIGKILL 信号或等效信号。

  • 使操作系统崩溃。例如，在 Linux 上echo 'c' > /proc/sysrq-trigger

测试后剩余数据的状态取决于存储和 DBMS。它们可能具有可以重放的日志，也可能没有。您可能希望对文件系统执行 fsck 或等效操作。如果数据库可以从日志或其他任何内容恢复到一致的时间点，您可能希望这样做。如果您有 DBMS 的完整性检查器，请将其用作健全性检查。

希望您已经对备份进行了恢复测试，以防万一。不要仅仅因为某些东西声称有崩溃恢复功能，就认为它在所有情况下都有效。

相关内容