Комментарии 9
НЛО прилетело и опубликовало эту надпись здесь
Ещё в минус — есть некоторые проблемы с выполнением функций, результат которых может быть разный на разных нодах. Например, now() будет выполнена на «мастере» (условно) — на одном из серверов, а вот на каком именно из нескольких? Функция, которая возвращает случайное значение, будет выполнена на обоих, или на каком-то одном (надо поместить её в белый список, не помню как называется). А если сомнительных функций тысячи?
А с возвращением ноды особых проблем как раз и нет, мне кажется. pg_basebackup и всё.
А с возвращением ноды особых проблем как раз и нет, мне кажется. pg_basebackup и всё.
А почему вы считаете, что применить запрос, модифицирующий данные, на 2 машины дешевле с точки зрения нагрузки, чем накатить изменения из WAL? Ведь в WAL уже готовый результат по сути, а исходный запрос надо распарсить, применить, записать собственно результат в WAL и только потом закоммитить в файл с данными. Слейв, соответственно, не делает бОльшую часть работы, только применяет изменения из WAL.
Отдельный вопрос в вашей схеме — консистентность реплик при конкурентных запросах на изменение данных. Кто гарантирует, что транзакции на двух машинах будут применены в одинаковом порядке?
Отдельный вопрос в вашей схеме — консистентность реплик при конкурентных запросах на изменение данных. Кто гарантирует, что транзакции на двух машинах будут применены в одинаковом порядке?
Было дело пару лет назад… не пуля.
Да, не дешевле, время отклика растет из-за синхронизации.
Консистентность есть, ибо синхронность проверяется. Но динамические значения типа рандов — беда. И чуть что — кластер деградировал в 1 ноду.
Интересно для чтения — селекты распределяются по нодам равномерно, а точка входа для приложения одна.
Да, не дешевле, время отклика растет из-за синхронизации.
Консистентность есть, ибо синхронность проверяется. Но динамические значения типа рандов — беда. И чуть что — кластер деградировал в 1 ноду.
Интересно для чтения — селекты распределяются по нодам равномерно, а точка входа для приложения одна.
Точка входа одна — значит если она ляжет, то все? Эх, лучше всего, кмк, это реализовано в кассандре, любая нода может быть точкой входа…
Картинка как бы намекает… В статье не рассматривась установка двух PGpool перекрестно, равно как и Кассандра.
Всё верно — изначально архитектура предполагала наличие второго Pgpool, они работали перекрестно и это было настроено, судя по разделу «WatchDog», где виртуальный IP-бегает между двумя Pgpool. Затем при тестировании Online Recovery, я убрал второй Pgpool из-за предостережения, которое нашел в мануале: «Note that there is a restriction about online recovery. If pgpool-II itself is installed on multiple hosts, online recovery does not work correctly, because pgpool-II has to stop all clients during the 2nd stage of online recovery. If there are several pgpool hosts, only one will have received the online recovery command and will block connections.»
Изначально была задача разобраться в решениях по отказоустойчивости в PostgreSQL. Сначала настроил Stream + Pgpool — чаще всего такая архитектура встречается в Интернете. Здесь тебе и select-ы на все ноды, но запись в одно место. Но потом захотелось попробовать писать сразу везде (некий мультимастер). И как оказалось, это мало кто использует, видимо как раз потому, что доверяют больше внутренним механизмам, это видимо и есть mainstream. Просто когда у тебя много транзакций в базе, генерация wal просто сумасшедшая, но это получается дешевле чем проигрывать в потере SQL-запросов (цитата от О.Бартунова) Захотелось раскурить pgpool — настроить его можно, поддерживать можно, но вот если одна из нод останавливается (при этом система продолжит, конечно, работать)по любой причине начинаются танцы с бубном.
Какие у Вас архитектуры по отказоустойчиовсти? pgBouncer + Stream?
Какие у Вас архитектуры по отказоустойчиовсти? pgBouncer + Stream?
Зачем делать реплику pgpool'ом при наличии 9.3+? Год назад описывал про настройку подобной связки для AWS. Связка рабочая, синхронную репликацию не использую.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL 9.3 + Pgpool-II