Хорошо конечно без многоверсионности, но современная армия разработчиков настолько привыкла к режиму изоляции Read Committed, что другого ничего и слышать не хочет (не все, есть и любители Repeatable Read). Вот версионнирование и нужно чтобы делать Read Committed/Repeatable Read.
По поводу хранения версий - так без этого никак, надо откуда получать данные из прошлого. В Оракле - это UNDO сегмент, в PostgreSQL - это несколько версий строк.
Vacuum бесспорно вещь неприятная. Но его можно научиться готовить, хотя серебряной пули увы нет.
В PostgresPro Multimaster использует 3PC (ещё одна фаза добавляется из-за RAFT-а).
И да: в этом случаи будет распределенный deadlock, поскольку при коммитах транзакций (а они обе дойдут беспрепятственно до коммита) изменения попробуют зареплицироваться между нодами и поймают блокировки. И тогда сработает deadlock detector. Но можно deadlock-а избежать через параметр multimaster.deadlock_prevention : https://postgrespro.ru/docs/enterprise/13/multimaster#MTM-DEADLOCK-PREVENTION . Это быстрее работает чем ожидание дедлока и его разрешение.
Другими словами в итоге либо будет 1 COMMIT+1ROLLBACK или 2 ROLLBACK-а
Понимаю эту боль. Когда всё разъехалось - это адовая боль.
Но если получится сломать PostgresPro Multimaster (виртуалка с ним выше доступна в самой статье), то прошу дать знать. Не говорю, что это сделать нельзя, но заложенный 3PC в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.
На Slave-е можно только читать. Там нельзя создать даже временной таблицы. А иногда хочется создать временные таблицы при формировании временного отчёт.
Моё личное ощущение что мультимастер прекрасен свой отказоустойчивостью:
Не надо думать где реплика а где мастер и городить балансировщики аля HAProxy
Не надо переживать за недоступность сервиса пока реплика будет превращаться в мастер при failover/switchover
Не надо думать в каком порядке обновлять базы и как обновлять. Особенно с учётом major upgrade
Два события похоже что связаны, но стоит разобраться что это. Обычно в dmesg сваливается информация о краше, одна строчка. На неё бы взглянуть. Наверно лучше в личку :)
Частый DDL для временных таблиц в любом случаи зло. Это и посылка сообщений об инвалидациях (даже fast_truncate посылает инвалидацию) и замусоривание таблиц системного каталога (от этого увы никуда не деться). Стоит отметить что внутри ядра PostgreSQL инвалидации нужны не только для того, чтобы информировать другие подключения, но ещё к примеру откатить изменения системного каталога в текущем процессе при ROLLBACK-е.
ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.
В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.
А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.
А вот реплика - это не совсем безкап ибо она не позволяет восстановиться на точку в прошлом. Если кто-то дропнул таблицу или зашифровал ключевые блоки, то реплика окажется также поломанной.
Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.
Хорошо конечно без многоверсионности, но современная армия разработчиков настолько привыкла к режиму изоляции Read Committed, что другого ничего и слышать не хочет (не все, есть и любители Repeatable Read). Вот версионнирование и нужно чтобы делать Read Committed/Repeatable Read.
Верно, в PostgresPro Multimaster используется PAXOS, не RAFT. Я ошибся в своём комментарии выше.
Репликация синхронная, 2PC накладывает свои расходы. Это как раз описано в третьей части данной серии статей: https://habr.com/ru/companies/postgrespro/articles/793158/
По поводу хранения версий - так без этого никак, надо откуда получать данные из прошлого. В Оракле - это UNDO сегмент, в PostgreSQL - это несколько версий строк.
Vacuum бесспорно вещь неприятная. Но его можно научиться готовить, хотя серебряной пули увы нет.
В PostgresPro Multimaster использует 3PC (ещё одна фаза добавляется из-за RAFT-а).
И да: в этом случаи будет распределенный deadlock, поскольку при коммитах транзакций (а они обе дойдут беспрепятственно до коммита) изменения попробуют зареплицироваться между нодами и поймают блокировки. И тогда сработает deadlock detector. Но можно deadlock-а избежать через параметр
multimaster.deadlock_prevention: https://postgrespro.ru/docs/enterprise/13/multimaster#MTM-DEADLOCK-PREVENTION . Это быстрее работает чем ожидание дедлока и его разрешение.Другими словами в итоге либо будет 1 COMMIT+1ROLLBACK или 2 ROLLBACK-а
Понимаю эту боль. Когда всё разъехалось - это адовая боль.
Но если получится сломать PostgresPro Multimaster (виртуалка с ним выше доступна в самой статье), то прошу дать знать. Не говорю, что это сделать нельзя, но заложенный 3PC в него выглядит пока довольно прочно и в эксплуатации с проблемами к нам не приходили.
На Slave-е можно только читать. Там нельзя создать даже временной таблицы. А иногда хочется создать временные таблицы при формировании временного отчёт.
Моё личное ощущение что мультимастер прекрасен свой отказоустойчивостью:
Не надо думать где реплика а где мастер и городить балансировщики аля HAProxy
Не надо переживать за недоступность сервиса пока реплика будет превращаться в мастер при failover/switchover
Не надо думать в каком порядке обновлять базы и как обновлять. Особенно с учётом major upgrade
del
"Problem sovled!"
Апечатки по Фрейду!
Два события похоже что связаны, но стоит разобраться что это. Обычно в dmesg сваливается информация о краше, одна строчка. На неё бы взглянуть. Наверно лучше в личку :)
Частый DDL для временных таблиц в любом случаи зло. Это и посылка сообщений об инвалидациях (даже fast_truncate посылает инвалидацию) и замусоривание таблиц системного каталога (от этого увы никуда не деться). Стоит отметить что внутри ядра PostgreSQL инвалидации нужны не только для того, чтобы информировать другие подключения, но ещё к примеру откатить изменения системного каталога в текущем процессе при ROLLBACK-е.
Конечно же. Спасибо большое! Текст поправил.
ZFS CoW снепшот атомарен, моментален, не вызывает деградации производительности и не требует больших расходов. Гарантии есть.
В чём плюс такой схемы с ZFS снепшотам, что можно восстановиться на любой момент времени. Выбирается точка во времени, откатывается на снепшот перед точкой, а потом добираются WAL-ы которые лежат в следующем снепшоте. И делается recovery.
А и про бекапы - снепшоты инкрементально отправляются в СРК или на реплику ZFS-а через zfs send/receive. То есть можно держать 100500 снепшотов в СРК, а на мастере хранить за последние сутки.
А вот реплика - это не совсем безкап ибо она не позволяет восстановиться на точку в прошлом. Если кто-то дропнул таблицу или зашифровал ключевые блоки, то реплика окажется также поломанной.
Симптомы бывают одни, а реально болит в совсем другом месте. И да, много проблем решается обновлением того или иного. Но чтобы найти что обновлять (а вариантов тут может быть слишком много включая железо), придётся разобраться в деталях происходящего. На первый взгляд описание тикета ZFS не имеет ничего общего с симптомами в PostgreSQL, а вот как оно вышло.