MySQL replikace Master <-> Master

Filip Krejčí krejcif na gmail.com
Středa Srpen 9 10:18:55 CEST 2006


DD


Petr Klima napsal(a):
> kruh slozeny ze tri a vice mysql serveru je podporovany. Kruh ze dvou
> tusim ovsem nefunguje, coz vas nezajima tak jako tak.

To jsem se nikde nedocetl ze by nemel fungovat ring slozeny ze dvou.
Proc se domnivate ze by to nemelo fungovat ?

> Filip Krejčí wrote:
>> 1/ Muzu vytvorit replication ring a kazdy master bude mit posunuty
>> auto_increment(aby nedoslo ke kolizi klicu). Pak muzu tyto data ktera
>> chci replikovat mezi mastery zapisovat na vsechny mastery.
>>
>> 2/ Muzu zapisovat tyto data jen na jednoho mastera a ostatni od neho
>> budou pozirat logy.
> 
> ==> Zalezi na tom, co potrebujete. Jestli vam staci moznost zmeny dat
> pouze na masteru a na ostatnich vam staci pouhe cteni, volba 2 je v
> poradku. Jestli potrebujete menit data kdekoliv, musite vyuzit 1.
> 
>> Chtel bych se zeptat zdali mate nekdo s tykovymto replikacnim schematem
>> zkusenosti? Zdali jste u toho narazili na nejake provozni problemy? A
>> predevsim ktere z tech dvou variant byste dali prednost?
>>
>> Osobne se klanim k variante 2/
>> Varianta 1/ sice nema zadny single point of failure nicmene pri
>> vypadnuti jednoho mastera z ringu se IMO rozhodi konzistence tech master
>> databazi, protoze se ten retez proste pretrhne.
>>
>> Nebo to je tak, ze se pletu a lze navazat na tu replikaci v tom miste
>> kde se to roztrhlo ?
> 
> Samozrejme ze ano, jinak by takova replikace byla opravdu k nicemu,
> protoze by vam ji rozhodilo skoro cokoliv - vypadek linky, selhani
> hardwaru atd. Jak Master tak slave si pamatuji aktualni binlog a pozici
> v nem. Cili, pokud dojde z jakehokoliv duvodu k vypadku, musite
> zajistit, aby po nabehu mel slave z ceho replikovat, tedy aby byla
> dostatecna historie binarnich logu na masteru. V podstate musite mit
> nastaveny dostatecny pocet binlog souboru, protoze (alespon v Debianu)
> se log rotuje pri mysqldumpu, rano pri regulerni rotaci logu a pri
> kazdem restartu mysql. Mozna je tech prilezitosti k rotaci jeste vice.

V tom pripade asi pouziji variantu 1/ nemit single point of failure je 
jednoznacne vyhoda.



Filip Krejci



Další informace o konferenci Linux