MySQL non limita il numero di slave che puoi connettere al server master in una topologia di replica. Tuttavia, con l'aumento del numero di slave, avranno un pedaggio sulle risorse master perché i registri binari dovranno essere serviti a diversi slave che lavorano a velocità diverse. Se l'abbandono dei dati sul master è elevato, il solo servizio di log binari potrebbe saturare l'interfaccia di rete del master.
Una soluzione classica per questo problema è distribuire un server binlog, un server proxy intermedio che si trova tra il master e i suoi slave. Il server binlog è impostato come slave per il master e, a sua volta, funge da master per il set originale di slave. Riceve eventi di log binari dal master, non applica questi eventi, ma li serve a tutti gli altri slave. In questo modo, il carico sul master viene enormemente ridotto e, allo stesso tempo, il server binlog serve i binlog in modo più efficiente agli slave poiché non deve eseguire altre elaborazioni del server di database.
Ripple è un server binlog open source sviluppato da Pavel Ivanov. Un post sul blog di Percona, intitolato MySQL Ripple:The First Impression of a MySQL Binlog Server, offre un'ottima introduzione alla distribuzione e all'utilizzo di Ripple. Ho avuto l'opportunità di esplorare Ripple in modo più dettagliato e volevo condividere le mie osservazioni attraverso questo post.
1. Supporto per la replica basata su GTID
Ripple supporta solo la modalità GTID e non la replica basata su file e posizione. Se il tuo master è in esecuzione in modalità non GTID, riceverai questo errore da Ripple:
Impossibile leggere il pacchetto:si è verificato un errore durante la lettura del pacchetto dal server:il thread del mittente della replica non può essere avviato in modalità AUTO_POSITION:questo server ha GTID_MODE =OFF anziché ON.
Puoi specificare Server_id e UUID per il server ripple utilizzando le opzioni della riga cmd: -ripple_server_id e -ripple_server_uuid
Entrambi sono parametri opzionali e, se non specificati, Ripple utilizzerà il server_id predefinito=112211 e uuid verrà generato automaticamente.
2. Connessione al master tramite utente e password di replica
Durante la connessione al master, puoi specificare l'utente e la password di replica utilizzando le opzioni della riga di comando:
-ripple_master_user e -ripple_master_password
3. Endpoint di connessione per il server Ripple
Puoi usare le opzioni della riga di comando -ripple_server_ports e -ripple_server_address per specificare i punti finali di connessione per il server Ripple. Assicurati di specificare il nome host o l'indirizzo IP accessibile dalla rete del tuo server Ripple come -rippple_server_address. Altrimenti, per impostazione predefinita, Ripple si legherà a localhost e quindi non sarai in grado di connetterti ad esso in remoto.
4. Configurazione degli slave sul server Ripple
Puoi usare il comando CHANGE MASTER TO per connettere i tuoi slave da replicare dal server Ripple.
Per assicurarti che Ripple possa autenticare la password che usi per connetterti, devi avviare Ripple specificando l'opzione -ripple_server_password_hash
Ad esempio, se avvii il server ripple con il comando:
rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip> -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'
puoi usare il seguente comando CHANGE MASTER TO per connetterti dallo slave:
CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’
Si noti che l'hash della password specificato per il server Ripple corrisponde alla password di testo utilizzata nel comando CHANGE MASTER TO. Attualmente, Ripple non si autentica in base ai nomi utente e accetta qualsiasi nome utente non vuoto purché la password corrisponda.
Esplorazione di MySQL Binlog Server - RippleClick To Tweet5. Gestione del server Ripple
È possibile monitorare e gestire il server Ripple utilizzando il protocollo MySQL da qualsiasi client MySQL standard. Sono supportati un set limitato di comandi che puoi vedere direttamente nel codice sorgente sulla pagina GitHub di mysql-ripple.
Alcuni dei comandi utili sono:
SELECT @@global.gtid_executed;– Per vedere il GTID SET del server Ripple in base ai log binari scaricati.STOP SLAVE;– Per disconnettere il server Ripple dal master.START SLAVE;– Per collegare il server Ripple al master.
Problemi noti e suggerimenti per il miglioramento
1. Non ho visto un'opzione per configurare un canale di replica SSL da un server Ripple al master
Di conseguenza, il server Ripple non sarà in grado di connettersi a un master che richiede connessioni crittografate. Il tentativo di connessione risulterà nell'errore:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Failed to connected to host: <Hosname>, port: 3306, err: Failed to connect: Connections using insecure transport are prohibited while --require_secure_transport=ON.
2. Non sono riuscito a far funzionare il server Ripple con l'opzione di semisincronizzazione
Ho avviato il server Ripple utilizzando l'opzione -ripple_semi_sync_slave_enabled=true
Al momento della connessione, il master è stato in grado di rilevare il server Ripple come slave abilitato alla semisincronizzazione.
mysql> show status like 'rpl%';
------------------------------------------------------
| Variable_name | Value |
------------------------------------------------------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | ON |
| Rpl_semi_sync_slave_status | OFF |
------------------------------------------------------
Tuttavia, il tentativo di eseguire una transazione in modalità semi-sincronizzazione ha atteso rpl_semi_sync_master_timeout che era 180000
mysql> create database d12;
Query OK, 1 row affected (3 min 0.01 sec)
Ho visto che la semi-sincronizzazione è stata disattivata sul master:
mysql> show status like 'rpl%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | OFF |
| Rpl_semi_sync_slave_status | OFF |
+--------------------------------------------+-------+
Snippet corrispondente dai log degli errori di MySQL:
2020-03-21T10:05:56.000612Z 52 [Note] Start binlog_dump to master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [Note] Start semi-sync binlog_dump to slave (server_id: 112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000010, pos: 350), semi-sync up to file , position 4.
2020-03-21T10:08:55.874044Z 2 [Note] Semi-sync replication switched OFF.
C'è un problema segnalato in modo simile qui sulla pagina MySQL Ripple Github.
3. Problema durante l'utilizzo della replica parallela per gli slave del server Ripple
Ho visto che il thread SQL sullo slave si interrompeva spesso con l'errore:
Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name /mysql_data/relaylogs/relay-log.000005, position 27023962 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly.
L'analisi del registro di inoltro e della posizione sopra ha rivelato che il "numero di sequenza" della transazione a questo punto è stato reimpostato su 1. Ho rintracciato la causa in una rotazione del binlog che si verificava sul maestro originale. Tipicamente, per gli slave diretti, c'è un evento di rotazione a causa del quale anche i registri del relè ruoterebbero in base alla rotazione del registro binario master. La mia valutazione è che tali condizioni possono essere rilevate e il ripristino del numero di sequenza può essere gestito da thread paralleli. Ma quando il numero di sequenza cambia senza la rotazione dei log di inoltro, vediamo che i thread paralleli falliscono.
Questa osservazione viene segnalata come il problema:errore del thread parallelo slave durante la sincronizzazione dal server binlog n. 26
4. L'utilità mysqlbinlog non funziona sui log binari prodotti dal server Ripple
Il tentativo di eseguire l'utilità mysqlbinlog sul registro binario ha provocato l'errore:
ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 43, event_type: -106
Questo problema viene sollevato qui:non è possibile aprire i file di registro binari utilizzando l'utilità mysqlbinlog. #25
È riconosciuto dall'autore come problema noto. Ritengo che sarebbe utile supportare questa utilità per scopi di debug.
Questo è il rapporto per ora del mio rapido test. Ho intenzione di aggiornare questo post sul blog man mano che mi imbatterò in ulteriori risultati su Ripple. Nel complesso, l'ho trovato semplice e diretto da usare e ha il potenziale per diventare uno standard per i server binlog in ambienti MySQL.
|
