Pull to refresh

Comments 14

А записи со всех серверов там все строго уникальные, и вы сливаете их все в одну кучу в итоге?
Просто если нет, то не ясно как вы разруливаете конфликты.
каждая удаленная бд пишется в отдельную базу на слэйве. на несколько таблиц повесил триггеры, которые пишут из всех баз в одну. все усложнено немного, но пока это самое оптимальное решение
хм, но это отменяет наличия конфликтов при совпадении ID
в общей базе уже дргие ид. это, конечно, специфично для моего случая, требовались новые ид.
но для всех можно настроить auto_increment_increment и auto_increment_offset на мастерах, чтобы с триггерами не мудрить.
тогда даже, если все базы одинаковы, можно и таргет у федерэйтэдов один сделать.
Ну я так и подумал что в итоге все записи получали новые ID, просто очень близка данная тема, сами сейчас мудрим как бы так всё это красиво собрать, но собираем в итоге на самом клиенте и кэшируем, присваивать новые ID в нашем случае нельзя.
С технической точки зрения всё ясно. А какая архитектурная цель этого решения?
для меня — объединение нескольких автономных бд на одном сервере, для выполнения общих запросов
А можно вопрос: зачем? «Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер.»

И например рассматривался ли вариант с цепочной репликацией и BLACKHOLE (и если да, то чем не подошёл)?:
MASTER1 -> MASTER2,BLACKHOLE1 — > MASTER3,BLACKHOLE1,BLACKHOLE2 ->......->MASTER_N,BLACKHOLE1...BLACKHOLE_N-1 -> SLAVE

Такой вариант проще конфигурировать и обслуживать и никаких скриптов.
Формально у такой цепочки ниже надежность, но мне кажется что для агрегатора некоторый downtime не критичен. Точней так: мне кажется что нет большой разницы между тем, что 30 минут не поступают данные репликации (которые потом подтянутся) и тем, что 30 минут не поступают данные от одного из мастеров — в том смысле что в обоих этих случаях агрегированные значения будут отсутствовать/неверны
Каждая из баз автономная, и есть возможность, что в любой момент она может оказаться недоступной. И вовсе не надо было, чтобы на мастерах оказывались данные другого мастера.
Я посмотрел много вариантов репликации, включая предложенные. Добавление/удаление звена в кольце, изыски с replicate-rewrite-db (в посте писал, что query-browser выполняет запросы только с полными именами таблиц, вместе с именем базы. Но тут можно и базы назвать по-разному, в принципе) гораздо сложнее используемого способа. Так вся конфигурация находится на 1м сервере и при остановке мастера вообще ничего не требуется, а при добавлении маленький скрипт быстро поднимает репликацию.
Я не предлагаю использовать этот способ вместо каких-то предложенных вами. Он реализует one-slave-multi-master без лишних мастер-мастер репликаций.
Позже нашел tungsten-replicator. Пока не смотрел, но уже опасаюсь полных путей таблиц, а без q-b пока никак.
blackhole не хранит данных. только логи для репликации.
это не кольцо
здесь нет master-master репликаций. толькоmaster-slave
Про мастер-мастер я писал к комменту ниже. Почему не использовал цепочку, я написал в первом абзаце и конце второго предыдущего ответа. Может только не уточнил, что «оказаться недоступной» — быть отключена навсегда.
Only those users with full accounts are able to leave comments. Log in, please.