Ну то есть пока модно fsync отключить . Разницы никакой

Разница большая, даже 1 апреля. ;) Кстати, это ведь "касается всех", как говорится. Т.е. любая программа (другая СУБД, например), которая получает EIO в ответ на fsync и пытается его повторить... получает "приятный сюрприз".

проблема касается только buffered writes. а у других СУБД есть direct IO, например

Чтобы проблема их не касалась, должен использоваться _только_ direct IO, правильно? Кстати, как с этим в MySQL (просто любопытно)?

в MySQL с этим innodb_flush_method=O_DIRECT уже давно и повсеместно

но другие движки (myrocks, tokudb) это не используют по архитектурным причинам. и потому подвержены той же проблеме, что и постгрес

Ясно, спасибо!

проблема касается только buffered writes. а у других СУБД есть direct IO, например

нет, проблема касается еще и того что второй фсинк ретраить нельзя

нет, проблема касается еще и того что второй фсинк ретраить нельзя

"The API offered by async buffered writes and fsync offers us no way to find out which page failed, so we can't just selectively redo that write"

ну это про обсуждение воркэкраунда второго фсинка скорее

мол если бы был редёрти, то можно было бы сделать второй синк

я немножечко умеют читать по-английски

хорошо

они там прямо в тредике пишут, что direct io их бы спасло. но долго

"There's nothing we can do about that in userspace (except perhaps abandon OS-buffered IO, a big project)"

и если по ссылочкам походить, то становится ясно, что проблема именно в buffered io

да, перечитал линуксовый тред

про direct io ничего не пишут

чего я нигде не увидел — внятного объяснения, почему 4.13 проблему исправляет. там по-моему определённые сомнения остались

чего я нигде не увидел — внятного объяснения, почему 4.13 проблему исправляет. там по-моему определённые сомнения остались

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=088737f44bbf6378745f5b57b035e57ee3dc4750 смотрел это?

насколько я понимаю 1) ensure that when a writeback error occurs that that error will be reported to userland on a subsequent fsync/fdatasync/msync call, regardless of what internal callers are doing 2) report writeback errors on all file descriptions that were open at the time that the error occurred. This is a user-visible change, but I think most applications are written to assume this behavior anyway. Those that aren't are unlikely to be hurt by it.

да. но там же есть какие-то невнятные пассажи про

"document what filesystems should do when there is a writeback error. Today, there is very little consistency between them, and a lot of cargo-cult copying. We need to make it very clear what filesystems should do in this situation."

и возникают вопросы — вот это фикс, он вообще для всех fs работает или как?

а вообще удивительно, какие серьёзные последствия может иметь такая незначительная на первый взгляд вещь как direct io

хотя, как обычно, об этом уже давным давно кто-то писал: https://dom.as/2014/03/31/mongo-io/

ну с такой же вероятностью мог бы быть и фатальный недостаток с ним

учитывая что все по дефолту живут с буфферед, найти такой недостаток в только в летом 2017 просто кайф

все в постгресе по дефолту живут с buffered. ну так в постгресе все и без контрольных сумм живут

все беды с buffered — это на самом деле следствия того, что с точки зрения СУБД это совершенно ненужная прослойка перед железом. со своими причудами и багами тоже

а кстати как мускуль обрабатывает ошибку на фсинке? паник или сделает еще раз запись через директ?

конкретно EIO обрабатывает так: повторяет сколько-то раз, потом паник

но это innodb, остальные детально не проверял. я просто и так знаю, что там с direct io плохо

а бинлоги тоже пишутся директ_ио?

бинлоги без

но с бинлогами мы как раз падаем, если fsync() возвращает ненулевой статус. то есть, с этим всё нормально

начиная с 5.7.7. а до этого просто писали в лог и продолжали дальше :)

норм

забаньте паразита!

