Почему так получается, что fsync=off в случае потери питания или

Question

Почему так получается, что fsync=off в случае потери питания или

kernel panic может привести к unrecoverable data corruption,
но вот, если установить synchronous_commit = off, то does not create any risk of database inconsistency?

Т.е. в первом случае может и не восстановиться, а во-втором - восстановиться гарантированно на какой-то момент времени.

#backend #devops #pgsql #programming #russian

0

07.11.2020

7 ответов

13 просмотров

Aleksey Stavrov Автор вопроса

Yaroslav Schekin
Потому что первое просто отключает все fsync-и, а ...

Отключение fsync на wal не значит потерю всех сообщений. Кажется понятным, чтое если записалось сообщение N, то и N-1 тоже записалось в случае, если fsync отключен. Т.е. пока не понятно, в чём именно проблема

0

07.11.2020

Yaroslav Schekin

Aleksey Stavrov
Отключение fsync на wal не значит потерю всех сооб...

В том, что это разрушает сам принцип Write Ahead Logging, естественно. Т.е. вообще все fsync-и отключаются, грубо говоря. ;)

0

07.11.2020

Aleksey Stavrov Автор вопроса

Yaroslav Schekin
В том, что это разрушает сам принцип Write Ahead L...

?

0

07.11.2020

Yaroslav Schekin

Aleksey Stavrov
?

! ;) Т.е. данные (в т.ч. pg_xact) могут быть записаны на диск раньше, чем их WAL. На том и конец, собственно.

0

07.11.2020

Виктор Егоров

- СУБД — Postgres — оперирует данными в больших объемах, которые хранятся на дисках - диски, ЧСХ, медленные. поэтому данные кэшируются: контроллером, ОС, самой базой. изменения происходят в кэше ( shared_buffers ) и когда-нибудь попадают на диск - чтобы обеспечить ACID совместимость, база ведёт последовательный журнал транзакций, куда осуществлятся запись до изменения данных - у этого жрунала, внезапно, тоже есть кэш — wal_buffers. так вот выключение synchronous_commit заставляет базу по максимуму использовать этот кэш. ( тут есть подстава в виде wal_writer_flush_after, установка этой крутилки в 0 равнозначно включению synchronous_commit ) т.е. за-COMMIT-ченые данные попали в shared_buffers и в wal_buffers, но не были fsync()-уты, однако база подтвердила COMMIT. при наполнении wal_buffers или наступлении wal_writer_delay — fsync() будет сделан. если же вы выключаете fsync — то всё зависит от случая. состояние данных на диске 100% будет неактуальным ( бай дизайн ), и база обязана воссздать данные из журнала после аварийной остановки. но состояни WAL будет непредсказуемым и скорее всего база руганётся на его содержимое: неправильная чексумма, не тот тип записи, что ожидали и т.д. т.е. не запуститься база с близкой к 100% вероятностью. теорию можно почитать тут: https://web.stanford.edu/class/cs345d-01/rl/aries.pdf

0

07.11.2020

om

Fsync синхронизирует файловый кеш ос с диском. В первом случае нет никакой гарантии, какие данные останутся на диске после аварии. Могут страницы бд доехать, а сегменты вал - нет. И т.п. В втором случае транзакции копятся в буфере вала, и периодически скидываются на диск. И кластер остаётся в консистентном состоянии. Пусть даже с риском потери транзакций, которые были в буфере на момент аварии.

0

08.11.2020

Yaroslav Schekin · Accepted Answer

Yaroslav Schekin

Потому что первое просто отключает все fsync-и, а второе — только [откладывает] sync WAL, который выполняется при commit.

0

07.11.2020

172 похожих чатов

Почему так получается, что fsync=off в случае потери питания или

7 ответов

Похожие вопросы