SB
Size: a a a
2021 December 06
I
это не надёжно, записывать нужно до того, как изменились данные в in memory
NV
причём тут вообще персист?
NV
не понял
MK
А где-то у постгреса в кишках написано зачем два. На какой-то freebsd есть какой-то хитрый баг при котором при каких-то обстоятельствах fsync не все данные складывает на диск
I
Ситуация:
Изменились данные в ets или persistent_term, приложение работает с новыми данными и после изменения (пусть даже в эту же секунду) происходит запись на диск. Но сервер упал, запись не произошла и приложение рестартится со старыми данными, но мгновение до аварии приложение работало с новыми данными в in memory, что вызовет конфлитк
Изменились данные в ets или persistent_term, приложение работает с новыми данными и после изменения (пусть даже в эту же секунду) происходит запись на диск. Но сервер упал, запись не произошла и приложение рестартится со старыми данными, но мгновение до аварии приложение работало с новыми данными в in memory, что вызовет конфлитк
MK
Нет, просто одно время у меня в моей курилке водился Фёдор Сигаев
NV
ну это уже атомарность, тут уж извините, а что если данные уже на половину считались из сокета, или откуда они там приходят, и тут мы падаем - ожидают ли от нас, что они применились - мы же на tcp хэндшейк ответили? Значит надо сначала записывать, потом применять, например
NV
и отвечать на запрос изменения параметров успехом только тогда, когда они записались + применились (записались - на первом месте)
I
Причём тут tcp? Конфиг сначала должен оказаться в постоянной памяти, потом применяться в приложении.
NV
короч вы о какой-то фигне в вакууме рассуждаете, сверху описано 100 способов обеспечения надежности, выбирайте любой
I
ets tab2file - не надёжно без временных таблиц, что не особо простое решение
NV
считал, дампнул под временным именем, ренеймнул, отрепортовал об успехе, в чём сложность?