LINUX.ORG.RU
ФорумAdmin

Какой выбрать кластер PostgreSQL (master-master) ?

 ,


1

5

Здравствуйте уважаемые форумчане. Подскажите пожалуйста, какую технологию лучше выбрать для организации двухнодового кластера PostgreSQL, объединенного и работающего в режиме master-master ?

Ответ на: а вам слабо почитать вики от vadv

Спасибо, не слабо. Но интересуют все-таки мнения и отзывы людей, имеющих конкретный практический опыт организации такой схемы. Но за ссылку пребольшое спасибо!

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)

Не стоит пробовать делать мультимастер на уровне базы данных.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Это почему же? Делают же, и вполне успешно. Есть конечно свои нюансы.

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

Дело в том, что прозрачно для приложения не получится мультимастер, так что проще пилить само приложение

vadv ★★ ()
Ответ на: комментарий от vadv

В каком плане не получиться? Что за ерунда? Что именно не получиться? Сбалансировать соединения? Распределить механизмы чтения/записи? Почему вы так решили?

ChAnton ★★ ()
Последнее исправление: ChAnton (всего исправлений: 1)
Ответ на: комментарий от vadv

Лень проверять, но я думаю ихний драйвер умеет скрывать несколько мастеров за одним клиентским соединением. И, скорее всего, балансировать нагрузку и делать failover.

true_admin ★★★★★ ()
Ответ на: комментарий от ChAnton

Не получиться обеспечить транзакционную целостность. Например в одной транзакции покрыть блокировкой данные на обоих серверах.

Впрочем, если рассматривать базы данных как черные коробочки, то получится чего нет. Только внезапно приложения могут начать работать как то не так.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Не получиться обеспечить транзакционную целостность

ЭЭээ, я так полагаю что речь идёт о синхронном мультимастере потому что асинхронный мультимастер признан вселенским злом. В таком случае проблем никаких, кмк.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Ну и как синхронный мультимастер решает эту проблему? Кто в традиционной архитектуре будет решать конфликт когда локальный update блокирует запись которая в это же время приходит от соседнего мастера? Будет ли тут детерминированное поведение? В случае одного инстанса эта проблема решается блокировками. Для мультимастера нужно серьезно переделывать движок rdbms как это делает postgresql-XC. Вот как раз в нем есть менеджер блокировок. И это только поверхностные проблемы.

ventilator ★★★ ()
Последнее исправление: ventilator (всего исправлений: 1)
Ответ на: комментарий от ventilator

Впрочем вам никто не мешает с помощью двухфазного коммита слать транзакции сразу в две базы, только это будет «несколько не то».

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Кто в традиционной архитектуре будет решать конфликт когда локальный update блокирует запись которая в это же время приходит от соседнего мастера? Будет ли тут детерминированное поведение?

нужно серьезно переделывать движок rdbms как это делает postgresql-XC

в нем есть менеджер блокировок

Ты сам ответил на свой вопрос. Конечно на все узлы запросы должны приходить в одинаковом порядке.

true_admin ★★★★★ ()
Ответ на: комментарий от ChAnton

Было бы все так просто, никто бы не покупал p795, а просто брали бы и запускали мультимастеры с полпинка.

ventilator ★★★ ()
Ответ на: комментарий от true_admin

Ты сам ответил на свой вопрос. Конечно на все узлы запросы должны приходить в одинаковом порядке.

Это вообще как? Суть мультимастера в том что на разные ноды приходят разные запросы. О каком порядке речь?

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Мастер — узел принимающий апдейты/селекты с приложения. Слейв — узел принимающий селекты и накатывает апдейты с мастеров. Мультимастер — наличие нескольких мастеров. Синхронный мультимастер — все апдейты синхронно прилетают на все мастера.

Асинхронный мультимастер — апдейты могут прилетать в произвольном порядке и консистентность не гарантируется. Тут или разруливать коллизии, или быть очень аккуратным с теми запросами что шлёшь.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

Асинхронный мастер работает независимо от доступности других узлов. Синхронный работает синхронно, пока все узлы не подтвердят готовность выполнить запрос/накатить апдейт ничего не будет. Скорость работы на апдейты равна скорости самого слабого звена.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

Наверняка есть механизмы, синхронизирующие порядок записи/реплицирования узлов. Например с отложенной записью/чтения? Или с разделением ролей на запись/чтение.

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

Общая распределённая запись например. Я настаиваю что это возможно потому что, например, гугловая база работает в синхронном режиме, причём синхронно на несколько датацентров: https://developers.google.com/cloud-sql/faq

Апдейты идут в две фазы: сначала получается апрув от всех баз, потом летит апдейт и завершается он когда бОльшинство узлов подтвердило коммит (это я на google io видел).

Да, задержки в разы больше чем при асинхронной работе, но зато если у них сдохнет пара датацентров то никто не заметит.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Вы неправильно читаете синхронный/асинхронный.

