Я был бы очень признателен за совет, как это исправить. У меня есть Debian KVM-Host с 9 запущенными на нем VMS Debian. Виртуальные машины работают в моем маленьком хранилище через iSCSI.
Теперь мой коммутатор просто временно потерял питание, и с ним разорвалось соединение от хоста к хранилищу. Теперь у меня есть хост, полный VMS, которые находятся в приостановленном режиме, потому что не могут справиться с этим внезапным прерыванием.
У меня такое чувство, что я мог испортить диски всех своих виртуальных машин. Кто-нибудь из вас знает, есть ли еще надежда на восстановление виртуальных машин?
Редактировать: Я снова подключился к цели iSCSI, сохранив состояние виртуальных машин и перезагрузив хост. Операционные системы на дисках по-прежнему ломаются. Знаете ли вы, сохраняется ли это для их жесткой перезагрузки или есть другой способ решить это состояние? Все они созданы с помощью EXT4.
Современные ОС и файловая система гораздо более устойчивы к повреждениям, и то же самое можно сказать о MySQL (особенно при использовании с таблицами InnoDB).
По сути, все, что записано на диск с sync/fsync семантика должна быть защищенной от сбоев, так как операции записи не вернутся, пока данные не будут в стабильном хранилище. Более того, InnoDB использует внутреннее ведение журнала, чтобы гарантировать, что частичная запись не записана.
Короче говоря, хотя иногда может произойти небольшая потеря данных, я был бы очень удивлен, если бы современная установка Linux (2.6.33+) стала полностью неправильной после сбоя.
Qemu намеренно приостанавливает работу виртуальных машин при ошибках io, чтобы избежать повреждения дисков. Все, что вам нужно сделать, это восстановить соединения iscsi и запустить / возобновить работу виртуальных машин.
Редактировать: Даже после того, как коммутатор снова получил питание и хранилище стало доступным, виртуальные машины все еще находились в неактивном аварийном состоянии. Они не отреагировали ни на какой ввод, вынудив меня выполнить полный сброс один за другим, полагаясь на ведение журнала файловой системы для устранения повреждений. Мне повезло, что это сработало, и ничего не сломалось.
Насколько я понимаю, мне повезло, поскольку fsck удаляет / восстанавливает только ошибочные ссылки, не учитывая целостность данных. Сервер MySQL, кажется, работает нормально, но если все по-прежнему на месте, это другой вопрос. Я был бы признателен за некоторые комментарии о том, как я мог бы лучше справиться с этой проблемой (помимо кластеризации, более частого резервного копирования и подобных действий).