Comments 12
велосипед давно изобретен
mysql-mmm.org/start
и вот onlamp.com/onlamp/2006/04/20/advanced-mysql-replication.html чтоб понять принципы
mysql-mmm.org/start
и вот onlamp.com/onlamp/2006/04/20/advanced-mysql-replication.html чтоб понять принципы
Большое спасибо за ссылки, многое подчерпнул из этих статей.
Но есть вопрос. Скрипты MMM по сути разработаны для топологии звезда с однонаправленными связями. Один мастер и несколько слейвов, при падении мастера осуществляется выбор нового мастера. При этом идет разделение запросов на чтение/запись и, как я понял все запросы на запись идут только к мастеру, а все запросы на чтение — только к слейвам (видимо чтобы разгрузить мастера). Так вот, моя же задача состоит в том, чтобы читать/писать можно было на все сервера, т.е. получается гомогенная среда. Это было в начале статьи по вашей ссылке. И при падении одного из узлов кольца, нужно замыкать кольцо на другой узел. А при восстановлении узла, включать его в кольцо. Есть ли какой-нибудь софт для этих целей, или можно как-то настроить MMM для этого?
Но есть вопрос. Скрипты MMM по сути разработаны для топологии звезда с однонаправленными связями. Один мастер и несколько слейвов, при падении мастера осуществляется выбор нового мастера. При этом идет разделение запросов на чтение/запись и, как я понял все запросы на запись идут только к мастеру, а все запросы на чтение — только к слейвам (видимо чтобы разгрузить мастера). Так вот, моя же задача состоит в том, чтобы читать/писать можно было на все сервера, т.е. получается гомогенная среда. Это было в начале статьи по вашей ссылке. И при падении одного из узлов кольца, нужно замыкать кольцо на другой узел. А при восстановлении узла, включать его в кольцо. Есть ли какой-нибудь софт для этих целей, или можно как-то настроить MMM для этого?
Спасибо за статью! А не подскажете? как реализовать следующею схему и можно ли. Чую что можно…
Пусть у нас есть ОЧЕНЬ важная база Base1 (номера кридиток допусти) которая должна работать всегда.
И мене важная база со всем остальным Base2
Цель — обеспечить повышенную отказоустойчивость для Base1 и приемлемую отказоустойчивость для Base2
1) Server1 используется на запись для Base1 (то есть он мастер для Base1)
2) Server2 является слейвом для Base1, однако на нем крутиться также Base2 и в нее пишут.
3) Server3 является слейвом для Server2 и на него реплецируются обе базы (Base1, Base2)
Судя по вашему посту сделать коскадную репликацию из трех серверов одной базы — можно. Но может ли один инстенс MySQL быть мастером для одной базы и слейво для второй? Или для Server2 нужно будет поднимать два экземпляра MySQL?
Server1.Base1 (m) ---> (s) Server2.Base1 (s) --> (s) Server3.Base1
=================== Server2.Base1 (m) --> (s) Server3.Base2
Пусть у нас есть ОЧЕНЬ важная база Base1 (номера кридиток допусти) которая должна работать всегда.
И мене важная база со всем остальным Base2
Цель — обеспечить повышенную отказоустойчивость для Base1 и приемлемую отказоустойчивость для Base2
1) Server1 используется на запись для Base1 (то есть он мастер для Base1)
2) Server2 является слейвом для Base1, однако на нем крутиться также Base2 и в нее пишут.
3) Server3 является слейвом для Server2 и на него реплецируются обе базы (Base1, Base2)
Судя по вашему посту сделать коскадную репликацию из трех серверов одной базы — можно. Но может ли один инстенс MySQL быть мастером для одной базы и слейво для второй? Или для Server2 нужно будет поднимать два экземпляра MySQL?
Server1.Base1 (m) ---> (s) Server2.Base1 (s) --> (s) Server3.Base1
=================== Server2.Base1 (m) --> (s) Server3.Base2
Но может ли один инстенс MySQL быть мастером для одной базы и слейвом для второй?
На сколько я знаю, в mysql нет разделение на master-slave по базам. Предлагаю сделать так:
server2 будет мастером для server3, но в свою очередь будет слейвом для server1.
Будет нечто вроде этого:
Server1.Base1 (m) ---> (s) Server2.Base1 (m) --> (s) Server3.Base1
=================== Server2.Base1 (m) --> (s) Server3.Base2
И вы можете спокойно писать и в server1 и в server2, не забыв добавить
log-slave-updatesв конфиг server2. Получите, как раз то, что требуется.
А как обстоят дела с автоинкрементными ключами? По идее должны быть конфликты-же?
Ну собственно вот так:
Quoting from the manual:
* auto_increment_increment controls the increment between successive AUTO_INCREMENT values.
* auto_increment_offset determines the starting point for AUTO_INCREMENT column values.
By choosing non-conflicting values for these variables on different masters, servers in a multiple-master configuration will not use conflicting AUTO_INCREMENT values when inserting new rows into the same table. To set up N master servers, set the variables like this:
* Set auto_increment_increment to N on each master.
* Set each of the N masters to have a different auto_increment_offset, using the values 1, 2,…, N.
Using those two variables as described in the manual, you can ensure that all nodes in your replication array will use different sequences of auto-incrementing numbers. For example, using auto_increment_increment = 10 and auto_increment_offset=3, the numbers generated when inserting three records will be 3, 13, 23. Using 10, 7, you'll get 7, 17, 27, and so on.
Добавлю в статью.
Quoting from the manual:
* auto_increment_increment controls the increment between successive AUTO_INCREMENT values.
* auto_increment_offset determines the starting point for AUTO_INCREMENT column values.
By choosing non-conflicting values for these variables on different masters, servers in a multiple-master configuration will not use conflicting AUTO_INCREMENT values when inserting new rows into the same table. To set up N master servers, set the variables like this:
* Set auto_increment_increment to N on each master.
* Set each of the N masters to have a different auto_increment_offset, using the values 1, 2,…, N.
Using those two variables as described in the manual, you can ensure that all nodes in your replication array will use different sequences of auto-incrementing numbers. For example, using auto_increment_increment = 10 and auto_increment_offset=3, the numbers generated when inserting three records will be 3, 13, 23. Using 10, 7, you'll get 7, 17, 27, and so on.
Добавлю в статью.
zizop если не затруднит свяжись со мной
ICQ 997544
Прочитал твои статьи, есть личный вопрос (Работа)
ICQ 997544
Прочитал твои статьи, есть личный вопрос (Работа)
При падении хотя бы одного сервера — на всех остальных данные рассинхронизируются.
Это своего рода MySQL RAID0.
Это своего рода MySQL RAID0.
multi-master схема оказывается обычно чертовски накладной в содержании и обслуживании. Все-таки, mysql — не кластерная субд, и такое ее использование черевато.
Операции записи/удаления могут вызывать конфликты, например.
Операции записи/удаления могут вызывать конфликты, например.
А если у нас есть такая схема replic1(ro)replic2(ro). При падении мастера необходимо сделать одну таблицу в БД rw. Соответственно между первым и вторым репликом должна подняться связь master-slave на время падения мастера. Или есть другой способ обеспечить целостность данных на время падения мастера?
Sign up to leave a comment.
Multi-Master репликация в MySQL