Рискну высказать свою точку зрения по поводу fsync-ов, хотя боюсь на меня сейчас вылют ушат помоев:) Итак повторно sync-ать плохо - при этом может потеряться информация об ошибках записи. Ужас, ужас, ужас... Прощай ACID (С упало, D пропало, кто остался на трубе?) Так, а из-за чего собственно ошибка то возникла? Может там диска сыпаться начал? А тогда не один ли хрен - накроется ли база сейчас или чуть попозже? Ну да, я конечно понимаю, что чем быстрее мы это обнаружим, тем быстрее мы сможем востановить базу из бэкапа (если он есть). И неверных ответов, основанных на битых данных, клиентам никто не зашлёт. И ещё есть вероятнось, что с дисков всё хоккей, "просто" на нём место кончилось. Тогда конечно не хорошо базу коррумпировать. Это я всё к чему? К тому, что есть сферические кони в ваккуме. А есть жизнь. Есть вероятность отказа диска, есть вероятность багов в ОС, СУБД,... Причём последние зачастую сильно превышают вероятности "железных" багов, всякия прилетающие из космоса частицы и.т.п. Тут было исследование, насколько хорошо современные диски и SSD переносят power failure и всегда ли заfsync-анные данные действительно в состоянии перенести жёсткое выключение. Выяснилось что чуть ли не половина моделей ведёт себя не правильно, причём не только теряет недавно записанные данные, но иногда и портит старые. Так что не надо рассматривать fsync как панацею... А знаете как работает fsync на Amazon EDS? Исключительно вероятностно. Они не пытаются честно засинкать данные на локальные диски. За счёт дублирования, они гарантируют, что вероятность потери данных меньше, чем для обычно диска с "честным" fsyncом... Так что дествительно ли обнаруженная проблема сильно снижает надёность Посгреса? Не думаю... Байка. Лет 10 назад, меня приглашали в один СУБД стартап, по написанию yet another pure Java OODBMS (у меня к тому времени была своя аналогичная). Так вот обсуждая с авторами особенности их архитектуры, а с удивлением узнал, что они не делают fsync-и. Вообще. Т.е. сливают Жавный файл кэш, и типо дело сделано. На мой вопль "№;%:?????, они спосоконо ответили, что пока никто из клиентов не жаловался, а fsync сильно тормозит работу. Продукт жмивёт до сих пор, но fsync-и я надеюсь туда всё таки прикрутили:) В общем эта тема с fsync-ами конечно важная, поучительная, и.т.п. Но я бы всё таки не драматизировал. Ну и ес-но все эти разгоовры, о том что надо использовать O_DIRECT и всё будет чики-пыки или то, что кэш ОС только мешает нормальной работе СУБД, они немного от лукавого. Я на многих своих базках эксперементировал с O_DIRECT и в результате обычно получал значительное падаение скорости. Что не удивительно,Ю потому как только ОС знает сколько у неё в ланный момент действительно памяти свободно. На пользовательском уровне такой информации нет. Мы либо не используем имеющуюся память, либо, что ещё хуже, наш якобы "кэш", оказывается отсваппированным на диск. В Посгресе было много попыток избавится отдвойной буферизации. Но эффект от большинства из них был сомнителен.

