主页 / server / 问题 / 879935
Accepted
noonex
Asked: 2017-10-24 19:35:28 +0800 CST

通过强制卸载模拟功率损失？

  • 772

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

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

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

有没有人认为这是个好主意，也许还有其他相关的提示（例如，哪个文件系统更好用或者我的期望无关紧要，那么为什么）？

filesystems

1 个回答

  1. Best Answer

    大概你实际上是在移除电源。 umount -f还不足以模拟许多失败。

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

       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 的完整性检查器，请将其用作完整性检查。

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

    • 1

相关问题