Синхронный - успешный коммит транзакции на ноде, означает что все остальные ноды записали изменения блоков которые сделала эта транзакция на диск. Иными словами в любом момент времени все инстансы содержат идентичные данные.

Асинхронный - успешный коммит транзакции на ноде, означает что локальная нода записала изменения блоков которые сделала эта транзакция на диск. Остальные ноды данные могут записать позже.

все апдейты синхронно прилетают на все мастера.

Так лучше не делать, тк апдейт может менять данные на разных нодах по разному (update .. set name=random()...). Я бы сказал вообще что все решения основанные на репликации sql стрима опасны. Гораздо правильнее реплицировать логи транзакций в которых отображаются изменения данных, а не команды sql.

ventilator ★★★ ()
Ответ на: комментарий от true_admin

А что скажете про организацию мультимастера на Pgpool II, вроде как она сейчас позволяет такое изготовить? Даже примеры где-то видел. Правда некоторые люди ссылаются на то, что он якобы «не совсем мастер», что это означает, мне пока непонятно. Есть еще Bucardo, но говорят что он асинхронный.

ChAnton ★★ ()
Ответ на: комментарий от ventilator

Кстати, а Postges умеет реплицирование логов транзакций?

ChAnton ★★ ()
Ответ на: комментарий от true_admin

Апдейты идут в две фазы: сначала получается апрув от всех баз, потом летит апдейт и завершается он когда бОльшинство узлов подтвердило коммит (это я на google io видел).

Это вы описали немного искаженно двухфазный коммит. К слову после первой фазы блокировки держатся до завершения второй. И либо вы используете приложение которое это умеет как говорил vadv либо запиливаете это в движок как делает postgresql-xc.

ventilator ★★★ ()
Ответ на: комментарий от ChAnton

А что скажете про организацию мультимастера на Pgpool II, вроде как она сейчас позволяет такое изготовить? Даже примеры где-то видел. Правда некоторые люди ссылаются на то, что он якобы «не совсем мастер», что это означает, мне пока непонятно.

Работает, юзать не стоит если вы цените свои данные.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Работает, юзать не стоит если вы цените свои данные.

Аргументы? Именно в отношении Pgpool...

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

Кстати, а Postges умеет реплицирование логов транзакций?

Да, именно так там мастер-слейв и сделан. Есть как синхронный, так и асинхронный режим.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

апдейт может менять данные на разных нодах по разному (update .. set name=random()...). Я бы сказал вообще что все решения основанные на репликации sql стрима опасны.

Есть statement based репликация, а есть bin/WAL-log based replication. В первом случае можно всё легко сломать, но, например, в мануале к mysql об этом чётко было сказано (по-моему, от первого вида вообще отказались т.к. переслать результат транзакции дешевле чем грузить все сервера запросами). Впрочём, я вижу что ты в этом сечёшь :). Но я не понимаю почему ты говоришь что это практически невозможно.

true_admin ★★★★★ ()
Ответ на: комментарий от ventilator

Ну приблизительно как в MySQL короче. Но это мастер-слейв. А мне бы нужен именно мастер-мастер.

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

В том режиме работы о котором вы говорите, Pgpool «просто» шлет sql сразу на все ноды. Ситуации типа update .. set name=random() вы должны сами обойти. Если не обойдете - получите разные данные на двух нодах. Легко и просто можно получить проблемы с sequence тоже. Кроме того обслуживать это весьма непросто. Если один из серверов остановится на время, весьма трудоемко его вводить в строй.

ventilator ★★★ ()
Ответ на: комментарий от ChAnton

А что скажете про организацию мультимастера на Pgpool II

ничего, кроме того что постгрес излишне сложен в администрировании. pgpool2 я поднимал только один раз в mastser-slave режими, натрахался с триггерами и процедурами по самое небалуйся. Больше не хочу такого.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Но я не понимаю почему ты говоришь что это практически невозможно.

Я вижу два пути:
а) Для этого нужно серьезно переделать движок, как делает postgresql-XC или mysql ndb cluster(врагу не пожелаю столкнуться с этим говном),Oracle RAC(немного не в ту степь но все же). Все переделки обеспечивают совместимость только до определенного уровня. И добавляют некоторые проблемы.

б) Приложение должно быть написано чтобы работать с несколькими базами. Часто бывает что выгоднее масштабироваться покупкой p795 чем это делать.

Пути с несвязанными базами, которые реплицируют по кругу что либо - не дадут гарантии целостности данных. Вы можете уточнить вопрос на sql.ru и там вам дадут идентичный ответ.

ventilator ★★★ ()
Последнее исправление: ventilator (всего исправлений: 1)
Ответ на: комментарий от ventilator

В том режиме работы о котором вы говорите, Pgpool «просто» шлет >sql сразу на все ноды. Ситуации типа update .. set >name=random() вы должны сами обойти. Если не обойдете - >получите разные данные на двух нодах. Легко и просто можно >получить проблемы с sequence тоже. Кроме того обслуживать это >весьма непросто. Если один из серверов остановится на время, >весьма трудоемко его вводить в строй.

