Pull to refresh

Comments 16

Действительно очень полезная фича. Если будет работать стабильно и прозрачно(понятное и четко описание поведение при различные ситуациях), то это очень классная вещь. PoostgreSQL действительно радует.

Активно пользуемся этой БД уже более 7 лет. Надо сказать, за это время с базой проблеме вообще не было. Все очень стабильно и надежно.
Какие объёмы и нагрузка, если не секрет?
Ну вот мы работаем лет 10 с PostgreSQL.
Объемы в разных конфигурациях от 10Гб до 600Гб на один кластер баз данных и таких несколько десятков…
Нагрузка от десятка то нескольких сотен активных подключений 20% которых пишущие.
Нам очень нравится, особых проблем за это время не испытывали…
Единственно — были заморочки, когда места на серверах заканчивались под базу во время большого количества транзакций… тогда рушились некоторые страницы в больших постоянно обновляемых табличках.
Интересно, расскажут ли об этом на грядущей PG Day?…
Крайне скептически отношусь к мультимастер репликации… Особенно. когда к этому добавляют «географически распределенные». Но надеюсь что у разработчиков получится сделать элегантное решение.
Как планируют разруливать конфликты и бороться со сплитбрейном?
Я так понял что конфликты разрешаются на основе временных меток транзакций, кроме того можно определять свои обработчики конфликтов (страничка в вики). Про split-brain самому интересно, но увы официальной позиции разработчиков по этому вопросу я не нашел.
UFO just landed and posted this here
да, проект еще не достаточно mature поэтому многое еще может и будет меняться.
Как считаете, для Production окружения можно использовать BDR (ведь PostgreSQL 9.5 уже не за горами) или всё же лучше пока остановится скажем на pgPool-II?
Для production окружения использовать BDR не стоит. Лучше использовать проверенные временем решения как pgpool.
Я так понял, несмотря на позитивные прогнозы, в ядро 9.5 BDR не добавили?
Имеется два географически разнесённых автономных кластера Postgresql-XL. Есть необходимость между ними сделать асинхронную репликацию. При этом клиенты только читают и ходят каждый на свой XL. Тот агент, который пишет — только один и он пишет данные в оба кластера с учётом асинхронной репликации данных. Подскажите, пожалуйста, целесообразно ли для целей репликации использовать PostgreSQL BDR в таком случае? И возможно ли это вообще?
Извините, не удержусь от того, чтобы ответить вопросом на вопрос. Для вас Postgres-XL – это теоретическая возможность или вы его уже используете в продакшене? Если да, то какую версию?
Весь проект находится на стадии разработки архитектуры. Тестируем на виртуалках XL9_5_STABLE. Пока нареканий нет. От всех синтетических тестов получаем предсказуемый и полностью удовлетворительный результат. В продакшн планируем именно такую связку:
XL <---BDR-->XL но с окончательным решением определились только к XL.
Sign up to leave a comment.

Articles