Хотите сказать эта проблема не такая уж и проблема?
Кстати, память которую я отрезал от /home, не понятно куда пропала, ведь в Free PE она не прибавилась и в выдачи df -h, я её не наблюдаю, куда делась то?:)))
Растет io write и read
При этом в постгресе на всякие буферы используется 17 гиг.
Начните отсюда с 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 окажутся на дисках и ни миллисекундой позже.