Понял вас. Очень поучительно. Буду думать теперь как этот процесс провести и реализовать схему в том числе и с учетом обозначенных нюансов.

ChAnton ★★ ()
Ответ на: комментарий от true_admin

Интересно. Видимо придется пробовать каждое из названных решений и смотреть что будет получаться.

ChAnton ★★ ()
Ответ на: комментарий от ChAnton

Ну если вам хочется по граблям - никто не запретит. Лучше бы изложили задачу более полно. Вероятно есть более красивый путь решения, который не приведет к уменьшению надежности.

ventilator ★★★ ()
Ответ на: комментарий от ChAnton

Мы используем master-master, но на TimesTen. Там реплицируется транзакционный лог. Есть способ борьбы с конфликтами и также способ их обнаружения. 100% гарантии это не дает, но для нас приемлимо. И да, у нас как приложение устроено так, чтобы снизить вероятность одновременной модификации строк на двух узлах.

vromanov ★★ ()
Ответ на: комментарий от vromanov

И? Если не секрет или коммерческая тайна, поделитесь? Это именно решение на Postgres?

ChAnton ★★ ()
Ответ на: комментарий от true_admin

постгрес излишне сложен в администрировании.

Постгрес просто позволяет сделать гораздо больше чем mysql). Например всегда умел влючать логгирование запросов без даунтайма. И много еще чего без даунтайма.

А то как в mysql любят, вообще веселит: нужно сделать консистентный бекап чтобы поднять слейв? - извольте залочить всю базу, пока ваши 300гб задампятся, ну или конечно можете взять левые тулзы которые может сработают. Хотя может уже в mysql что то сделали на эту тему.

ventilator ★★★ ()
Ответ на: комментарий от ChAnton

Нет это совсем другая комерческая InMemory база данных. Сейчас мы сделали, чтобы приложение работало либо с TimesTen, либо с Postgress. В постгрессе от репликации решили отказаться (уж больно много граблей везде описано) и решать вопрос на уровне приложения.

vromanov ★★ ()
Ответ на: комментарий от ventilator

А как же многочисленные форки от мускуля, например Percona XDB (Наверное аналог Postgre XC в какой-то мере), или MariaDB ? Не сам MySQL(аля-Oracle) конечно, но все-таки)))

ChAnton ★★ ()
Ответ на: комментарий от true_admin

А с чем конкретно у вас были трудности, в части триггеров и процедур в Postgres ?

ChAnton ★★ ()
Ответ на: комментарий от ventilator

300гб

mysql

you're doing it wrong :)

извольте залочить всю базу

достаточно дамп делать в одной транзакции. Если используется myisam то ой. Да можно просто бинарно скопировать. Стопанул базу, сделал снапшот фс и льёшь на другой сервер как есть.

true_admin ★★★★★ ()
Ответ на: комментарий от ChAnton

Форки это круто, но хотелось бы стабильного продукта, а не 100500 различных вариаций в каждой из которых запилена какая то фича. Percona XDB судя по всему сделана из галеры http://codership.com/ Когда я смотрел галеру, у меня было много вопросов и мало документации. Мне показалось что опрометчиво делать ставку на решение которое не обкатано и слабо описано. Кроме того минусом всех mysql-based решений было отсутствие hash/merge join алгоритмов, которые давали неплохое ускорение на наших запросах.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

Все переделки обеспечивают совместимость только до определенного уровня. И добавляют некоторые проблемы.

Тут ещё требования к надёжности играют. Часто нужна тупо производительность, а то что базы немного разные бывает что и пофиг. К тому же придуманы скриптики для сравнения баз и добавления недостающих строк :)

А я вообще не верю что можно изначально кривые приложения не расчитанные на масштабируемость полностью «вылечить» кустарными средствами.

Что касается всяких оракловых решений, то, кмк, там своего секса ого-го. И я считаю это исключительно результат криворукости дизайна (мускла и pg это тоже касается). Если простые и нужные вещи делаются только после прочтения кучи манов то тут или на поддержке бабло отбивают, или сделано неправильно.

true_admin ★★★★★ ()
Ответ на: комментарий от ChAnton

Просто очень сложно, везде грабли. Ты не можешь, например, просто так добавить таблицу, надо ещё при этом кучу действий сделать аля добавить нужные триггеры итп. Короче, мануал надо прочитать весь от и до, там всё подробно написано.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Стопанул базу, сделал снапшот фс и льёшь на другой сервер как есть.

Получил даунтайм и холодный кеш.

Вообще это я к неудобности постгреса). Бинарное копирование там предусмотрено и делается на ходу без остановки базы.

ventilator ★★★ ()
Ответ на: комментарий от true_admin

А я вообще не верю что можно изначально кривые приложения не расчитанные на масштабируемость полностью «вылечить» кустарными средствами.

+100500

ventilator ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.