MariaDB
 sql >> Database >  >> RDS >> MariaDB

Suggerimenti per la migrazione da MySQL Replication a MySQL Galera Cluster 4.0

In precedenza abbiamo scritto sul blog sulle novità di MySQL Galera Cluster 4.0, sulla gestione di grandi transazioni con la replica in streaming e su MariaDB 10.4 e abbiamo presentato alcune guide sull'utilizzo della nuova funzionalità di replica in streaming in una serie parte 1 e parte 2.

Spostare la tecnologia del database da MySQL Replication a MySQL Galera Cluster richiede che tu abbia le giuste competenze e una comprensione di ciò che stai facendo per avere successo. In questo blog condivideremo alcuni suggerimenti per la migrazione da una configurazione di replica MySQL a MySQL Galera Cluster 4.0.

Le differenze tra la replica MySQL e il cluster Galera

Se non hai ancora familiarità con Galera, ti suggeriamo di consultare il nostro Galera Cluster for MySQL Tutorial. Galera Cluster utilizza un livello completamente diverso di replica basato sulla replica sincrona, in contrasto con MySQL Replication che utilizza la replica asincrona (ma potrebbe essere configurato anche per ottenere una replica semi-sincrona).

Galera Cluster supporta anche la replica multi-master. È in grado di eseguire applicazioni parallele non vincolate (ovvero "replica parallela"), replica multicast e provisioning automatico dei nodi.

L'obiettivo principale di Galera Cluster è la coerenza dei dati, mentre con MySQL Replication è soggetto all'incoerenza dei dati (che può essere evitata con le migliori pratiche e una configurazione adeguata come l'applicazione della sola lettura sugli slave per evitare scritture indesiderate all'interno degli slave).

Sebbene le transazioni ricevute da Galera vengano applicate a tutti i nodi o non vengano applicate affatto, ciascuno di questi nodi certifica il set di scritture replicato nella coda dell'applicatore (commissioni di transazione) che include anche informazioni su tutti i blocchi che sono stati mantenuti dal database durante la transazione. Questi set di scrittura, una volta che non vengono identificati blocchi in conflitto, vengono applicati. Fino a questo punto, le transazioni sono considerate impegnate e continuano ad applicarle al tablespace. A differenza della replica asincrona, questo approccio è anche chiamato replica virtualmente sincrona poiché le scritture e i commit avvengono in modalità logica sincrona, ma la scrittura e il commit effettivi nel tablespace avvengono indipendentemente e diventano asincroni su ciascun nodo.

A differenza di MySQL Replication, un cluster Galera è un vero e proprio slave multi-master, multi-thread, un puro hot-standby, senza necessità di master-failover o splitting lettura-scrittura. Tuttavia, la migrazione a Galera Cluster non significa una risposta automatica ai tuoi problemi. Galera Cluster supporta solo InnoDB, quindi potrebbero esserci modifiche al design se stai utilizzando MyISAM o motori di archiviazione di memoria.

Conversione di tabelle non InnoDB in InnoDB

Galera Cluster ti permette di usare MyISAM, ma questo non è ciò per cui Galera Cluster è stato progettato. Galera Cluster è progettato per implementare rigorosamente la coerenza dei dati all'interno di tutti i nodi all'interno del Cluster e ciò richiede un potente motore di database compatibile con ACID. InnoDB è un motore che ha queste potenti capacità in quest'area e si consiglia di utilizzare InnoDB; soprattutto quando si tratta di transazioni.

Se stai utilizzando ClusterControl, puoi facilmente determinare le tue istanze di database per qualsiasi tabella MyISAM fornita da Performance Advisors. Puoi trovarlo nella scheda Performance → Consulenti. Ad esempio,

Se hai bisogno di tabelle MyISAM e MEMORY, puoi comunque usarle ma assicurati i tuoi dati che non hanno bisogno di essere replicati. Puoi utilizzare i tuoi dati memorizzati per la sola lettura e utilizzare "START TRANSACTION READONLY" ove appropriato.

Aggiunta di chiavi primarie alle tue tabelle InnoDB

Poiché Galera Cluster supporta solo InnoDB, è molto importante che tutte le tabelle abbiano un indice cluster (chiamato anche chiave primaria o chiave univoca). Per ottenere le migliori prestazioni da query, inserimenti e altre operazioni di database, è molto importante definire ogni tabella con una o più chiavi univoche poiché InnoDB utilizza l'indice cluster per ottimizzare le operazioni di ricerca e DML più comuni per ciascuna tabella . Ciò consente di evitare query di esecuzione prolungata all'interno del cluster e potrebbe rallentare le operazioni di scrittura/lettura nel cluster.

In ClusterControl ci sono consulenti che possono avvisarti di questo. Ad esempio, nel cluster master/slave di MySQL Replication, verrà emesso un avviso dalla visualizzazione o dall'elenco degli advisor. Lo screenshot di esempio seguente rivela che non hai tabelle che non hanno una chiave primaria:

