Я хочу протестировать аварийное восстановление RDBM после потери питания при высокой нагрузке.
Моя идея - смонтировать каталог данных под новой точкой монтирования, а затем выполнить umount -f во время загрузки и исследуйте результат / состояние файлов.
Я ожидаю, что с недолговечной конфигурацией данные должны быть непоследовательными и непротиворечивыми.
Кто-нибудь думает, что это хорошая идея и, возможно, другие связанные подсказки (например, какую файловую систему лучше использовать или мои ожидания не имеют значения, тогда почему)?
Предположительно вы действительно снимаете власть. 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%. Даже если хранилище сделало что-то разумное в этом сценарии, СУБД может быть недовольна, если ее тома будут доступны только для чтения в середине записи.
Отключите все пути к сети SAN, чтобы смоделировать это «бесперебойное» обслуживание хранилища, которого нет.
Найдите процесс, который действительно пишет, и отправьте ему сигнал SIGKILL или аналогичный.
Сбой ОС. Например, в Linux echo 'c' > /proc/sysrq-trigger
Состояние данных, оставшихся после теста, зависит от хранилища и СУБД. Либо у них есть дневник, который они могут переиграть, либо нет. Вероятно, вы захотите выполнить fsck или эквивалент файловой системы. Если база данных может восстановиться до согласованного момента времени из журналов или чего-то еще, вы можете захотеть это сделать. Если у вас есть средство проверки целостности СУБД, используйте его для проверки работоспособности.
Надеюсь, вы уже на всякий случай провели тест восстановления своей резервной копии. Не думайте, что это работает во всех ситуациях только потому, что что-то требует восстановления после сбоя.