Рискну высказать свою точку зрения по поводу fsync-ов, хотя боюсь на меня сейчас вылют ушат помоев:) Итак повторно sync-ать плохо - при этом может потеряться информация об ошибках записи. Ужас, ужас, ужас... Прощай ACID (С упало, D пропало, кто остался на трубе?) Так, а из-за чего собственно ошибка то возникла? Может там диска сыпаться начал? А тогда не один ли хрен - накроется ли база сейчас или чуть попозже? Ну да, я конечно понимаю, что чем быстрее мы это обнаружим, тем быстрее мы сможем востановить базу из бэкапа (если он есть). И неверных ответов, основанных на битых данных, клиентам никто не зашлёт. И ещё есть вероятнось, что с дисков всё хоккей, "просто" на нём место кончилось. Тогда конечно не хорошо базу коррумпировать. Это я всё к чему? К тому, что есть сферические кони в ваккуме. А есть жизнь. Есть вероятность отказа диска, есть вероятность багов в ОС, СУБД,... Причём последние зачастую сильно превышают вероятности "железных" багов, всякия прилетающие из космоса частицы и.т.п. Тут было исследование, насколько хорошо современные диски и SSD переносят power failure и всегда ли заfsync-анные данные действительно в состоянии перенести жёсткое выключение. Выяснилось что чуть ли не половина моделей ведёт себя не правильно, причём не только теряет недавно записанные данные, но иногда и портит старые. Так что не надо рассматривать fsync как панацею... А знаете как работает fsync на Amazon EDS? Исключительно вероятностно. Они не пытаются честно засинкать данные на локальные диски. За счёт дублирования, они гарантируют, что вероятность потери данных меньше, чем для обычно диска с "честным" fsyncом... Так что дествительно ли обнаруженная проблема сильно снижает надёность Посгреса? Не думаю... Байка. Лет 10 назад, меня приглашали в один СУБД стартап, по написанию yet another pure Java OODBMS (у меня к тому времени была своя аналогичная). Так вот обсуждая с авторами особенности их архитектуры, а с удивлением узнал, что они не делают fsync-и. Вообще. Т.е. сливают Жавный файл кэш, и типо дело сделано. На мой вопль "№;%:?????, они спосоконо ответили, что пока никто из клиентов не жаловался, а fsync сильно тормозит работу. Продукт жмивёт до сих пор, но fsync-и я надеюсь туда всё таки прикрутили:) В общем эта тема с fsync-ами конечно важная, поучительная, и.т.п. Но я бы всё таки не драматизировал. Ну и ес-но все эти разгоовры, о том что надо использовать O_DIRECT и всё будет чики-пыки или то, что кэш ОС только мешает нормальной работе СУБД, они немного от лукавого. Я на многих своих базках эксперементировал с O_DIRECT и в результате обычно получал значительное падаение скорости. Что не удивительно,Ю потому как только ОС знает сколько у неё в ланный момент действительно памяти свободно. На пользовательском уровне такой информации нет. Мы либо не используем имеющуюся память, либо, что ещё хуже, наш якобы "кэш", оказывается отсваппированным на диск. В Посгресе было много попыток избавится отдвойной буферизации. Но эффект от большинства из них был сомнителен.

Тут недавно взрослый mysql под названием oracle rdbms тестировали со вклбченным direct io. Система сидела в основном в диске. На тойже базе,но сконвертированной для postgres при тойже нагрузке дииски молчали.

и это тоже разговоры от лукавого. Потому что при использовании O_DIRECT вся работа по IO scheduling, readahead и прочему переносится в приложение. Это сложно для реализации. Но это также означает, что разговоры "тестировал я тут O_DIRECT на своих базах" вообще не имеют смысла. Это как сказать: "тестировал я эти оптимизаторы запросов на своих базах — вообще никакого толка от них. Значит и вообще оптимизаторы не нужны"

и да, разговоры про swap — вообще ортогональны обсуждаемой теме. Кэш может оказаться в swap независимо от использования direct или buffered IO

я бы перечислил все аргументы за использование direct io. но я на 80% буду пересказывать ту статью, ссылку на которую уже приводил. а остальные 20% я уже упоминал в других местах. поэтому лень

Тут недавно взрослый mysql под названием oracle rdbms тестировали со вклбченным direct io. Система сидела в основном в диске. На тойже базе,но сконвертированной для postgres при тойже нагрузке дииски молчали.

Я не понял, это хорошо или плохо, что у Постгреса диски молчали? :)

кстати, забыл ответить на главное, т.е. на тезис "В общем эта тема с fsync-ами конечно важная, поучительная, и.т.п. Но я бы всё таки не драматизировал"

