Журналирование в mongodb и postgresql — правильно ли я его понимаю?
Точно про актуальную монгу сказать что-то затрудняюсь.
Про версию постарше цитата про вторую версию монги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
и тут я вспомнил что у postgresql есть параметр wal_writer_delay = 200ms, что-же получается и у postgresql может быть такая ботва что клиент думает что строка сохранена а все накрылось до сброса журнала на диск???
По постгресу. Если включено synchronous_commit = on , то в любом случае перед тем как сообщить клиенту об успехе ждем записи в WAL на диск. Это дефолтные и почти всегда разумные настройки.
В случае synchronous_commit = off гарантируется только то, что база даже в случае падения ( метеорита ) останется в непротиворечивом состоянии, но WAL будет записан на диск через некоторое время, зависящее от настройки wal_writer_delay. Это режим "готов получить шанс потери данных при падении в обмен на увеличение производительности".