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