Да

А для каких данных?

Есть просто точка зрения, что репликации в разные ДЦ без fsync достаточно для 99.9% случаев

У финансоаго сервиса  у него и так три бекапа

Не все решения я подерживаю и одобряю но они есть и я подерживаю(технически)

а репликация конечно асинхронная?

а чего его не включать то?
на NVMe нормальных он достаточно дешев

его отключали то тупо просто чтобы "размазывать нагрузку"

а вы отключаете?

Да, но сами NVMe всё ещё дороже обычных SSD. И нельзя исключать, что у кого-то базы работают даже на HDD. Вопрос был скорее в том, насколько часто в практике встречается случай, когда данные требуется синкать на каждый запрос, и никакая другая схема обеспечения отказоустойчивости невозможна?

Я опросил знакомых программистов, и только один сказал, что видел fsync один раз в каком-то проекте Mail.ru, но и там его быстро отключили, так как всё тормозило

Всё на усмотрение клиента. Если клиент обладает большим количеством денег и железа для обеспечения такого уровня отказоустойчивости, то можем включить. Но пока такие не встречались. Обычно люди экономят на железе и соглашаются на риски

вообще насколько я помню, большинство DBE сами управляют кешами и взаимодействием с дисковой подсистемой и тот же flush/fsync делают сами в критический момент. В свое время было много сложностей с виртуализацией, потому что виртуализированный сторадж только имитирует fsync :)

не на каждый запрос а на каждый коммит, разница есть

=) ну, если вы считаете какую нибудь лабуду, то можно и отключить
а если бабло, то я бы все таки не советовал

ну а в WALах разве не каждый запрос надо сохранять (синхронно) ?

в WAL'ах, пишется если что содержимое транзакции, чтобы ее потом можно было проиграть, может быть несколько запросов в одной транзакции

fsync делается в финале транзакции а не в финале запроса, так понятнее? ;)

Ага, спасибо

и еще для PostgreSQL не стоит synchronous_commit  путать с fsync

вот его вполне себе можно отключать off или ставить в local

Могу сказать, как fsycn и запись в WAL работает в oracle. Но там все настолько хитро, что нет наверное человека вне оракла, кто это понимает до конца т.к это все еще завязано на файловую систему может быть. Поправите, если где ошибусь.  Чтобы минимизировать стоимость fsync он пишет в директ моде т.е при открытии файла. он открывает его с флагом - O_DIRECT (since Linux 2.4.10) Try to minimize cache effects of the I/O to and from this file. И еще он выставляет O_SYNC Write operations on the file will complete according to the requirements of synchronized I/O file integrity completion (by contrast with the synchronized I/O data integrity completion provided by O_DSYNC.) А при записи он батчует. В целом там идея такая, что пачк по времени или размеру. что раньше( как и в кафке). И в целом получается, что у него fsync уже дешевле выходит. Он синкает не всю транзакцию, а пачку.

Ну то есть можно продолбать несколько транзакций, если не успели синкнуть последнюю пачку?