Я заметил, что конфигурация по умолчанию для zookeeper.forceSync — «нет».
Это означает, что FileChannel.Force() не будет вызываться в журнале упреждающей записи.
У меня сложилось впечатление, что алгоритм консенсуса Zab, используемый zookeeper, работает правильно. Эта вся запись должна была быть сохранена на диск, прежде чем отвечать лидеру. В противном случае при выборе лидера некоторые данные могут быть потеряны.
Безопасно ли, что значение по умолчанию «нет»?
Нет, работать с forceSync=no небезопасно.
Как обсуждалось в списке пользователей zookeeper в 2014 году:
There's a big warning in the documentation that says that's a possibility.
If you don't force both Java and the OS to flush their IO buffers to disk,
then you have no guarantees that your data is consistent.
Глядя на документы администратора Zookeeper в 2020 году, там говорится только:
forceSync
(Java system property: zookeeper.forceSync)
Requires updates to be synced to media of the transaction log before
finishing processing the update. If this option is set to no,
ZooKeeper will not require updates to be synced to the media.
Вы должны смотреть выше этого на заголовок раздела и первый абзац раздела, чтобы знать об опасности:
Unsafe Options
The following options can be useful, but be careful when you use them.
The risk of each is explained along with the explanation of what the
variable does.
Для меня это не является «большим предупреждением в документации», кроме как сказать, что все настройки в этом разделе описаны как «небезопасные». Информация о рисках использования опциона отсутствует. Например, я ожидаю, что в надежной документации упоминается риск коррелированных сбоев, обсуждаемый ниже. Вы можете подумать о том, чтобы поднять вопрос о том, что документация по этому небезопасному варианту не так ясна и полезна, как должна быть.
Обсуждение в 2014 году, кажется, указывает на то, что в то время forceSync был включен по умолчанию. Они говорят об ошибке в forceSync=no, из-за которой люди не видели ожидаемого улучшения производительности. Это говорит о том, что значение по умолчанию было безопасным и что вам пришлось «отказаться от безопасности», установив forceSync=no для повышения производительности. Если по умолчанию сейчас forceSync=no, я предлагаю вам сообщить об ошибке.
Обсуждение на форуме продолжается и предполагает, что при сбое одного узла не должно быть проблем. Это будет иметь место, поскольку не будет подтверждений записи в ансамбле под ZAB, пока данные не будут по крайней мере на двух узлах. Вы потеряете данные при сбое одного узла, если данные не будут сброшены и не реплицированы более чем на один узел.
Большая проблема, когда данные не сбрасываются на диск, возникает при коррелированном сбое узлов. Если диск не сброшен хотя бы на одном узле, запись, подтвержденная клиенту, может быть потеряна. Zookeeper часто используется для метаданных небольшого объема, таких как результаты выборов лидера. Весь смысл Zookeeper в том, что хранение таких важных данных должно быть безопасным. Забвение того, кто победил на выборах руководства, может нанести огромный ущерб системе, которая полагается на Zookeeper в плане безопасности, но на самом деле не записывает данные в Zookeeper. В таких случаях использования записи с низкой пропускной способностью, где обычно развертывается Zookeeper, люди часто могут и должны безопасно работать с forceSync=yes.
Как подчеркивается в теме 2014 года, существуют подходы, которые можно использовать, чтобы попытаться сделать безопасным не принудительное использование диска. Упоминаются рейд-контроллеры с батарейным питанием, которые, как я помню, были на физических серверах на рубеже веков. У нас также были совмещенные блоки питания на каждом сервере, подключенном к двум внешним энергосистемам, резервные сетевые карты, резервные генераторы для восстановления питания и т. д. Затем вы можете разместить серверы, на которых работает ансамбль, в разных стойках, чтобы весь сетевой трафик проходил через несколько верхних -стоечные выключатели. Это снизит риск коррелированных отказов до незначительного уровня. В этот момент вы можете спать по ночам и беспокоиться только о случайном запуске развертывания, которое убило несколько процессов одновременно. Возможно, это то, что документация означает «быть осторожным» при использовании этой опции.
Проблема в том, что в трех последних глобальных компаниях, в которых я работал, развернутый Zookeeper был на стандартных виртуальных машинах без каких-либо гарантий относительно расположения стойки, антиаффинности или коррелированных сбоев. Не было никакой гарантии, что если я настрою пять виртуальных машин для размещения ансамбля Zookeeper, все они не будут размещены на одном и том же физическом хосте. Кроме того, во время любого будущего обновления оборудования команды инфраструктуры оставляют за собой право перемещать виртуальные машины между физическими хостами без консультации с нами. Когда виртуальные машины находятся на одном хосте, у вас очень мало защиты от коррелированных сбоев. Я просто не стал бы спать по ночам с forceSync=no, не будучи уверенным, что приняты пуленепробиваемые меры, гарантирующие, что коррелированные сбои не произойдут.
