Comments 14
А записи со всех серверов там все строго уникальные, и вы сливаете их все в одну кучу в итоге?
Просто если нет, то не ясно как вы разруливаете конфликты.
Просто если нет, то не ясно как вы разруливаете конфликты.
каждая удаленная бд пишется в отдельную базу на слэйве. на несколько таблиц повесил триггеры, которые пишут из всех баз в одну. все усложнено немного, но пока это самое оптимальное решение
хм, но это отменяет наличия конфликтов при совпадении ID
не отменяет точнее
в общей базе уже дргие ид. это, конечно, специфично для моего случая, требовались новые ид.
но для всех можно настроить auto_increment_increment и auto_increment_offset на мастерах, чтобы с триггерами не мудрить.
тогда даже, если все базы одинаковы, можно и таргет у федерэйтэдов один сделать.
но для всех можно настроить auto_increment_increment и auto_increment_offset на мастерах, чтобы с триггерами не мудрить.
тогда даже, если все базы одинаковы, можно и таргет у федерэйтэдов один сделать.
С технической точки зрения всё ясно. А какая архитектурная цель этого решения?
А можно вопрос: зачем? «Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер.»
И например рассматривался ли вариант с цепочной репликацией и BLACKHOLE (и если да, то чем не подошёл)?:
MASTER1 -> MASTER2,BLACKHOLE1 — > MASTER3,BLACKHOLE1,BLACKHOLE2 ->......->MASTER_N,BLACKHOLE1...BLACKHOLE_N-1 -> SLAVE
Такой вариант проще конфигурировать и обслуживать и никаких скриптов.
Формально у такой цепочки ниже надежность, но мне кажется что для агрегатора некоторый downtime не критичен. Точней так: мне кажется что нет большой разницы между тем, что 30 минут не поступают данные репликации (которые потом подтянутся) и тем, что 30 минут не поступают данные от одного из мастеров — в том смысле что в обоих этих случаях агрегированные значения будут отсутствовать/неверны
И например рассматривался ли вариант с цепочной репликацией и 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 пока никак.
Я посмотрел много вариантов репликации, включая предложенные. Добавление/удаление звена в кольце, изыски с replicate-rewrite-db (в посте писал, что query-browser выполняет запросы только с полными именами таблиц, вместе с именем базы. Но тут можно и базы назвать по-разному, в принципе) гораздо сложнее используемого способа. Так вся конфигурация находится на 1м сервере и при остановке мастера вообще ничего не требуется, а при добавлении маленький скрипт быстро поднимает репликацию.
Я не предлагаю использовать этот способ вместо каких-то предложенных вами. Он реализует one-slave-multi-master без лишних мастер-мастер репликаций.
Позже нашел tungsten-replicator. Пока не смотрел, но уже опасаюсь полных путей таблиц, а без q-b пока никак.
А зачем так сложно? Сделали бы обычную циркулярку, вот по этой статье хотя бы Advanced MySQL Replication Techniques, и имели бы себе «мультимастер».
Sign up to leave a comment.
MySQL репликация one-slave-multi-master