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

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

Извини, но это явно 4.2

Если тебе хочется триггеры добавить - добавляй, но чтобы вот «надо ещё при этом кучу действий сделать аля добавить нужные триггеры итп.»- это 4.2

PS: триггеры - это плохой стиль, при разработке не стоит их часто юзать.

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

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

Ну ок, нужен кэш. Я вспомнил что снапшоты можно делать без остановки. Вот так: http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and...

Там, правда, всё равно будет небольшой перерыв на flush cache. Я уже четыре года не админил мускул, не могу сказать на сколько это плохо. На мелкий базах вообще не проблема, на сколько помню.

Другое дело где взять эти самые снапшоты в линуксе. btrfs сырой, lvm тоже далеко не zfs. В общем, надо заранее продумывать такие вещи раз уж никак нельзя останавливать базу. Слава богу, те базы что я админил останавливать можно было, лишь бы недолго.

Извини, но это явно 4.2

Я про триггеры на таблицу. Там репликация триггерами. Не дай бог девелопер снесёт триггер pgpool или добавит таблицу без прописывание тригггеров которые делают репликацию.

триггеры - это плохой стиль, при разработке не стоит их часто юзать.

Да я вообще против sql :). Но выбора-то не было: что давали админить то и админил.

Вообще репликация тригерами это же какой-то кривой ужас.. Еще меня PG удивляет тем, что они в транзакционный лог пишут изменения индекса, что приводит к невозможности использовать транзакционный лог для репликации. Да и вообще было круто писать именно изменения на уровне строк, а не на уровне страниц.

Я про триггеры на таблицу. Там репликация триггерами. Не дай бог девелопер снесёт триггер pgpool или добавит таблицу без прописывание тригггеров которые делают репликацию.

Аах, я думал речь просто о посгрес. Pgpool я тоже считаю костылем.

Там, правда, всё равно будет небольшой перерыв на flush cache.

FLUSH TABLES WITH READ LOCK точно так же лочит базу. Это тоже downtime.

Я не к тому что проблема нерешаемая. Но в постгресах есть стандартный путь который делает копию базы без даунтаймов, напшотов fs/виртуалок исключительно средствами субд и это очень приятно особенно в случае софта, который спроектирован так, что даунтаймы базы приводят к остановке сервиса.

Да я вообще против sql

Ну не все вещи решаются key-value, если я правильно понял)

Еще меня PG удивляет тем, что они в транзакционный лог пишут изменения индекса, что приводит к невозможности использовать транзакционный лог для репликации.

Какие то странные выводы, насколько известно, родная репликация постгреса работает именно стримингом wal лога.

FLUSH TABLES WITH READ LOCK точно так же лочит базу

залочил, создал снапшот, отпустил лок. Сколько займёт блокировка? Если меньше 10 секунд то я не верю в фатальные последствия для подавляющего числа приложений. Лично для меня даже 30сек норм. Не, ну если тачка работает с перегрузом то она может долго очухиваться, да.

Я про мастер-мастер. Т.е. предположим есть две строчки на одной странице. на одном узле меняется одна, на втором другая. В логи на разных серврах пишутся РАЗНЫЕ версии одной и тоже страницы. имеем конфликт. Если бы писались изменения строк, то конфликта бы не было. Это как раз наш случай

не все вещи решаются key-value

Жаль нет столько времени чтобы это обсудить. Мне вот интересно, могут ли современные распределённые nosql базы аля hadoop решать те же задачи что и монструозные sql-решения от оракла. Вернее, на сколько сложно писать map/reduce под сложные запросы.

FLUSH TABLES WITH READ LOCK будет длиться пока все данные не записанные в датафайлы не сбросятся на диски(checkpoint в терминах постгрес) и если этих грязных буферов много(а количество их прямо влияет на скорость пишущих транзакций), то процесс может долго длиться, в пределах минут, а не секунд.

решать те же задачи что и монструозные sql-решения от оракла.

sql решения часто подразумевают ACID, а эта идеология важна для некоторых задач и не всегда BASE можно применить. Мне кажется эти подходы в разных нишах.

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

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

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

К слову в mysql пишутся изменения строк и можно сделать такое(и делают репликацию по кругу), но без учета специфики приложения велика вероятность получения фейла. Грубо говорят ACID не соблюдается в таком режиме.

Мне нечего возразить http://www.mysqlperformanceblog.com/2010/04/24/how-fast-is-flush-tables-with-...

sql решения часто подразумевают ACID

