Журналирование в mongodb и postgresql — правильно ли я его понимаю?

Question

[quest2017]

копаю тут mongodb и нашел что там есть настройка storage.journal.commitIntervalMs которая настраивает сохранять журнал каждые 50ms - https://docs.mongodb.com/manual/core/journaling/

отсюда вопрос это что-же получается возможна ситуация когда клиент сохраняет в mongodb ключ, она ему отвечает что сохранила, он продолжает что-то делать будучи уверенным что ключ сохранен, а в это время не дожидаясь очередного сохранения на диск журнала все падает и ключ мы теряем?

далее у update мы видем некий writeConcern - https://docs.mongodb.com/manual/reference/write-co... где есть ключ j:true который вроде как заставляет сохранять журнал.

это решает эту проблему?

и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???

просвятите плиз!

Answer 1

[Melkij]

Точно про актуальную монгу сказать что-то затрудняюсь.
Про версию постарше цитата про вторую версию монги

MongoDB v2.0 will consider a write to be complete, done, finito as soon as it has been buffered in the outgoing socket buffer of the client host.

Отвечает "записано", когда данные даже не покинули машину клиента, не то что записаны хоть куда-нибудь.
С таким подходом задумывались ли авторы над потерей данных вообще и исправлено ли сейчас?

и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???

Если вы намеренно выкрутили гайку synchronous_commit.

fsync - это очень дорого. Даже на SSD.
Поскольку это дорого, делаются какие-нибудь фокусы. Магнитные диски ненавидят случайную запись и куда лучше относятся к последовательной. Поэтому и тут тоже придумывают какие-то фокусы.
В итоге postgresql (если вы сами не отстрелили себе ноги) пишет wal в память, отдельный процесс каждые wal_writer_delay просыпается, сбрасывает на диск накопленные wal и отмечает, в какой позиции wal гарантированно доехал до диска fsync. Поскольку synchronous_commit включен, то перед ответом клиенту "записано" воркер ждёт, пока его данные не будут записаны на диск. После этого отвечает приложению "записано".
https://www.postgresql.org/docs/current/static/run...

synchronous_commit (enum) Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a "success" indication to the client

Comments

[lega]

задумывались ли авторы над потерей данных вообще

В монге как раз продумано, там на лету можно уровень надежности задавать для каждого изменения.

есть параметр wal_writer_delay = 200ms
отдельный процесс каждые wal_writer_delay просыпается, сбрасывает на диск накопленные wal и отмечает, в какой позиции wal гарантированно доехал до диска fsync.

т.е. если я запишу 1 байт в базу, это займет (до) 200мс? Это на дефолтных натройках?

[Melkij]

Порой путаю мс и мкс, поэтому не заметил, что бред пишу.

After flushing WAL it sleeps for wal_writer_delay milliseconds, unless woken up by an asynchronously committing transaction

Коммит вызывает сброс wal на диск вне зависимости от wal_writer_delay.
Будет ли при этом fsync - зависит от гайки wal_writer_flush_after

synchronous_commit - локальная штука, можно переопределять для каждой транзакции.
А задержка коммита чтобы сделать за один fsync несколько транзакций разом - это гайка commit_delay.

Answer 2

[terrier]

и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???

По постгресу. Если включено synchronous_commit = on , то в любом случае перед тем как сообщить клиенту об успехе ждем записи в WAL на диск. Это дефолтные и почти всегда разумные настройки.
В случае synchronous_commit = off гарантируется только то, что база даже в случае падения ( метеорита ) останется в непротиворечивом состоянии, но WAL будет записан на диск через некоторое время, зависящее от настройки wal_writer_delay. Это режим "готов получить шанс потери данных при падении в обмен на увеличение производительности".