Disponibilità elevata, failover e replica MySQL con Latency


8

Stiamo implementando un nuovo CMS (Drupal 6.x) che gira su MySQL. Abbiamo due data center - primario e secondario - con latenza nota tra di loro. Non siamo sicuri di quale versione di MySQL eseguiremo ... Community o Enterprise, ma si tratta di un TBD. Sembra che eseguiremo il motore InnoDB, il sistema operativo sarà RedHat EL 5.5 I server primari saranno attivi, mentre il secondario sarà passivo o hot stand-by.

Vorrei implementare la replica, l'elevata disponibilità e il failover automatico in MySQL nei due data center.

Dopo un failover sui server secondari, quando eseguiamo il failback sui server primari, vorremmo che i dati fossero sincronizzati dal DB secondario al DB primario in modo rapido e completo in modo da poter continuare a servire il contenuto dai server primari.

Sono interessato a sapere quali tecnologie / strumenti / migliori pratiche possono essere utilizzati per risolvere / affrontare questi problemi. Inoltre, anche qualsiasi momento o ah ah ah sarebbe molto apprezzato. Ho letto la replica di MySQL, il clustering e alcuni strumenti di terze parti come Tungsten e Dolphinics, ma non sono sicuro di quale sia la migliore linea di condotta.

Grazie per il tuo tempo!

KM

Risposte:


3

Per semplicità, consiglio solo MySQL Circular Replication. Ecco perché:

Esistono molte tecnologie e topologie di gran lunga superiori a MySQL Circular Replication. Il mio preferito, senza dubbio , è DRBD (Distributed Replicated Block Device) . Tuttavia, DRBD funziona alla grande quando la coppia di server si trova nello stesso bulding, data center e rack. È ancora meglio quando si utilizza un cavo crossover nella sottorete 192.168.xx tra il DRBD primario e il DRBD secondario. Sfortunatamente , DRBD ha prestazioni orribili su una distanza tra due posizioni, sebbene DRBD possa ancora funzionare. Non ci sono topologie di rete in giro per darti le soddisfacenti prestazioni DRBD necessarie tra due datacenter.

Dopo aver configurato MySQL Circular Replication tra i due server DB in due diversi data center, l'unica messa a punto necessaria è per la rete. In sostanza, le prestazioni di replica sono una funzione delle impostazioni di rete (velocità / latenza della trasmissione del registro binario in MySQL Replication Setup) e dell'I / O del disco (DRBD).

Un'alternativa che potresti desiderare per una migliore ridondanza è la seguente a titolo di esempio:

Configurare una coppia DRBD in entrambe le posizioni
Coppia DRBD nel sito n. 1 con VIP
111.111.111.111 Coppia DRBD nel sito n. 2 con VIP 222.222.222.222

Configurare la replica circolare MySQL tra i server primari DRBD in queste condizioni:
Per il sito n. 1, utilizzare 222.222.222.222 come Master_Host in MySQL
Per il sito n. 2, utilizzare 111.111.111.111 come Master_Host in MySQL

Pur introducendo un livello di complessità, ora hai due livelli di ridondanza: DRBD all'interno di ciascun sito e MySQL Circular Replication tra i siti. Hai i vantaggi aggiuntivi di eseguire i backup tramite mysqldump sul primario DRBD del server hot standby.

Per quanto riguarda il failover, DRBD fornisce il failover automatico in qualsiasi sito.

Solo nel caso in cui un datacenter sia totalmente non disponibile, si utilizzerà DB VIP nel sito di hot standby.

AGGIORNARE

Ho appena fatto una doppia ripresa e ho notato che stai usando Drupal6. Sono felice che convertirai tutte le tabelle drupal in InnoDB. Ciò rimuoverà ogni possibilità di aggiornamenti delle tabelle MyISAM che causano il blocco dei blocchi di tabelle che bloccano le connessioni DB che stanno semplicemente leggendo le tabelle MyISAM. Qualsiasi aggiornamento DML (INSERISCE, AGGIORNAMENTI, CANCELLA) su una tabella MyISAM FARÀ SEMPRE UN BLOCCO TABELLA COMPLETO !!! L'uso di InnoDB introduce il blocco a livello di riga, che elimina i blocchi completi della tabella.

Inoltre, DRBD diventa tuo amico quando tutto è InnoDB perché il ripristino da crash sarà coerente tra la coppia DRBD. Inoltre, DRBD con MyISAM non ti compra nulla perché una tabella MyISAM bloccata sul primario DRBD viene semplicemente duplicata sul secondario DRBD come, hai indovinato , una tabella MyISAM danneggiata.

AGGIORNAMENTO # 2

È necessario utilizzare due livelli di ridondanza

Livello 1: in ciascun centro database, utilizzare DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html

Configurare una coppia di server DB
Avvio DRBD
Avvio MySQL sul DRBD primario

Questo crea dati ridondanti a livello del disco.

Livello 2: è necessario configurare la replica circolare MySQL tra
il primario DRBD di DataCenter n. 1 e il primario DRBD di DataCenter n. 2

Ogni primario DRBD eseguirà MySQL e fungerà
sia da master che da slave

Ho impostato per topologie client come questo e lo considero abbastanza stabile.


Grazie @RolandoMySQLDBA. Il tuo punto sull'uso di un VIP con bilanciamento del carico per interruzioni del data center ha senso. Quindi avremmo un Master-Slave in ogni datacenter, giusto? In caso di failback, quale pensi sia il modo migliore per garantire l'aggiornamento dei DB primari? Inoltre, ho osservato la replica circolare e sembra che si basi sul clustering MySQL? con NDB? Non penso che Drupal 6 funzioni bene con NDB ( drupal.org/node/391130 ). Grazie ancora per il tuo tempo!
KM.

Ho aggiornato la mia risposta !!! A proposito non ho mai menzionato NDB. MySQL Circular Replication è solo Master-Slave implementato in modo bidirezionale.
RolandoMySQLDBA

Grazie per il chiarimento. Alcuni dei riferimenti di replica circolare di MySQL menzionavano NDB, quindi volevo ricontrollare (-: A proposito, quanto automatizzato puoi ottenere con il failover usando queste topologie?
KM.

DRBD è progettato per facilitare il failover automatico utilizzando Linux HeartBeat o ucarp ( ucarp.org/project/ucarp ). La mia azienda, LogicWorks, è un negozio ucarp. ucarp consente a due macchine di condividere un indirizzo IP virtuale (VIP). DRBD Master avrebbe il VIP con MySQL in esecuzione su di esso. DRBD Secondary avrebbe ucarp in esecuzione e aspetterebbe un tempo morto per attivare il failover automatico. Gli script su e giù per ucarp per assumere il DB VIP dovrebbero includere il montaggio del disco DRBD, rendendolo Primario e avviando MySQL. Down script interromperà MySQL smontando DRBD, diverrebbe Secondario e ucciderebbe il VIP.
RolandoMySQLDBA
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.