А слона-то я и не приметил :(

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

Буду в ваших краях — дам знать :)

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

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

Мне нечего возразить http://www.mysqlperformanceblog.com
/2010/04>/24/how-fast-is-flush-tables-with-...

Ну все-таки c postgre это сравнивать не совсем корректно)))

Вот полазил по форумам, выяснил, что multimaster концептуально плох (если он асинхронный). Каждый мастер у себя создает свои первичные ключи со своими значениями. Пока нагрузка не очень большая, они успевают оповестить друг друга. Как только нагрузка становится большой, возможно получить конфликт при синхронизации. Еще вычитал, что на мультимастере каждый сервер вроде как будет проводить и свои команды и команды остальных master-хостов. Тоесть, сколько было нагрузки на каждый сервер, столько и будет вероятно как каждом в совокупности, сколько бы ни было хостов, если не ошибаюсь конечно. Роста производительности не будет, а возможно будет даже убыль. Будет только рост надежности и то под вопросом.

Про Pgpool также повыяснял, но как оказалось, у него другие проблемы:

Человек пишет:

1) если он работает в команде со Streaming Replication (когда >мастер один, а остальные слейвы, которым SR раскидывает >ченджи), то как ни крути, все апдейты(делиты, инсерты) идут >на один сервер - он не масштабируется. То есть это нифига не >мультимастер уже.

2) если он работает в одиночку, то он синхронно сообщается >всем базам про апдейт. Каждый из них типа как «мастер». >Только вот в случае падения любого, нужно останавливать >целиком весь сервис, пока не актуализируешь базу, которая >была сломана.

Шардинг тоже где-то советуют.

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

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

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

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

Я все таки думаю если вы изложите задачу и цифры нагрузки, то может оказаться что ваша проблема решается проще.

А у вас большие объемы? Какого типа приложение?

Объемы небольшие. База в пределах 50-70 GB. Операции чтения-записи производяться довольно активно, практически ежесекундно. Обсчет статистики базы производиться также ежемоментно, тоесть пользователь базы должен видеть статистику в любой момент времени.

«Активно» и «практически ежесекнудно» после наших нескольких десятков тысяч запросов в секунду звучит забавно :)

да inmemory не очень подойдет. Объем слишком большой. С такой нагрузкой можно почти все что угодно выбирать

Вы можете потестировать его как раз, но если вам нужно >проверенное железобетонное решение, то увы его нет.

Ну, значит как обычно, придется делать придумывать и реализовывать комплексное решение аля-кластеризация+шардинг))) Ничего необычного в этом не вижу. Это стандартная проблема, по-которой я и пытаюсь получить максимум информации и разобраться.

Я все таки думаю если вы изложите задачу и цифры нагрузки, то >может оказаться что ваша проблема решается проще.

Да, вот как раз я что-то отписал человеку , постом выше.

«Активно» и «практически ежесекнудно» после наших нескольких >десятков тысяч запросов в секунду звучит забавно :)

Ну бывают решения, где база периодами простаивает, а потом резко и очень интенсивно пишет. У нас резких пиков нет, интенсивность точно сейчас не скажу, так как пока детальной информации нет(чуть позже узнаю). Но я предполагаю что не более пары тысяч запросов в секунду. Там специфика другая, она не сильно нагруженная, но должна быть сильно надежной.

да inmemory не очень подойдет. Объем слишком большой. С такой >нагрузкой можно почти все что угодно выбирать

Можете поподробнее, что вы имеете ввиду?

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

Вы можете сделать мастер/слейв + автопереключение при поломке мастера. Но если вам важнее сохранность данных, то лучше предусмотреть в бизнес логике при отвале мастера запись задач в очередь/файлы/другие инстансы. Но тут все зависит от вашей бизнес логики очень сильно,не всегда такое возможно. Часто задачи допускают в случае аварии показывать юзеру данные со слейва пока мастер лежит(устаревшие данные) и если это так, не стоит делать автопереключения, а переключать руками таки.

да inmemory не очень подойдет. Объем слишком большой.

Сейчас 50-70Гб не являются проблемой в плане объема RAM. Другой вопрос что вряд ли ТС нужен вообще inmemory.

Не совсем ясна связь между «практически ежесекнудно» и «не >более пары тысяч запросов в секунду»

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

Часто задачи допускают в случае аварии показывать юзеру данные >со слейва пока мастер лежит(устаревшие данные)

Да, я рассматриваю разные варианты.