Я не понял, это хорошо или плохо, что у Постгреса диски молчали? :)

Хорошо. Тк он кеш пользовал %)

напомню, что всё это всплыло по результатам расследования реального случая data corruption у пользователя. т.е. никакие это не сферические кони в вакууме

напомню, что всё это всплыло по результатам расследования реального случая data corruption у пользователя. т.е. никакие это не сферические кони в вакууме

Ага за 30 лет существования пг. Ужас ужас.

Ага за 30 лет существования пг. Ужас ужас.

дооо, просто при каждом data corruption все же проводят вот такой же анализ и выясняют причину

каждый Вася-сисадмин в Пупкин Телеком первым делом выясняет от чего случился corruption. и до выяснения никаких действий не предпринимает

напомню, что всё это всплыло по результатам расследования реального случая data corruption у пользователя. т.е. никакие это не сферические кони в вакууме

Тесла вот тоже в аварию попала, а Уберовский робот человека задавил. Значит ли это что роботы за рулём главный источник опасности?

ERROR: S client not available

Тесла вот тоже в аварию попала, а Уберовский робот человека задавил. Значит ли это что роботы за рулём главный источник опасности?

это значит, что говорить "безопасность беспилотных автомобилей — это конечно важно и всё такое, но всё это сферические кони в вакууме" как минимум неразумно

это попытка замылить вероятность события, которое вполне встречается в реальной жизни

Я же не говорю, что проблемы нет. Что типа - фигня всё, спите спокойно. Русский авось всё вывезет... Я просто хотел заметить, что это далеко не единственная и боюсь не самая критичная проблема для надёжности СУБД.

пытаюсь найти, кто же здесь говорил: "это единственная и самая критичная проблема надёжности СУБД". ничего не находится

Один раз в 30 лет использования пг в проде. Да и вообще это проблема ос. Опенсоурс так как. Тяп ляп и в прод.

сорян, моей целью было не очернить постгрес, а указать на проблему думаю Алексей тоже не ставил себе такой задачи

принижать проблему при этом не разумно

а я вообще по случаю первого апреля хотел рассказать, какая постгрес замечательная СУБД. И как глубоко заблуждается Christophe Pettus, когда его критикует. Что он просто ничего не понимает в постгресе и вообще ¯\_(ツ)_/¯

а тут ты со своим дурацким фсинком

на субботнешней субд сессии в яндексе Леша Миловидов верно сказал как же скучно обсуждать эти ваши постгресы с мускулями

на субботнешней субд сессии в яндексе Леша Миловидов верно сказал как же скучно обсуждать эти ваши постгресы с мускулями

Ну раз яндексу скучно больше не будем

Леша Миловидов вообще жжёт напалмом

как-то на докладе на percona live его спросили: "how do you delete data?", на что он ответил: "we never delete data, we just buy new servers"

я посоветовал ему завести borat-style twitter. типа этого, только про кликхаус: https://twitter.com/mysqlborat

а я, когда выйду на пенсию и мне будет нечего делать, заведу такой же про постгрес

я посоветовал ему завести borat-style twitter. типа этого, только про кликхаус: https://twitter.com/mysqlborat

Норм

на субботнешней субд сессии в яндексе Леша Миловидов верно сказал как же скучно обсуждать эти ваши постгресы с мускулями

А что не скучно?

https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA

https://www.youtube.com/channel/UCHnBsf2rH-K7pn09rb3qvkA

А если там psql показывают это обещает быть интересным?

мораль басни --- в реальном мире похоже никому этот fsync никуда не уперся. странно всё это

просто обычно он работает

или не работает

ну и еще вывод -- не юзать xfs )

надо в pg все записи заного накатывать при ошибке на чекпоинте или только на таблицах/индексах где побилось. так что-ли? заного все валы перечитывать и писать заного всё поверх кучи

бррр