Имитировать потерю мощности с размонтированной силой?

Я хочу протестировать аварийное восстановление RDBM после потери мощности при высокой нагрузке.

Моя идея - смонтировать каталог данных под новой точкой монтирования, а затем выполнить umount -f во время загрузки и изучения результатов / состояния файлов.

Я ожидаю, что с недолговечной конфигурацией данные должны быть непоследовательными и непротиворечивыми в противном случае.

Кто-нибудь считает, что это хорошая идея и, возможно, другие связанные подсказки (например, какую файловую систему лучше использовать, или мои ожидания не имеют значения, тогда почему)?

Источник

1 ответ

Решение

Предположительно, вы фактически удаляете власть. 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%. Даже если хранилище сделало что-то нормальное в этом сценарии, СУБД может быть недовольна, если ее тома будут прочитаны только в середине записи.

  • Отключите все пути к SAN, чтобы имитировать то "неразрывное" обслуживание хранилища, которое не выполняется.

  • Найдите процесс, который выполняет запись, и отправьте ему сигнал SIGKILL или его эквивалент.

  • Сбой ОС. Например, в Linux echo 'c' > /proc/sysrq-trigger

Состояние данных, оставшихся после теста, зависит от хранилища и СУБД. Либо у них может быть журнал, который они могли бы воспроизвести, либо, возможно, у них нет. Вы, вероятно, хотите сделать fsck или эквивалент в файловой системе. Если база данных может восстановиться в согласованный момент времени, из журналов или чего-либо еще, вы можете сделать это. Если у вас есть средство проверки целостности для СУБД, используйте его как проверку работоспособности.

Надеюсь, вы уже провели тест восстановления вашей резервной копии на всякий случай. Не думайте только, что что-то требует восстановления после сбоя, что оно работает во всех ситуациях.

Источник
Другие вопросы по тегам