Identifica un nodo master (o scrittore attivo)

Galera Cluster è puramente una vera replica multi-master. Tuttavia, ciò non significa che sei completamente libero di scrivere qualsiasi nodo desideri indirizzare. Una cosa da identificare è che, quando si scrive su un nodo diverso e viene rilevata una transazione in conflitto, si verificherà un problema di deadlock proprio come di seguito:

2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:

TRANSACTION 728431, ACTIVE 0 sec starting index read

mysql tables in use 1, locked 1

MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)

2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:

TRANSACTION 728426, ACTIVE 3 sec updating or deleting

mysql tables in use 1, locked 1

, undo log entries 11409

MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating

update sbtest1_success set k=k+1 where id > 1000 and id < 100000

2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X

Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0

 0: len 8; hex 73757072656d756d; asc supremum;;

Il problema con la scrittura di più nodi senza identificare un nodo di scrittura attivo corrente, ti ritroverai con questi problemi che sono problemi molto comuni che ho riscontrato quando si utilizza Galera Cluster quando si scrive su più nodi in lo stesso tempo. Per evitare ciò, puoi utilizzare l'approccio di configurazione a master singolo:

Dalla documentazione,

Per rilassare il controllo del flusso, potresti utilizzare le impostazioni seguenti:

wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"

Quanto sopra richiede un riavvio del server poiché fc_master_slave non è dinamico.

Abilita la modalità di debug per la registrazione di conflitti o deadlock

Il debug o la traccia dei problemi con il tuo cluster Galera è molto importante. I blocchi in Galera sono implementati in modo diverso rispetto a MySQL Replication. Utilizza il blocco ottimistico quando si tratta di transazioni a livello di cluster. A differenza di MySQL Replication, ha solo un blocco pessimistico che non sa se c'è una transazione simile o in conflitto eseguita in un co-master su una configurazione multi-master. Galera utilizza ancora il blocco pessimistico ma sul nodo locale poiché è gestito da InnoDB, che è il motore di archiviazione supportato. Galera usa il blocco ottimistico quando passa ad altri nodi. Ciò significa che non vengono effettuati controlli con altri nodi del cluster quando vengono raggiunti i blocchi locali (blocco pessimistico). Galera presuppone che, una volta che la transazione supera la fase di commit all'interno del motore di archiviazione e gli altri nodi vengono informati, tutto andrà bene e non si verificheranno conflitti.

In pratica, è meglio abilitare wsrep_logs_conflicts. Questo registrerà i dettagli di MDL in conflitto così come i blocchi InnoDB nel cluster. L'abilitazione di questa variabile può essere impostata in modo dinamico, ma un avvertimento una volta abilitata. Popolerà dettagliatamente il tuo file di registro degli errori e può riempire il tuo disco una volta che la dimensione del file di registro degli errori è troppo grande.

Fai attenzione con le tue query DDL

A differenza di MySQL Replication, l'esecuzione di un'istruzione ALTER può influire solo sulle connessioni in entrata che richiedono l'accesso o il riferimento a quella tabella presa di mira dall'istruzione ALTER. Può anche interessare gli slave se il tavolo è grande e può portare al ritardo dello slave. Tuttavia, le scritture sul tuo master non verranno bloccate fintanto che le tue query non sono in conflitto con l'ALTER corrente. Tuttavia, questo non è del tutto il caso quando si eseguono le istruzioni DDL come ALTER con Galera Cluster. Le istruzioni ALTER possono causare problemi come il blocco del cluster Galera a causa del blocco a livello di cluster o l'avvio del controllo del flusso per rilassare la replica mentre alcuni nodi si stanno riprendendo da scritture di grandi dimensioni.

In alcune situazioni, potresti avere tempi di inattività del tuo Galera Cluster se quella tabella è troppo grande ed è una tabella primaria e vitale per la tua applicazione. Tuttavia, può essere raggiunto senza tempi di fermo. Come ha sottolineato Rick James nel suo blog, puoi seguire i consigli seguenti:

RSU vs TOI

  • Aggiornamento in sequenza dello schema =esegui manualmente un nodo (offline) alla volta
  • Total Order Isolation =Galera si sincronizza in modo che venga eseguito contemporaneamente (nella sequenza di replica) su tutti i nodi. RSU e TOI

Attenzione:poiché non c'è modo di sincronizzare i client con il DDL, devi assicurarti che i client siano soddisfatti del vecchio o del nuovo schema. In caso contrario, probabilmente dovrai rimuovere l'intero cluster passando contemporaneamente allo schema e al codice client.

