|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день.
Существует примерно такая схема:
_ _ _ _ _ _ _ _ _ _ _ _ _ _
| | | |
| master | -----------------> | slave1 |
| | | |
|_ _ _ _ _ _| |_ _ _ _ _ __|
/ \
/ \
/ \
/ \
_ _ _ _ _/_ _ _ _\ _ _ _ _ _
| | | |
| slave2 | | slave3 |
| | | |
|_ _ _ _ _ _ _| |_ _ _ _ _ _|
На всех серверах mysql 4 ветки. Между master & slave1 репликация master-slave. Причем slave1 реплицирует все, за исключением одной таблички(сильно тяжелая). На slave1 идут исключительно select запросы, никаких insert'ов нет.
Slave2 & slave3 реплицируют всего несколько табличек, в отличии от slave1. Но, в slave2 & slave3 идут insert'ы.
В master приходит основной поток insert'ов.
В резуьтате того, что в slave2&slave3 приходят некоторые insert'ы, ломаются master-slave репликация между master и slave2&slave3.
(В результате того, что slave2 и slave3 имеют на некоторых таблицах различные autoicrement_value, и при реплицированиии с master, может возникнуть ситуация duplicate entry).
Что хочется получить:
1. Идеальный вариант: наличие master-master репликация нескольких табличек между slave2&slave3 - master
2. Достаточный вариант: работа master-slave репликации между slave2&slave3 - master
Насколько я понимаю, достаточный вариант можно получить, проапргрейдив все сервера до 5 версии и выставив определленые значения autoincrement_increment и autoincrement_offset на slave2, slave3 и master.
Существуют ли какие-либо другие способы решения? Может быть стоит перейти к какой-то другой схеме репликации?
Так же, не будет ли возникать проблемы, в случае master-master репликации между slave2&slave3 - master, поскольку на slave2&slave3 находится только несколько табличек, а в master их гораздо больше(если указывать replicate-do-table - то не будет ли slave1 реплицировать только эти таблички. В конфиге my.cnf slave1 прописано какие таблицы игнорировать).
Чтобы не быть голословным - slave1 и slave2 - базы хранилище для dns-системы. slave1 - реплика, которая создана для уменьшения нагрузки master и используется только для большого количества select запросов. Убрать из схемы slave2 и slave3 - нельзя.
Неактивен
Кажется, варианты 1 и 2 друг от друга не очень отличаются. autoincrement_increment и autoincrement_offset
Вас действительно спасут (только надо ставить через 3, т.к. у Вас пишут на три машинки).
Какой смысл держать slave2/slave3 разными? в них разные таблички? Как Вы их сейчас синхронизируете между
собой и с мастером? Почему нельзя отправить все изменения на мастер?
Неактивен
> Какой смысл держать slave2/slave3 разными?
Я не держу их разными 
Они отдельные, потому что это две разные физические машины в разных датацентрах.
Реплицировать их между собой я смысла не вижу.
> Как Вы их сейчас синхронизируете между собой и с мастером?
slave2&&slave3 сейчас синхронизируются по master-slave схеме с master. Между собой slave2 и slave3 не реплицируются.
> Почему нельзя отправить все изменения на мастер?
Это подразумевает наличие master-master репликаций slave2-master и slave3-master
Я не знаю, будет ли такая схема корректно работать. Те будет ли нормальным, например:
1) slave2 посылает insert master
2) master посылает этот же insert slave3
Здесь еще очень важный момент, что репликация master-slave между master-slave1 не должна рушиться и на slave2 и slave3 должны реплицироваться только некоторые таблички.
Неактивен
Все равно не понимаю. Пусть я вставил строчку в slave1. Ее не будет ни в мастере, ни в
slave2. Получается, что данные разъехались. Что в этом хорошего?
--
Что касается односторонних репликаций «туда-сюда» — не получится, т.к. мастер у сервера
может быть только один, т.е. машинка master может тянуть или со slave2 или со slave3, но никак
не одновременно. Как вариант — круговая репликация
master -> slave2 -> slave3 -> master
master -> slave1
Неактивен
> Все равно не понимаю. Пусть я вставил строчку в slave1. Ее не будет ни в мастере, ни в
> slave2. Получается, что данные разъехались. Что в этом хорошего?
В этом безусловно есть хорошее, но в данном конкретном случае ничего плохого нет.
Наверное лучше обьяснить все с деталями.
В таблицах slave2 и slave3 содержатся данные о доменах(используется dns сервер powerdns).
Так вот, в случае, когда домен выступает в роли slave - софт спрашивает у его мастер серверов(не mysql master, a dns master серверов) информацию и вставляет ее в эти таблички(вот эти те самые insert'ы в slave2 и slave3). Так как домены одинаковые(они реплицируются с master) - то соответственно должны быть и одинаковые вставленные записи. В данном случае, репликация как бэ осуществляется средствами powerdns. В условиях задачи, гораздо важнее, чтобы осуществлялась репликация между master->slave3 и master->slave3.
Таким образом, основная задача сводится к тому, что бы репликации между master->slave2 и master->slave3 не нарушались, в случае, когда какие-то insert'ы пришли на slave2 или slave3(опять же в 5 версии насколько я понимаю это решается за счет autoincrement_increment и offset. Однако в мане так же сказано, что эти переменные можно использовать только в случае репликации master-master).
На счет круговой репликации.
Тут я видимо немного не понимаю.
master -> slave2 -> slave3 -> master
Те master сервер является master'ом для slave2, slave2 является мастером для slave3, slave3 мастером для master.
В случае попадания insert в master, он будет среплицирован сначала на slave2, потом на slave3, а потом?)
Неактивен
ubique написал:
переменные можно использовать только в случае репликации master-master
Это основное применение, но не значит, что только в этом случае.
ubique написал:
В случае попадания insert в master, он будет среплицирован сначала на slave2, потом на slave3, а потом?)
Сначала на slave2, потом на slave3, потом на master 
А вот тут магия — у каждого сервера уникальный server-id.
master смотрит, что изменение генерировано им самим, и, соответственно, пропускает его (т.к. он уже его выполнял).
Неактивен
paulus написал:
ubique написал:
переменные можно использовать только в случае репликации master-master
Это основное применение, но не значит, что только в этом случае.
Угу, уже понял.ubique написал:
В случае попадания insert в master, он будет среплицирован сначала на slave2, потом на slave3, а потом?)
Сначала на slave2, потом на slave3, потом на master
master смотрит, что изменение генерировано им самим, и, соответственно, пропускает его (т.к. он уже его выполнял).
Во, понял как.
Вообщем решили обойтись малой кровью и сделать составной ключ для таблицы. Кстати на такое решение тоже натолкнулся по ходу гугления.
Спасибо за помощь!
Неактивен
Я рад, что Вы решили задачу... а какое отношение имеет ключ?
Неактивен
paulus написал:
Я рад, что Вы решили задачу... а какое отношение имеет ключ?
Проблема заключалась в том, что была возможна ситуация, когда при реплицировании на slave2 или slave3 приходил insert запрос с master сервера(таблица в которую он приходил имела primary unique auto_increment key), то возникала ошибка duplicate entry из-за того, что значение autoincrement для таблицы на master и slave2||slave3 было различным(те самые insert запросы на slave серверах). Сделав составной ключ, мы решили эту проблему.
Неактивен
