The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Обновление PostgreSQL с устранением серьёзных проблем с fsync

14.02.2019 20:08

Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.2, 10.7, 9.6.12, 9.5.16 и 9.4.21, в которых исправлено около 70 ошибок. Наиболее значительным изменением стала переработка механизма использования вызова fsync() для обеспечения целостности записываемых на диск данных.

Оказалось, что вызов fsync() некорректно используется в PostgreSQL уже около 20 лет, что потенциально могло приводить в Linux, NetBSD и OpenBSD к потере записываемых данных в случае аппаратных сбоев. Разработчики PostgreSQL полагали, что успешно завершившийся вызов fsync() гарантирует, что поступившие данные записаны на постоянный носитель, но оказалось, что существуют ситуации когда это не так.

В случае когда ядро не может записать данные, например из-за сбоя буферизированного ввода/вывода вследствие аппаратной ошибки, некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов. Таким образом, ранее переданные данные отбрасываются, а блоки помечаются как очищенные. Получив код ошибки PostgreSQL опять попытается сбросить на диск данные и ещё раз вызывает fsync().

Так как буферы были очищены повторный вызов будет завершён успешно и PostgreSQL посчитает, что все данные записаны успешно. Но на деле, при чтении блоков, которые PostgreSQL полагает записанными, будет возвращено не то, что ожидается. Проблема усугубляется тем, что в разных операционных системах fsync() ведёт себя по разному и логичным кажется поведение, когда данные не отбрасываются при первой же неудачной попытке записи, а сохраняются в памяти в состоянии "dirty" для повторения попыток записи.

Начиная с выпусков PostgreSQL 11.2, 10.7, 9.6.12, 9.5.16 и 9.4.21 логика обработки ошибок fsync() изменена и PostgreSQL теперь не пытается после сбоя выполнения fsync() повторно вызвать fsync(), а завершается с выдачей фатальной ошибки. Данный шаг даёт возможность при перезапуске восстановить корректное состояние данных на основе WAL-лога, минуя скрытое повреждение содержимого базы. Подобная логика обработки ошибки может показаться неоптимальной, но разработчики сочли данное решение достаточным так как указанные проблемы возникают крайне редко.

Для систем, ядро которых не сбрасывает содержимое буфера записи после сбоя, в настройки добавлена опция data_sync_retry, позволяющая вернуть старое поведение с двойным вызовом fsync(). Например, FreeBSD не очищает состояние и при повторном вызове fsync() повторно выведет ошибку.

Поведение с очисткой буфера записи после ошибки объясняется тем, что в подавляющем большинстве случаев ошибки ввода/вывода возникают из-за удаления USB-накопителя без отмонтирования. Без очистки ситуация, когда какой-то процесс продолжает пытаться записать большой объём данных, приведёт к накапливанию страниц в состоянии "dirty", вплоть до исчерпания доступной памяти. Очистка же помогает сохранить работоспособность системы в подобных ситуациях.

Дополнительно можно отметить, что факт ошибки не всегда удаётся отследить. Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно. Компания Google для обхода описанной проблемы использует альтернативный метод обработки ошибок ввода/вывода, основанный на сборе сведений об ошибках напрямую из ядра через netlink-сокет. Другим вариантом является использование прямого ввода/вывода (DIO), который предоставляет дополнительные механизмы для отслеживания сброса данных на диск и контроля за активностью ввода/вывода.



  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Обновление PostgreSQL 11.1, 10.6, 9.6.11, 9.5.15, 9.4.20 и 9.3.25
  3. OpenNews: Выпуск PipelineDB 1.0.0, надстройки к PostgreSQL для непрерывной обработки потоков
  4. OpenNews: Релиз СУБД PostgreSQL 11
  5. OpenNews: Для PostgreSQL предложено новое хранилище zheap
  6. OpenNews: Microsoft поглотил компанию Citus, развивающую СУБД на базе PostgreSQL