Un DDL "veloce" può anche essere eseguito tramite TOI. Questo è un elenco provvisorio di tali:

  • CREATE/DROP/RENAME DATABASE/TABLE
  • ALTER per cambiare DEFAULT
  • ALTER per modificare la definizione di ENUM o SET (vedi avvertenze nel manuale)
  • Alcuni PARTITION ALTER che sono veloci.
  • DROP INDEX (diverso da PRIMARY KEY)
  • AGGIUNGERE INDICE?
  • Altri ALTER su tavoli "piccoli".
  • Con 5.6 e soprattutto 5.7 con molti casi ALTER ALGORITHM=INPLACE, controlla quali ALTER dovrebbero essere eseguiti in che modo.

Altrimenti, usa RSU. Effettuare le seguenti operazioni separatamente per ciascun nodo:

SET GLOBAL wsrep_OSU_method='RSU';

Questo rimuove anche il nodo dal cluster.

ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';

Reinserisce, portando alla risincronizzazione (si spera un IST veloce, non un SST lento)

Preserva la consistenza del tuo cluster

Galera Cluster non supporta filtri di replica come binlog_do_db o binlog_ignore_db poiché Galera non si basa sulla registrazione binaria. Si basa sul file buffer ad anello chiamato anche GCache che memorizza i set di scritture che vengono replicati lungo il cluster. Non è possibile applicare alcun comportamento o stato incoerente di tali nodi di database.

Galera, d'altra parte, implementa rigorosamente la coerenza dei dati all'interno del cluster. È ancora possibile che ci possa essere incoerenza in cui non è possibile trovare righe o record. Ad esempio, l'impostazione della variabile wsrep_OSU_method RSU o TOI per le istruzioni DDL ALTER potrebbe comportare un comportamento incoerente. Controlla questo blog esterno di Percona che discute dell'incoerenza con Galera con TOI vs RSU.

Impostare wsrep_on=OFF e successivamente eseguire query DML o DDL può essere pericoloso per il tuo cluster. È inoltre necessario rivedere le procedure archiviate, i trigger, le funzioni, gli eventi o le viste se i risultati non dipendono dallo stato o dall'ambiente di un nodo. Quando uno o più nodi possono essere incoerenti, può potenzialmente portare l'intero cluster a non funzionare. Una volta che Galera rileva un comportamento incoerente, Galera tenterà di lasciare il cluster e terminare quel nodo. Quindi, è possibile che tutti i nodi possano essere incoerenti lasciandoti in uno stato di dilemma.

Se anche un nodo Galera Cluster subisce un arresto anomalo soprattutto in un periodo di traffico elevato, è meglio non avviare subito il nodo. Invece, esegui un SST completo o porta una nuova istanza il prima possibile o quando il traffico diminuisce. È possibile che il nodo possa portare un comportamento incoerente che potrebbe aver danneggiato i dati.

Separa le transazioni di grandi dimensioni e determina se utilizzare la replica in streaming 

Andiamo subito su questo. Una delle principali novità, soprattutto su Galera Cluster 4.0, è la replica in streaming. Versioni precedenti di Galera Cluster 4.0, limita le transazioni <2GiB che è in genere controllata dalle variabili wsrep_max_ws_rows e wsrep_max_ws_size. A partire da Galera Cluster 4.0, puoi inviare> 2GiB di transazioni ma devi determinare la dimensione dei frammenti da elaborare durante la replica. Deve essere impostato per sessione e le uniche variabili di cui devi fare attenzione sono wsrep_trx_fragment_unit e wsrep_trx_fragment_size. Disabilitare la replica in streaming è semplice poiché l'impostazione di wsrep_trx_fragment_size = 0 lo farà. Tieni presente che, la replica di una transazione di grandi dimensioni comporta anche un sovraccarico sui nodi slave (nodi che si replicano sul nodo master/master attivo) poiché i log verranno scritti nella tabella wsrep_streaming_log nel database MySQL.

Un'altra cosa da aggiungere, dal momento che hai a che fare con una transazione di grandi dimensioni, è considerevole che la transazione potrebbe richiedere del tempo per terminare, quindi è necessario tenere in considerazione l'impostazione della variabile innodb_lock_wait_timeout alta. Impostalo tramite sessione a seconda del tempo stimato ma maggiore del tempo stimato per la fine, altrimenti aumenta un timeout.

Ti consigliamo di leggere questo blog precedente sulla replica in streaming in azione.

Replica dichiarazioni GRANTs

Se stai usando GRANT e operazioni correlate, agisci sulle tabelle MyISAM/Aria nel database `mysql`. Le istruzioni GRANT verranno replicate, ma non le tabelle sottostanti. Quindi questo significa, INSERT INTO mysql.user ... non verrà replicato perché la tabella è MyISAM.

