Как обезопасить базу данных от аварийных выключений?
Разрабатываю программу которая будет собирать данные в БД, пока что ориентируюсь на MySQL.
В базе на ssd диске будут храниться как сырые данные, так и результаты вычислений.
При этом аварийное отключение питания это частая и неустранимая специфика работы.
Как-то можно повысить стойкость БД к внезапным отключениям питания?
Допустима утеря каких-то последних данных, но недопустима порча БД, после перезагрузки и перезапуска ПО работа должна продолжиться.
Возможно есть какие-то специфические настройки БД или стратегии работы с БД которых нужно придерживаться?
UPD
Это относительно портативное устройство с питанием от розетки, батарейное питание не предусмотрено.
И его гарантированно будут случайно выдёргивать из розетки во время работы.
Алексей Тен, Совершенно верно. Это прибор без аккумуляторов и с питанием от розетки. Ранее обходились скидыванием данных в файл, но пришли к необходимости использования полноценной БД.
И после того как эта штука сядет, всё равно произойдёт аварийное выключение.
Лишние 15 минут работы перед аварийным отключением не сделают его менее аварийным :)
Вопрос не по железному обеспечению, вопрос по софтверной части.
Почти любая современная БД пишет WAL и fsyncает всё важное. Худшее что случится при внезапном отключении - потеряется то, что не дописалось в WAL.
С mysql есть ряд приколов - надо читать ее доки, не все её storage engines могут в wal.
Хотите сказать эта проблема не такая уж и проблема?
Хотим сказать, что в аббревиатуре описания транзакционный систем ACID последняя буква обозначает ровно то что вам и требуется. И это что-то - полвека теории и практики как не терять даже одну транзакцию при любом сбое.
А так например даже sqlite говорят, что сбои питания - часть регрессионных тестов.
Реально волноваться вам необходимо скорее за файловую систему. Если подыхает ФС - то подыхает любая СУБД размещенная поверх.
Т.е. нужно:
- проверить настройки durability вашей СУБД
- проверить опции монтирования вашей ФС
- проверить настройки кеша записи вашей системы хранения
Чтобы оно всё в сумме на всех уровнях не вздумало игнорировать fsync.
Melkij, ага, теперь понятней.
настройка субд это вероятно innodb_change_buffering=none
А что имеется в виду под опциями монтирования? там вроде про отказоустойчивость нет, выбираю тип ФС и режим чтения.
у каждой файловой системы достаточно много опций, большую часть можно задавать при монтировании, но бывает что какие-то только при форматировании устанавливаются.
Смотрите ext4, она с журналом идет по умолчанию, ну и в принципе там дефолтные опции ориентированы на надежность в основном.
Вообще обычно цепочка какая: используется БД с журналом, опции ускорения типа кэшей всяких отключаются. Далее это пишется на файловую систему с журналом. Которая находится на диске с батарейкой (сейчас, в век SSD, это стало удобнее - делают SSD с конденсаторами сразу, которых хватает на сброс кэша самого ссд). Ну и SSD не забиваем на 100% никогда и используем TRIM, чтобы в случае такой вот аварии не пришлось ему сначала сборку мусора запустить, а потом уже нашлось куда кэш сбросить.
настройка субд это вероятно innodb_change_buffering=none
Начните отсюда с durability по списку: https://dev.mysql.com/doc/refman/8.0/en/mysql-acid.html
Для mysql так же уточните насколько транзакционен сейчас их системный каталог. Это обещали исправить как раз в 8.0 перейдя на нормальное транзакционное хранение каталога. Я не знаю насколько полностью это сделали, до того использовалась куча бинарного мусора под названием myisam легко подверженная сбоям.
А, и разумеется - все таблицы обязаны быть innodb, если уж хотите именно mysql. Это не настройка субд, это к автору схемы данных.
А что имеется в виду под опциями монтирования? там вроде про отказоустойчивость нет, выбираю тип ФС и режим чтения.
Добро пожаловать в этот огромный новый неизведанный мир. Вот например список только по ext4: https://www.kernel.org/doc/Documentation/filesyste...
У других ФС свои списки опций. И я не вполне уверен что для таких условий ext4 оптимальный выбор, может есть что более подходящее и рассчитанное на регулярное отключение питания. Может что-то из используемого в роутерах всяких.
Кэши чтения на durability не влияют и их крутить можно спокойно.
Кэши записи данных в самой СУБД - крутить можно, но с оглядкой на то что это именно такое и как крутится. СУБД запись данных кэшировать может без влияния на durability, влияет только на время старта базы после сбоя.
Запись журналов - строго fsync на каждый commit в такой задаче необходим.
И самое важное - все нижележащие слои должны гарантировать что если база попросила fsync - то данные именно во время выполнения этого syscall окажутся на дисках и ни миллисекундой позже.
Вопрос работы оборудования при регулярных отключениях был успешно решён ранее.
Теперь стоит вопрос ПО для хранения данных, как писать данные в БД при регулярных отключениях.
Такая конфигурация не имеет право называться базой данных. Присоединяюсь ко всем ораторам. Просто добавлю что портативное устройство должно писать логи операций. Чтобы выполнять разбор полетов и фиксировать что делалось. Можно с ротацией. А база данных должна лежать отдельно. На надежных удаленных серверах.
MySQL - это не совсем DBMS. Это сборный лего-конструктор в котором каждая таблица в отдельности сама определяет свой уровень отказоустойчивости (т.н. engine). Поэтому обсуждать надёжность MySQL нет смысла без обсуждения того как была создана каждая таблица. In general - про надёжность сказать ничего невозможно.
И как бэкап поможет предотвращать повреждение БД?
Сделал бэкап на флешку и можно выдёргивать из розетки, база точно не повредится?
Бэкап это лишь маленький бонус, когда прибор привезли в ремонт можно обрадовать заказчика что данные как минимум до последнего бэкапа у него сохранились.
Простой
