Комментарии 16
Действительно очень полезная фича. Если будет работать стабильно и прозрачно(понятное и четко описание поведение при различные ситуациях), то это очень классная вещь. PoostgreSQL действительно радует.
Активно пользуемся этой БД уже более 7 лет. Надо сказать, за это время с базой проблеме вообще не было. Все очень стабильно и надежно.
Активно пользуемся этой БД уже более 7 лет. Надо сказать, за это время с базой проблеме вообще не было. Все очень стабильно и надежно.
+2
Какие объёмы и нагрузка, если не секрет?
0
Ну вот мы работаем лет 10 с PostgreSQL.
Объемы в разных конфигурациях от 10Гб до 600Гб на один кластер баз данных и таких несколько десятков…
Нагрузка от десятка то нескольких сотен активных подключений 20% которых пишущие.
Нам очень нравится, особых проблем за это время не испытывали…
Единственно — были заморочки, когда места на серверах заканчивались под базу во время большого количества транзакций… тогда рушились некоторые страницы в больших постоянно обновляемых табличках.
Объемы в разных конфигурациях от 10Гб до 600Гб на один кластер баз данных и таких несколько десятков…
Нагрузка от десятка то нескольких сотен активных подключений 20% которых пишущие.
Нам очень нравится, особых проблем за это время не испытывали…
Единственно — были заморочки, когда места на серверах заканчивались под базу во время большого количества транзакций… тогда рушились некоторые страницы в больших постоянно обновляемых табличках.
0
Крайне скептически отношусь к мультимастер репликации… Особенно. когда к этому добавляют «географически распределенные». Но надеюсь что у разработчиков получится сделать элегантное решение.
Как планируют разруливать конфликты и бороться со сплитбрейном?
Как планируют разруливать конфликты и бороться со сплитбрейном?
0
Я так понял что конфликты разрешаются на основе временных меток транзакций, кроме того можно определять свои обработчики конфликтов (страничка в вики). Про split-brain самому интересно, но увы официальной позиции разработчиков по этому вопросу я не нашел.
0
НЛО прилетело и опубликовало эту надпись здесь
Как считаете, для 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
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в PostgreSQL BDR