ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
2 мая
1165339 Топик полностью
Nikolay_Po (16.01.2022 17:50, просмотров: 115) ответил Cкpипaч на Готов урезать осетра в двадцать раз. На самом деле это очень тонкий вопрос, сколько данных пишется на диск.
P.S. Предложенное в этом сообщении ниже, позволяет не модифицировать имеющуюся базу данных, при этом обеспечивая производительность в типовых применениях, приближающуюся размещению базы SSD. 

Я за такой расклад: RAID-5 на традиционных HDD, а поверх него, в режиме блочного кэширования, RAID-1 на SSD, меньшего объёма, чем сами данные. Имею опыт, правда, у меня обычная работа сервера виртуальных машин, а не БД.

Собственно, кэширование делается bcache. В режиме writeback поддерживается кэширование записи, ускоряя работу в обоих направлениях. Теоретически, можно настроить скрипт, когда по отказу одного из накопителей кэширующего массива SSD, даётся команда bcache перейти из режима кэширования [writeback] в режим кэширования [writethrough]. Тогда то, что было записано в SSD, но не было занесено на HDD, будет выгружено на HDD и статус кэша поменяется с "dirty" (записанные данные ещё не попали на HDD) на "clean" (все записанные данные - на HDD). Цитата: "Cache SSD's in writethrough and in writearound mode can be shared by multiple backing devices, as they do not cause data loss when they fail."

В предложенной схеме, когда отказал один из кэширующих накопителей SSD, оперативно выключается кэширование записи и данные с уцелевших SSD переносятся на HDD без потерь и без продолжения интенсивной записи на SSD. После выгрузки (статус кэша "clean", можно проверить из скрипта "cat /sys/block/bcache0/bcache/cache_mode" или типа того) данных на HDD, развал кэширующего RAID становится не критичным, данные не теряются, лишь падает скорость работы с БД.

За умеренное вознаграждение могу проконсультировать подробнее и помочь с настройками.