Tuttavia, quanto sopra potrebbe non essere più vero da Percona XtraDB Cluster(PXC) 8.0 (attualmente sperimentale) poiché le tabelle dello schema MySQL sono state convertite in InnoDB, mentre in MariaDB 10.4, alcune delle tabelle sono ancora in formato Aria ma altri sono in CSV o InnoDB. Dovresti determinare quale versione e provider di Galera hai, ma è meglio evitare di usare istruzioni DML che fanno riferimento allo schema mysql. In caso contrario, potresti ottenere risultati imprevisti a meno che tu non sia sicuro che si tratti di PXC 8.0.

Transazioni XA, LOCK/UNLOCK TABLES, GET_LOCK/RELEASE_LOCK non sono supportati

Galera Cluster non supporta XA Transactions poiché XA Transactions gestisce il rollback e si impegna in modo diverso. Le istruzioni LOCK/UNLOCK o GET_LOCK/RELEASE_LOCK sono pericolose da applicare o utilizzare con Galera. Potresti riscontrare un arresto anomalo o blocchi che non sono uccidibili e rimangono bloccati. Ad esempio,

---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec

mysql tables in use 2, locked 2

3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5

MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)

insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5

Questa transazione è già stata sbloccata ed è stata persino uccisa, ma senza alcun risultato. Ti consigliamo di riprogettare il client dell'applicazione e di eliminare queste funzioni durante la migrazione a Galera Cluster.

La stabilità della rete è un MUST!!!

Galera Cluster può funzionare anche con topologia inter-WAN o inter-geo senza problemi (controlla questo blog sull'implementazione della topologia inter-geo con Galera). Tuttavia, se la connettività di rete tra ciascun nodo non è stabile o si interrompe in modo intermittente per un periodo di tempo imprevisto, può essere problematico per il cluster. È meglio avere un cluster in esecuzione in una rete privata e locale in cui ciascuno di questi nodi è connesso. Quando si progetta un nodo come ripristino di emergenza, pianificare la creazione di un cluster se questi si trovano in una regione o area geografica diversa. Puoi iniziare a leggere il nostro blog precedente, Utilizzo della replica del cluster MySQL Galera per creare un cluster geo-distribuito:parte uno, in quanto ciò potrebbe aiutarti a decidere al meglio la topologia del tuo cluster Galera.

Un'altra cosa da aggiungere sull'investimento dell'hardware di rete, sarebbe problematico se la velocità di trasferimento della rete fornisse una velocità inferiore durante la ricostruzione di un'istanza durante IST o peggio in SST, specialmente se il set di dati è enorme . Possono essere necessarie lunghe ore di trasferimento di rete e ciò potrebbe influire sulla stabilità del tuo cluster, soprattutto se hai un cluster a 3 nodi mentre 2 nodi non sono disponibili dove questi 2 sono un donatore e un joiner. Tieni presente che, durante la fase SST, i nodi DONOR/JOINER non possono essere utilizzati fino a quando non sarà finalmente in grado di sincronizzarsi con il cluster primario.

Nella versione precedente di Galera, quando si trattava di selezionare il nodo donatore, il donatore State Snapshot Transfer (SST) veniva selezionato a caso. In Glera 4, è molto più migliorato e ha la possibilità di scegliere il donatore giusto all'interno del cluster, poiché favorirà un donatore che può fornire un trasferimento di stato incrementale (IST) o scegliere un donatore nello stesso segmento. In alternativa, puoi impostare la variabile wsrep_sst_donar sul donatore giusto che vorresti selezionare sempre.

Esegui il backup dei dati ed esegui test rigidi durante la migrazione e prima della produzione

Una volta che sei pronto e hai deciso di provare a migrare i tuoi dati su Galera Cluster 4.0, assicurati di avere sempre preparato il tuo backup. Se hai provato ClusterControl, sarà più facile eseguire i backup.

Assicurati di migrare alla versione corretta di InnoDB e non dimenticare di applicare ed eseguire sempre mysql_upgrade prima di eseguire il test. Assicurati che tutti i tuoi test superino il risultato desiderato da cui MySQL Replication può offrirti. Molto probabilmente, non c'è alcuna differenza tra il motore di archiviazione InnoDB che stai utilizzando in un MySQL Replication Cluster e il MySQL Galera Cluster, a condizione che i consigli e i suggerimenti siano stati applicati e preparati in anticipo.

Conclusione

La migrazione a Galera Cluster 4.0 potrebbe non essere la soluzione tecnologica di database desiderata. Tuttavia, non ti sta spingendo a utilizzare Galera Cluster 4.0 fintanto che i suoi requisiti specifici possono essere preparati, configurati e forniti. Galera Cluster 4.0 è ora diventata una scelta e un'opzione praticabili molto potenti, specialmente su una piattaforma e una soluzione ad alta disponibilità. Ti suggeriamo inoltre di leggere questi blog esterni su Galera Caveats o Limitations of Galera Cluster o questo manuale di MariaDB.