simfs на мой взгляд более опасен :) Миллионы миллионов айнодов на хост-ноде очень часто приводят к повереждениям фс и ровно также выносит куски контейнеров.
Так что - it depends, но изоляция у ploop крутая :)
А про какие кэши вопрос? С flashcache есть несколько человек в багтрекере опенвз, у которых убило полностью все данные - можете спросить специфику у них, я не специалист по данной теме, ничего сказать не могу.
Друзья! С радостью сообщеам о множественных улучшениях в нашей системе уведомления о технических работах, теперь все без исключения клиенты информируются о проблеме в максимально короткие сроки :)
Но мы также активно работаем над уменьшением числа работ и в скором времени сможем отказаться от солидной части даунтаймов вообще! :)
Да, ситуацию еще может усугубить fsck. Он может решить пойти подправить немного экстентов, на которых лежит ploop, а так как это не простые файлы, для которых повреждение нескольких блоков можно пережить - все разлетается.
ploop - очень простой формат, в нем нет журналирования, нет бэкапа суперблока (BAT). А суперблок - это кусок данных в начале диска в 1Мб.
Если туда будет идти запись и в это время вырубится питание, то он повредится и вся тушка придет в негодность, так как только в BAT хранится маппинг между виртуальными секторами и реальным их положением в образ-файле.
Как воркэраундом может быть вариант - бэкапить суперблок самостоятельно или, в иделае, бэкапить тушки целиком, всегда.
Glueon, лучше в обоих случаях, но очень требовательно к работе железа - то есть ECC, RAID с батарейкой, хорошо резервированное питание - нужно обязательно. А также, разумеется, никаких flashcache/bcache и прочих - убьет данные, почти гарантированно.
Спасибо за спасибо :)
Там решительно больше ядер. Без повышения цены тот же 2670v3 дает в 2х процовом конфиге +4 ядра относительно 2670v2 А это +8 ядер логических (то есть 40 против 48 логических), вполне немало.
А то, что DDR4 дороже.... ну она еще и БЫСТРЕЕ.
Так что я не был бы так ориентирован к новой платформе. Скорее текущие e5 платформы надо отправлять на свалку, очевидно, v2 новых процов не будет.
Хорошо, если мы включим sysvar_innodb_flush_log_at_trx_commit, то на каждую транзакцию будет вызываться fflush, верно? В данном случае это отчасти поможет, если SSD не будет нагло врать, что flush сделан, а на самом деле он не сделал. Ситуация когда диск врет о реальном сбросе данных - крайне распространенная и используется производителями для "видимого ускорения" работы диска, даже есть тулзы как это проверить.
Но даже если с MySQL Innodb это поможет, то на сервере есть еще файловая система (почти всегда ext4) у которой стандартный коммит аж 5 секунд (commit=nrsec) и она с радостью потеряет если не базы, то сопутствующие файлы ну или сама покрашится, это довольно легко.
Мораль - аппаратный/программный RAID, батарейки при наличии денег, максимально стабильный по питанию ДЦ и регулярные бэкапы :)
Проблема не столько в кэше самих дисков, его можно отключить при желании, а в поведении страничного кэша почти любой современной ОС, когда данные пушатся блоками (когда наберется 10-20-50 записей или пройдет какое-то время), а не по мере реальной записи.
То есть, пишет тут MySQL что-то на диск раз запсисал - данные еще в памяти, два записал - снова в памяти, три записал - пошел пуш на диск. И ели до реального пуша данных еще не дошло и кончилось электричество - с данными можно прощаться. Ну и файловая система может разлететься, журнал ФС пишется зачастую даже чаще чем реальные данные.
