Мало того что сравнение колоночная vs классическая, так ещё и с отключенным журналом транзакций, т.е. ACID vs non-ACID. Аж двойная бессмыслица. В противники тут Кликхаус бы подошёл. А так это как взять кота и голубя, подбросить их, и написать статью что одно летает лучше другого. Оно и так понятно.
При синхронной репликации Latency сети напрямую влияет на скорость транзакций: каждый Commit ждет подтверждения от реплики. Нужно заранее понимать, какая задержка допустима, и выбирать между синхронной и асинхронной репликацией осознанно
Ну и чего делать будете если нужна именно синхронная реплика для отказоустойчивости, а отлик не устраивает? А при более-менее серьезной нагрузке и нахождении её в другом ЦОДе он скорей всего не устроит, уж поверьте.
Этап 3. Отказоустойчивость
Что делаем на этом этапе:
настраиваем Streaming Replication между мастером и репликой;
разворачиваем систему автоматического Failover: Patroni, repmgr или аналог;
Ничего не понял... какой вы там Streaming Replication руками настраиваете, если вы следом ставите patroni/repmgr? Это вообще-то их прямая обязанность. Вообще, на моём опыте, патрони и уже настроеные руками кластера "подцеплял" успешно при запуске службы (без дт бекендов пг), но тут описан сценарий первоначального запуска. Тут возникают сомнения что автор вообще понимает что пишет.
Split-brain — ситуация, когда два узла одновременно считают себя мастером и принимают записи. Как это происходит: сеть между ЦОДами прерывается, каждая сторона считает, что другая недоступна. Patroni на каждой стороне решает: «Мастер умер, я беру на себя». Теперь у вас два мастера, и приложения пишут в оба.
ЧЕГО-ЧЕГО? Это каким образом патрони может так решить? Дайте хоть один пример: статью, пост, issue мож на гитхабе есть где такое у кого-то возникло? Патрони никогда не запромоутит реплику при обрыве связи с кластером и DCS, ни автоматически ни руками ты этого не сделаешь. Даже при опции failsafe_mode: true, патрони максимум оставит ТЕКУЩИЙ мастер работать. На этом моменте уже точно понятно что у автора околонулевой опыт реальной эксплуатации и траблшутинга кластеров с patroni.
настраиваем регулярные полные бэкапы через pg_basebackup; автоматизируем все через pgBackRest или Barman;
Опять же, если вы использует barman/pgbackrest и прочее, что вы там с pg_basebackup "настраиваете" ручками? barman под капотом сам вызывает его когда надо.
настраиваем механизм переключения клиентов: VIP (виртуальный IP), DNS-based Failover или интеграция с Load Balancer;
Это всё хорошо, но простой способ не упомянут: прописывание через запятую бекендов в connection string jbdc драйвера (он давно такое умеет). Сервисы обеспечивающие VIP это, к сожалению, ещё одна точка отказа.
Бэкап базы в 500 ГБ восстанавливается несколько часов.
Как категорично, скорость сетевых интерфейсов, дисков и прочие факторы в расчет не берем, ага. Если я скажу что я базу 10ТБ восстанавливал за 4 часа, не поверите?
pgAudit позволяет логировать все операции с данными: SELECT, INSERT, UPDATE, DELETE
Это позволяет родной для pg параметр log_statement = 'mod'. pgAudit для куда более сложных вещей.
В росреестре нет ванильного PG, там PGPro и Аренадата. И он набирает обороты не только в РФ последние годы, и абсолютно заслужено. Пусть там нет навороченности Оракла, для 95%+ сервисов его функционала хватает за глаза.
«А не лучше ли нам расстаться?» - А сходиться с кем будете? У вас выбор софта ограничен лицензией ФСТЭК. Там все продукты такие написанные на коленке за попилы под горячую темку "импортозамещения".
"а с доступом к экземплярам PostgreSQL не так просто — нужно устанавливать новые соединения ко всем экземплярам, а для этого открывать сетевые порты и управлять конфигами pg_hba.conf, прописав в них IP‑адреса серверов мониторинга, да и передавать данные по сети в открытом виде нехорошо, а для SSL тоже нужны отдельные настройки."
Ужасы то какие, оказывается СУБД надо администрировать. Прочитав про "решение" вашей проблемы только один вопрос в голове возникает - а стандартную практику воткнуть пулер поверх субд не рассматривали? слишком скучно и не велосипедно видимо :)
На госпроектах всем чихать на качество продукта, конкуренция отсутствует, никто сравнивать это убожество полученное на выходе с реальными коммерческими проектами не будет. Главное бюджет растащить, исполнение доверят вчерашнему студенту со сверхсжатыми сроками, который только вкотился войти и "работает на опыт".
Мало того что сравнение колоночная vs классическая, так ещё и с отключенным журналом транзакций, т.е. ACID vs non-ACID. Аж двойная бессмыслица. В противники тут Кликхаус бы подошёл. А так это как взять кота и голубя, подбросить их, и написать статью что одно летает лучше другого. Оно и так понятно.
Ужас. Даже не знаю с чего начать коментировать.
Ну и чего делать будете если нужна именно синхронная реплика для отказоустойчивости, а отлик не устраивает? А при более-менее серьезной нагрузке и нахождении её в другом ЦОДе он скорей всего не устроит, уж поверьте.
Ничего не понял... какой вы там Streaming Replication руками настраиваете, если вы следом ставите patroni/repmgr? Это вообще-то их прямая обязанность. Вообще, на моём опыте, патрони и уже настроеные руками кластера "подцеплял" успешно при запуске службы (без дт бекендов пг), но тут описан сценарий первоначального запуска. Тут возникают сомнения что автор вообще понимает что пишет.
ЧЕГО-ЧЕГО? Это каким образом патрони может так решить? Дайте хоть один пример: статью, пост, issue мож на гитхабе есть где такое у кого-то возникло? Патрони никогда не запромоутит реплику при обрыве связи с кластером и DCS, ни автоматически ни руками ты этого не сделаешь. Даже при опции failsafe_mode: true, патрони максимум оставит ТЕКУЩИЙ мастер работать. На этом моменте уже точно понятно что у автора околонулевой опыт реальной эксплуатации и траблшутинга кластеров с patroni.
Опять же, если вы использует barman/pgbackrest и прочее, что вы там с pg_basebackup "настраиваете" ручками? barman под капотом сам вызывает его когда надо.
Это всё хорошо, но простой способ не упомянут: прописывание через запятую бекендов в connection string jbdc драйвера (он давно такое умеет). Сервисы обеспечивающие VIP это, к сожалению, ещё одна точка отказа.
Как категорично, скорость сетевых интерфейсов, дисков и прочие факторы в расчет не берем, ага. Если я скажу что я базу 10ТБ восстанавливал за 4 часа, не поверите?
Это позволяет родной для pg параметр log_statement = 'mod'. pgAudit для куда более сложных вещей.
Полезность статьи со знаком минус.
В росреестре нет ванильного PG, там PGPro и Аренадата. И он набирает обороты не только в РФ последние годы, и абсолютно заслужено. Пусть там нет навороченности Оракла, для 95%+ сервисов его функционала хватает за глаза.
«А не лучше ли нам расстаться?» - А сходиться с кем будете? У вас выбор софта ограничен лицензией ФСТЭК. Там все продукты такие написанные на коленке за попилы под горячую темку "импортозамещения".
"а с доступом к экземплярам PostgreSQL не так просто — нужно устанавливать новые соединения ко всем экземплярам, а для этого открывать сетевые порты и управлять конфигами pg_hba.conf, прописав в них IP‑адреса серверов мониторинга, да и передавать данные по сети в открытом виде нехорошо, а для SSL тоже нужны отдельные настройки."
Ужасы то какие, оказывается СУБД надо администрировать. Прочитав про "решение" вашей проблемы только один вопрос в голове возникает - а стандартную практику воткнуть пулер поверх субд не рассматривали? слишком скучно и не велосипедно видимо :)
'Непонимание и невычитывание команд, выдаваемых ИИ — это бич современной разработки. В прод идёт всё, неважно, как оно написано."
Замените 'выдаваемых ии' на 'выдаваемых стэковерфлоу' и твоё утверждение верно и для прошлых времен. Может дело все таки в конкретных "погромистах"?
Почему именно логическую?
На госпроектах всем чихать на качество продукта, конкуренция отсутствует, никто сравнивать это убожество полученное на выходе с реальными коммерческими проектами не будет. Главное бюджет растащить, исполнение доверят вчерашнему студенту со сверхсжатыми сроками, который только вкотился войти и "работает на опыт".