До девятой версии в PostgreSQL для создания «теплого» резервного сервера использовался WAL archiving. В версии 9.0 появилась потоковая репликация с возможностью создания «горячего» read-only сервера. В следующей версии PostgreSQL 9.4 появится новый функционал для создания потоковой репликации под названием replication slots.
Введение в PostgreSQL BDR
7 min
Введение в PostgreSQL BDR
PostgreSQL это не только стабильная и надежная СУБД но и плюс ко всем это динамично развивающийся продукт, в котором от релиза к релизу появляются самые разные прорывные вещи. В свое время одной из таких технологий была потоковая репликация. Это высокопроизводительная репликация которая позволяет очень легко и дешево масштабировать базу данных на чтение. Используя ее можно создавать надежные конфигурации распределяя нагрузку на чтение между узлами. Однако как я написал выше, продукт развивается, и сегодня в статье речь пойдет о новой технологии BDR (Bi-Directional Replication).
Как я реплицировал данные с помощью postgres_fdw и dbt
Medium
5 min
Case
Привет, Хабр!
Хочу рассказать вам о собственном опыте извращенной репликаций данных между базами Postgres)
Моделирование отказоустойчивых кластеров на базе PostgreSQL и Pacemaker
12 min
Введение
Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.
К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).
Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.
Репликации в PostgreSQL
6 min
Сейчас трудно себе представить «боевую» инсталляцию любой серьезной СУБД в виде единственного инстанса. Конечно, некоторые приложения требуют для своей работы использование локальных баз данных, но если мы говорим о сетевом многопользовательском режиме работы, то здесь использование только одной инсталляции это очень плохая идея.
Основной проблемой единственной инсталляции естественно является надежность. В случае падения сервера нам потребуется некоторое, возможно значительное, время на восстановление. Так восстановление террабайтной базы может занять несколько часов.
Да и исправный бэкап есть не всегда, но об этом мы уже говорили в предыдущей статье.