Лицензия: CC-BY
Тип: Программы
Ключевые слова: postgresql, fsync
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (84) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (1), 20:16, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    а как с этим обстоят дела у оракала?
     
     
  • 2.20, nobodynoone (?), 22:40, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    O_DIRECT и свой велосипед буферов.
     
  • 2.48, Andrey Mitrofanov (?), 10:18, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > а как с этим обстоят дела у оракала?

    Тут не понятно, как оно "обстоит" к постреса-то, а ты про...  проприертарь какую-то.

     
  • 2.57, Аноним (57), 10:57, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У постгреса fsync выключается одной строкой fsync = off.
    У mysql пришлось исходники править т.к. O_DIRECT в итоге не отключал вызовы fsync.
     
     
  • 3.77, одмин (?), 08:51, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я выключаю, у меня блок бесперебойного питания и потоковая репликация.
    считаю что пусть этим занимается ядро системы а не ядро постгреса.
     
     
  • 4.79, Аноним (79), 10:24, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я выключал, потому что KMail тормозила :)
     
  • 4.97, postgres (?), 17:20, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а когда у него навернется база (причем не сразу, поэтому что там будет в среплицированных копиях - рандом его знает) - виноваты будем мы, ядро системы, что угодно, короче, кроме его фатального непонимания как именно субд взаимодействуют с этим самым ядром, в сочетании с беспокойными ручонками, которым лучше бы уж член и не выпускать :-(
     
     
  • 5.99, odmin (??), 13:56, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    фатальное непонимание? LOL, давай продолжим - фатальное непонимание у разработчиков которые добавили эту олцию?!
     
  • 5.100, odmin (??), 13:58, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    и база наверное должна навернуться, потому что.... кто то что-то удалил??!!
     
  • 4.98, Онаним (?), 13:49, 20/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ностоящий девопс, паздравляю
     
  • 2.78, Аноним (78), 08:56, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Отлично, его же профессионалы делают.
     
  • 1.3, Аноним2 (?), 20:34, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    >  Можно отметить, что компания Google для обхода...

    А добавить свое решение в комьюнити они пробовали? пропиерасты

     
     
  • 2.15, Аноним (15), 22:15, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Может и пробовали. Ты думаешь так просто закоммиить в postgres? Ты знаешь сколько желающих запихнуть туда свой exstension, чтобы патчи самим не поддерживать.
     
     
  • 3.46, Анонимный прохожий (?), 09:36, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты думаешь так просто закоммиить в postgres?

    Олег Бартунов на одном из семинаров рассказывал, как это работает.  Бывает, проходит несколько лет, пока патч не войдёт в основной релиз.

     
     
  • 4.59, нах (?), 11:49, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ты правда думаешь что в других опенсосных прожектах оно как-то иначе? Причем это несколько лет не пассивного ожидания щастья, а регулярных попыток разработчиков закрыть тикет notabug, советов куда тебе пойти и что еще им улучшить до того как они соизволят коснуться твоего грязного патча, ну и бесконечного его исправления в погоне за уходящим поездом апстрима (который тебе возможно нафиг не нужен, ибо ломает еще в десяти местах)

    Причем с весьма вероятным таки notabug, closed, comments allowed only from developers, через эти два года, вместо мержа.

     
     
  • 5.80, Аноним (79), 10:47, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    встречаются исключения, где сперва принимают, а потом дают советы :)
     
     
  • 6.90, Andrey Mitrofanov (?), 10:56, 18/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > встречаются исключения, где сперва принимают, а потом дают советы :)

    Угрожая-то выносом из staging на мусорку?  А не обращайте внимания -- это не про кодинг, платиновые взносы где-то подзадержались.  "Трудности перевода."

     
  • 2.49, Andrey Mitrofanov (?), 10:19, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>  Можно отметить, что компания Google для обхода...
    > А добавить свое решение в комьюнити они пробовали? пропиерасты

    Это ж он, бизнес _дружественный_ к опенсорсу.

    Понимаете[I]?!

     
  • 2.58, Qwerty (??), 11:03, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >А добавить свое решение в комьюнити они пробовали? пропиерасты

    Они тебе что-то должны? Ты сам не хочешь выложить все свои наработки (ха-ха) в открытый доступ?

     
     
  • 3.76, SAF0001 (?), 04:39, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А они свои наработки в общий доступ выкладывают не с целью денег заработать? А раз с целью заработать то и разговор другой.
     
  • 2.60, КО (?), 12:22, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А оно нужно?
    Так ли уж часто БД будет менять файл в котором произошли сбои до того как БД его открыла?
     
  • 1.4, Crazy Alex (ok), 20:45, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Ну, при проблемах с диском лучше сразу умереть - это логично. Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?
     
     
  • 2.8, Аноним (8), 21:17, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Но интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?

    Т.е. тебе рассказать зачем нужен fsync?

     
     
  • 3.9, Crazy Alex (ok), 21:24, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    не, мне рассказать, зачем сбрасывать буфер если fsync не успешен
     
     
  • 4.11, Аноним (8), 21:40, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А, извини. Я думал ты неуч, а ты просто лентяй и даже новость не прочитал.
     
     
  • 5.17, Crazy Alex (ok), 22:20, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я, конечно, тот ещё лентяй, но новость читал, и даже не раз, так как несколько обалдел от такого контринтуитивного поведения оси. Но да, сейчас добавили абзац об этом.
     
     
  • 6.19, Crazy Alex (ok), 22:30, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Стоп, всё равно непонятно. Ну ладно, произошла ошибка, зачем дальше позволять что-то в этот файл писать? Ну отбивать последующие write() с -1, да и всё...

    Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то осмысленно обрабатывать, тем более если это самый частый случай. В общем, правильно сказали - mess и есть.

     
     
  • 7.21, пох (?), 22:40, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Не говоря о том, что ситуацию "из под фс выдернули носитель" не худо бы отслеживать и как-то
    > осмысленно обрабатывать,

    freebsd по сей день очень "осмысленно" наворачивается в kernel panic.
    У линукса чуть лучше - навсегда блокируется точка монтирования и та неудачливая fs которой оно принадлежало.

    Вот ЭТО сделать "как в винде" - то есть вывести юзеру сообщение "верни, козлина, флэшку на место, я ж еще не дописала" и таки попытаться дописать если вернет - с 1995го года нерешаемая задача, совершенно вот ну никак невозможно ее решить по тыщеодной причине, причина первая - не было пороха.

    Ну ничего, зато щас запилим очередной "асинхронный инит", это как-то проще получается.

     
     
  • 8.22, анонн (?), 22:53, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > freebsd по сей день очень "осмысленно" наворачивается в kernel panic.

    Пользуюсь флешками, киндлом, внешними хардами, подключаю телефон через usb, далеко не всегда не забываю отмонтировать. За последние 7 лет припоминаю ровно 0 паник. Странно.

     
     
  • 9.26, пох (?), 00:19, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    пару лет назад у slw@ стабильно воспроизводилось банальным отключением виртуальной "дискеты" bhyve'ом

    сомнительно чтобы с тех пор стало что-то сильно лучше.

     
     
  • 10.33, анонн (?), 01:48, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Есть архив подписки на stable за последние 4 год, с кучей репортов от slw багр... текст скрыт, показать
     
     
  • 11.45, пох (?), 07:58, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    о, форма осталась в хистори Попробуем так Хотя впопеннет в очередной раз подтв... текст скрыт, показать
     
     
  • 12.81, Аноним (79), 11:16, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы не накуралесить.

    В FreeBSD это notabug, тогда с какой целью перезапуск?

     
     
  • 13.82, пох (?), 12:16, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В оффтопике подобная ситуация называется багчек. Система дальше не работает, что бы
    > не накуралесить.

    э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системой - и чего делать-то будем?
    > В FreeBSD это notabug, тогда с какой целью перезапуск?

    kern.panic_reboot_wait_time=-1 и будет "как в винде".

    а дальше чо? Орать "люююди, помогите кто-нибудь"? Ну вот один, как видишь, орал - так к нему кровосос из соседнего болота вылез, щупальцами облизался и спрашивает - "ну я услышал, notabug, легче стало?" Еще и велел орать тише, а не то!

    Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.
    (не в смысле все сломал, а в смысле - кроме него чинить просто некому вообще.)

     
     
  • 14.86, Аноним (86), 16:04, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > э... и вот стоишь ты такой весь красивый перед неработающей-чтоб системой

    О том и вопрос: а чей-та она не работает, нотабаг же?

    > Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs.

    Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.

     
     
  • 15.88, пох (?), 20:20, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > О том и вопрос: а чей-та она не работает, нотабаг же?

    так она работает - вон, отлично перезагружается. А хочешь какой другой работы - удали нафиг этот сторадж, создай новый - и все отлично дальше поедет. Какие еще данные, зачем они тебе были нужны?

    > Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.

    это болгенос, что-ле? Так-то обычно чтобы вышло что-нибудь работающее, и пары тысяч не хватает. Откуда, собственно, и растет проблема.

     
     
  • 16.89, Аноним (86), 08:37, 17/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Тю. Тут ОС целиком исключительно _один_ человек разрабатывает полностью автономно.
    > это болгенос, что-ле?

    БолгенОС всего лишь принципиально новый софт. В Роза Ентерпрайз Десктоп новизна в этом плане отсутствует. Былые идеи развиты до исключительной автономии, как указано в реестре. Осталось дождаться, пока аутсорсер Билл получит гражданство РФ и подпишет загрузчик.

     
  • 14.101, Anon Y Mous (?), 19:01, 21/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если кто не понял - во freebsd _три_, прописью - три активных коммитера в zfs. Этот - один из.

    Да хоть бы и ни одного не было. Оффсет, который zfs_blkptr_verify() сочла неправильным - это 72057594038013952 или 0x100000000015000, что выглядит как bitflip.

     
     
  • 15.102, пох (?), 14:27, 22/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну и чего теперь - владельцу сдохшего стора легче станет?

    P.S. было б ниодного - мы бы хоть те патчи, что уже есть, пропихнули. Но там не принято коммитить через голову активно-копипастящего.

     
  • 9.47, Анонимный прохожий (?), 09:40, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > За последние 7 лет припоминаю ровно 0 паник. Странно.

    Брат, Аноним, ты явно делаешь что-то не так. :-)

     
  • 8.25, universite (ok), 00:11, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/

    >freebsd по сей день очень "осмысленно" наворачивается в kernel panic.

    Будьте добры привести PR.

     
  • 8.36, Crazy Alex (ok), 05:53, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не надо "как в винде" (100500 руганей юзеру). Наоборот - надо уметь поймать, что устройства нет, отдавать какой-то осмысленный код ошибки приложениям, пытающимся что-то сделать с соответствующей фс и по тому же umount -f таки отмонтировать, а в контексте данной траблы - не убивать буферы, если устройство не исчезло.
     
     
  • 9.38, Аноним (38), 06:43, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вы вообще то об одном и том же говорите. "Ругань юзеру" окошко - это и есть приложение, которое получает осмысленный код ошибки.

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

    По сути, в линуксе бесит, что mount -f не работает часто. Накой черт он нужен тогда, или сделали бы как у гита, -f -f лол

     
     
  • 10.42, пох (?), 07:52, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    не, у винды той которая еще 95 окошко было системное точнее не окошко, а свит... текст скрыт, показать
     
  • 2.12, rshadow (ok), 21:43, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://postgrespro.ru/docs/postgrespro/10/wal-configuration
    Смотри чекпоинты
     
  • 2.50, Andrey Mitrofanov (?), 10:22, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну, при проблемах с диском лучше сразу умереть - это логично. Но
    > интересно, какова мотивация сброса буферов? Кто-нибудь в курсе?

    В наука-и-жизни ж писали.  На LWN-е то есть.

    Они все _делают вид_, что в курсе.  И каждый талдычит своё.

    Непросвященным мирянам не понять.

     
  • 1.6, Аноним (6), 20:59, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    для тех, кто держит реплики + с отставанием для защиты от дропов - это не важно
     
     
  • 2.68, Аноним (68), 02:37, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Диск может сбойнуть и на реплике, а из-за неспособности linux гарантировать fsync ваша реплика запишет на диск одно, а прочитает — другое. Получите потерю данных после promote на эту реплику.
     
  • 1.10, Аноним (10), 21:36, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я одно не понял - а что предписывает fsync делать POSIX?
     
     
  • 2.13, Аноним (13), 21:46, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Реализация на усмотрение разработчиков ОС.

    https://www.opennet.ru/man.shtml?topic=fsync&russian=5

    "If the fsync() function fails, outstanding I/O operations are not guaranteed to have been completed."  

     
     
  • 3.14, Аноним (10), 21:54, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо!

    А попадания в буфер (очередь?) входит в эти "I/O operations"?

     
  • 3.18, Аноним (15), 22:22, 14/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Кажется, пора им этот пункт пересмотреть
     
     
  • 4.53, Andrey Mitrofanov (?), 10:31, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кажется, пора им этот пункт пересмотреть

    [I]"" Пора прекратить этот разврат! -- и откопали позикс. ""

     
  • 1.23, sdog (ok), 23:10, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    ребята из саппорта vmware рассказали что когда стали использовать постгрес для замены mssql то были очень удивлены "надёжностью" постгреса на линуксе, что mssql в ситуациях всяческих крэшей был надёжнее, со временем ситуация улучшилась, и сейчас врод бы как паритет, но вот, такой факт.
     
     
  • 2.69, Аноним (68), 02:42, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Эти ребята видимо режим надёжного хранения отключали, для скорости.
     
  • 1.24, nobodynoone (?), 23:23, 14/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Всё гораздо хуже. Это не неправильное использование, а напрочь сломанный *sync().

    В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны. (теперь-то Постгрес запаникует, речь про раньше)

    В глобальном контексте, касается любого приложения: делаете 'sync' в шелле и... См. выше, ситуация аналогична.

    https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Q

     
     
  • 2.29, пох (?), 00:25, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    как мне в свое время объяснял ank: 1. нельзя верить манам - их пишут не те кто писали код 2. если какое-то поведение не описано жестко в позиксе - значит, функция может вернуть что угодно, даже если не написано что она вообще что-то возвращает - достаточно и того что она не void 3. если у функции явно описаны возвращаемые коды ошибок, она может вернуть любой другой

    как хотите, так и программируйте под ваш "новый стандарт".

    это, надо понимать, какой-нибудь 99й или еще раньше.

    P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.

     
     
  • 3.32, Bx (ok), 00:31, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.

    Хе-хе-хе. Впрочем, "пох".

     
     
  • 4.54, Andrey Mitrofanov (?), 10:34, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>еще подлежит восстановлению - тот лох педальный.
    > Хе-хе-хе. Впрочем, "пох".

    [I]Педальный!?

     
     
  • 5.75, Bx (ok), 03:30, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>>еще подлежит восстановлению - тот лох педальный.
    >> Хе-хе-хе. Впрочем, "пох".
    > [I]Педальный!?

    Пардон? Лох или Пох?
    Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync один раз видел, база жива. Вот если бы wal помер, было бы интереснее.

     
     
  • 6.84, пох (?), 12:26, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Раскрою мыслю(голодный трезвого не разумеет :) ), проблему с pg + fsync
    > один раз видел, база жива. Вот если бы wal помер, было
    > бы интереснее.

    ну а где подробности? В смысле - как ты дошел до жизни такой, что fsync отправил данные в /dev/null, и зачем еще потом пользуешься такой базой поверх такого стора?

     
  • 3.73, _ (??), 03:18, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.

    А ты точно читал что там в талмудах про iSCSI написано?!?!?
    Впрочем - пох! Причём педальный :-)))))


     
     
  • 4.83, пох (?), 12:24, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>>>P.S. с другой стороны - у тебя на ходу отвалился диск под базой. А потом еще и почему-то обратно привалился. Кто при этом думает, что база еще подлежит восстановлению - тот лох педальный.
    > А ты точно читал что там в талмудах про iSCSI написано?!?!?

    авторы большинства fs - точно не читали (их отчасти извиняет то, что это дерьмо придумано позже), поэтому буферы выбрасываются в унитаз, система гордо встает раком, а одна здорово распиаренная - вообще после этого начинает циклично перезагружаться, и хранилка восстановлению не подлежит, как мы недавно с изумлением узнали.

    > Впрочем - пох! Причём педальный :-)))))

    не, лох кто в 19м году использует iscsi вместо san, да еще и не имеет бэкапов, желательно вообще на другом типе стораджа.
    Если совсем нет денег - используйте aoe (раз их совсем нет, у вас явно все в пределах соседней стойки уместилось, оно в такой ситуации вполне живо), не выпендривайтесь.

     
  • 2.31, Bx (ok), 00:30, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ага, треды спасут :) Начнем с вопроса "а какие процессы в пг пишут на диск?".
     
     
  • 3.62, nobodynoone (?), 12:25, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не спасут.
     
  • 2.34, YetAnotherAnon (?), 02:40, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В контексте Постгреса: он использует процессы, а не треды. Один из процессов делает fsync(), заботясь только о своём сете данных. Упс, другой процесс уже не увидит ошибки от вызова fsync() со своей стороны.

    Функция fsync() (https://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html) вызывается с конкретным файловым дескриптором, и просит ОС сбросить буферы только для него одного, так что всё что Вы написали про проблемы процессов PostgreSQL - это сугубо Ваши измышления и демонстрация Вашего же непонимания.

    > В глобальном контексте, касается любого приложения: делаете 'sync' в шелле и... См. выше, ситуация аналогична.

    Не стоит путать функцию fsync() с одноимённой утилитой. Хотя, похоже, про то что утилита имеет  параметры, Вы не знаете.

     
     
  • 3.37, Crazy Alex (ok), 05:56, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не. Вот (по ссылке из новости же) детальнее: https://lwn.net/Articles/752063/
     
  • 3.61, nobodynoone (?), 12:24, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тред читай по приведённой мной ссылке. Измышления у меня какие-то.
     
  • 1.28, Bx (ok), 00:22, 15/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Хз, в общем, опасность (по личному опыту) преувеличена. Лично видел. БД не пострадала(хз, обычно wal отдельно!). Кейс с tablespace не рассматривался, вроде, еще наступят.
     
  • 1.39, Аноним (38), 06:50, 15/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > В случае когда ядро Linux не может записать данные, например из-за сбоя буферизированного ввода/вывода вследствие аппаратной ошибки, некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов.

    что значит это предложение? "некоторые операционные системы" - это что?

     
     
  • 2.55, Andrey Mitrofanov (?), 10:39, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> В случае когда ядро
    >>>например из-за
    >>>>некоторые операционные системы
    >>>>>содержимое ожидающих
    > что значит это
    >- это что?

    Драма ж. Беллетристика. сАспенс. Журнализм.  </but stay tuned></dontouch that dial>

     
  • 2.64, нах (?), 12:51, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > что значит это предложение? "некоторые операционные системы" - это что?

    это что разработчики линукса начали отмазываться в стиле "а вон у netbsd вообще до сих пор негр дохлый висит, а у openbsd еще и каждый день -  новый"

    и тут до разработчиков постгреза (которые как раз категорически против "новых стандартов" и по сей день как-то неуклюже пытаются сохранить юникс-совместимость) начало потихоньку доходить... ;-)


     
  • 1.51, Аноним (38), 10:24, 15/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > некоторые операционные системы возвращают код ошибки в fsync() и очищают содержимое ожидающих записи буферов

    Т.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?

     
     
  • 2.56, Аноним (13), 10:42, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Т.е. я правильно понимаю, это упомянутые операционные системы Linux, OpenBSD, NetBSD? А
    > почему стесняетесь прямо сказать, стыдно? Что за "некоторые"?

    Потому что они перечислены рядом в тексте новости. Незачем по нескольку раз одно и тоже копировать.

     
  • 2.65, нах (?), 12:53, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    просто это не означает что список - исчерпывающий, вероятнее всего, к нему можно добавить еще много интересного.

     
     
  • 3.74, _ (??), 03:22, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А что ещё (хоть как то)живого осталось?
    AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...
    Ну то есть "описано : неизвестно" = 4 : 4  ... :)
     
     
  • 4.85, пох (?), 12:30, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А что ещё (хоть как то)живого осталось?
    > AIX, Solaris и Форточка ... а ну голубятня же ещё. Всио ...

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

    Как у вас (ты ж, вроде, в .ca? ) со спросом на выгул собак, догситтинг, вот это вот всьо? В рай (по версии вашего премьера) при таком занятии, конечно, не возьмут, но и вляпаешься разьве что в легкоотмываемую какашку, а не в этот ваш мир занимательного софта.

    и, заметь, нашествие скайнета и автоуправление искусственной идиотией этому бизнесу ни разу не угрожает.

     
     
  • 5.93, bOOster (ok), 17:07, 18/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что за "Древние стандарты"?
    Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует что софт соберется практически везде.
    В отличие от "толпы отморозков" которые его выпилить пытаются не удосужившись даже изучить.
     
     
  • 6.95, пох (?), 13:31, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что за "Древние стандарты"?
    > Есть Posix, который умные люди расширяют, стандартизированно дорабатывают, и который гарантирует

    позикс уже тоже дорасширяли до полной невменяемости.

    > что софт соберется практически везде.

    такой сложный и ресурсожручий софт как postgres недостаточно собрать - он еще и работать после этого должен. А они только-только стали задумываться, что sysV ipc уже нигде толком немодно, да и с модными антипатчами типа kpti немодная многопроцессная вместо мультитредовой модель плохо совместима.

     
  • 1.63, J.L. (?), 12:32, 15/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.

    это ваще как?? кто-нить может объяснить что имелось в виду в этой строке?

     
     
  • 2.66, Andrey Mitrofanov (?), 12:59, 15/02/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Например, если ошибка ввода/вывода возникла до открытия файла, то fsync() завершится успешно.
    > это ваще как?? кто-нить может объяснить что имелось в виду в этой
    > строке?

    Robert Haas делает вид, что может.  См. LWN и не морочьте нам голову, мы обсуждаем в новости и в дрвму.

     
  • 2.70, Аноним (68), 02:58, 16/02/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    1. в приложении: открыли, записали, закрыли (данные в кеше ФС)

    2. в консоли вызвали /bin/sync, получили ошибку

    3. в приложении: открыли тот же файл, вызвали fsync(), linux возвращает 0, "всё записал", хотя данные из кеша всё ещё не записаны

     
  • 1.94, Аноним (94), 12:05, 19/02/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть ли у них интерфейс к данным мимо SQL, типа, как это у BerkeleyDB?
     
     
  • 2.96, adolfus (ok), 13:51, 19/02/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наверняка есть -- на что-то же должен этот SQL опираться.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor