А что вообще положено делать вам и вашим клиентам для того чтобы не убить данные в таком случае? Даунтайм понятно - это минус чуть-чуть упущенной прибыли, одноразово, форс-мажоры бывают, компенсировали, забыли.
Но "убились нахрен все данные клиентов" - это же печаль какая-то совсем. Ладно, предположим клиенты (наученные) делают бэкап себе, а с вашей стороны хоть какая-то техническая возможность избежать хотя бы повреждения FS есть?
С точки зрения виртуалок это всё было как "отключили по питанию".
А "потеря данных"... Я лично наблюдал клиента, который пытался убедить fsck сделать проверку для PV-тома на LVM. Такому ума хватит метаданные ext3 поверх метаданных LVM накатать.
Т.е. журнализация в файловых системах таки работает нормально, в смысле что они переживают отключение питания как положено, не умирая?
Просто я удолбался выяснять аналогичный вопрос про базы данных. По любой логике сбой питания - такая же проблема, как и все остальные, и соответственно транзакции после commit должны быть на диске и после включения их изменения будет видно. Но на практике возникают разнообразные вопросы вида "а рейд-контроллер ли у вас с батарейкой", "без UPS базы регулярно дохнут", т.е. практически базы данных не всегда переживают издевательство с выключением машин.
Ключевое: write cache. Отсюда требование батарейки. Если нет батарейки и есть write cache - то при фейле всего и вся теряется не только current state, но и некий произвольный кусок предыдущих. Не факт, что консистентый с точки зрения БД.
У нас потому SSD (RAID10 over SSD) для кеширования на запись и используется, чтобы в случае эпикфейла всего лишь продолжнить работу.
>> Т.е. журнализация в файловых системах таки работает нормально, в смысле что они переживают отключение >> питания как положено, не умирая?
У ext4 да, ext3 может в редких случаях данные терять, особенно на больших разделах с терабайтами инфы. В случаях восстановления файловой системы чем больше раздел и чем больше на нём лежит - тем хуже.
reiserfs - как повезет, чтобы дохло по питанию с включенным write cache было 1 раз, еле просрались потом. 12 часов проверок, восстановлений и танцев с бубном.
Но "убились нахрен все данные клиентов" - это же печаль какая-то совсем. Ладно, предположим клиенты (наученные) делают бэкап себе, а с вашей стороны хоть какая-то техническая возможность избежать хотя бы повреждения FS есть?
Reply
А "потеря данных"... Я лично наблюдал клиента, который пытался убедить fsck сделать проверку для PV-тома на LVM. Такому ума хватит метаданные ext3 поверх метаданных LVM накатать.
Reply
Просто я удолбался выяснять аналогичный вопрос про базы данных. По любой логике сбой питания - такая же проблема, как и все остальные, и соответственно транзакции после commit должны быть на диске и после включения их изменения будет видно.
Но на практике возникают разнообразные вопросы вида "а рейд-контроллер ли у вас с батарейкой", "без UPS базы регулярно дохнут", т.е. практически базы данных не всегда переживают издевательство с выключением машин.
Reply
У нас потому SSD (RAID10 over SSD) для кеширования на запись и используется, чтобы в случае эпикфейла всего лишь продолжнить работу.
Reply
>> питания как положено, не умирая?
У ext4 да, ext3 может в редких случаях данные терять, особенно на больших разделах с терабайтами инфы. В случаях восстановления файловой системы чем больше раздел и чем больше на нём лежит - тем хуже.
reiserfs - как повезет, чтобы дохло по питанию с включенным write cache было 1 раз, еле просрались потом. 12 часов проверок, восстановлений и танцев с бубном.
по xfs статистики нет, может в будущем появится.
Reply
Reply
Reply
Reply
Leave a comment