а вам слабо почитать вики

http://wiki.postgresql.org/wiki/Postgres-XC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если это тот vromanov, то и для postgresql есть версия)

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

Маска, я тебя знаю :)

да ну?

Все таки думаю ты ошибся), irl мы точно не знакомы)

Понятно. Но увы, это не PostgreSQL (

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

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

300гб

mysql

you're doing it wrong :)

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

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

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

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

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

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

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

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

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

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

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

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

+100500