Ricerca nel sito web

Come impostare la replica in MySQL

Una versione precedente di questo tutorial è stata scritta da Etel Sverdlov.

introduzione

Quando si lavora con i database, può essere utile disporre di più copie dei dati. Ciò fornisce ridondanza in caso di guasto di uno dei server di database e può migliorare la disponibilità, la scalabilità e le prestazioni complessive di un database. La pratica di sincronizzare i dati su più database separati è chiamata replica.

MySQL è un sistema di gestione di database relazionali ed è oggi il database relazionale open source più popolare al mondo. Viene installato con una serie di funzionalità di replica integrate, che consentono di conservare più copie dei dati.

Questo tutorial illustra come configurare un'istanza MySQL su un server come database di origine e quindi configurare un'istanza MySQL su un altro server in modo che funzioni come sua replica. Include anche una panoramica su come MySQL gestisce la replica.

Nota: Storicamente, questo tipo di replica del database è stato indicato come replica \master-slave. In un post sul blog pubblicato nel luglio del 2020, il team di MySQL ha riconosciuto l'origine negativa di questa terminologia e ha annunciato i propri sforzi per aggiornare il database programma e la sua documentazione per utilizzare un linguaggio più inclusivo.

Tuttavia, questo è un processo in corso. Sebbene la documentazione di MySQL e gran parte dei comandi nella versione 8 del programma siano stati aggiornati per fare invece riferimento ai server in una topologia di replica come la sorgente e le sue repliche , ci sono luoghi in cui appare ancora la terminologia negativa. Questa guida utilizzerà per impostazione predefinita la terminologia source-replica più inclusiva, ove possibile, ma ci sono alcuni casi in cui i termini più vecchi inevitabilmente emergono.

Prerequisiti

Per completare questa guida avrai bisogno di:

  • Due server che eseguono Ubuntu 20.04. Entrambi dovrebbero avere un utente amministrativo non root con privilegi sudo e un firewall configurato con UFW. Segui la nostra guida alla configurazione iniziale del server per Ubuntu 20.04 per configurare entrambi i server.
  • MySQL installato su ciascun server. Questa guida presuppone che tu stia utilizzando l'ultima versione di MySQL disponibile dai repository Ubuntu predefiniti che, al momento della stesura di questo documento, è la versione 8.0.25. Per installarlo su entrambi i server, segui la nostra guida su Come installare MySQL su Ubuntu 20.04.

Tieni presente che la procedura delineata in questa guida comporta la designazione dell'installazione di MySQL su un server come database di origine e quindi la configurazione dell'installazione di MySQL sull'altro server come replica dell'origine . Per mantenere le cose chiare, tutti i comandi che devono essere eseguiti sul server del database di origine avranno uno sfondo blu, come questo:

  1.

Allo stesso modo, tutti i comandi che devono essere eseguiti sul server dell'istanza MySQL di replica avranno uno sfondo rosso:

  1.

Infine, questa esercitazione include istruzioni facoltative su come eseguire la migrazione dei dati in un database esistente dall'origine alla replica. Questo processo prevede la creazione di uno snapshot del database di origine e la copia del file risultante nella replica. Per fare ciò, ti consigliamo di configurare le chiavi SSH sul server del server di origine e quindi assicurarti che la chiave pubblica dell'origine sia stata copiata nella replica.

Comprensione della replica in MySQL

In MySQL, la replica prevede che il database di origine annoti ogni modifica apportata ai dati contenuti in uno o più database in un file speciale noto come registro binario. Una volta che l'istanza di replica è stata inizializzata, crea due processi con thread. Il primo, chiamato thread IO, si connette all'istanza MySQL di origine e legge gli eventi del log binario riga per riga, quindi li copia in un file locale sul server della replica chiamato relay log. Il secondo thread, chiamato thread SQL, legge gli eventi dal log di inoltro e li applica all'istanza di replica il più velocemente possibile.

Le versioni recenti di MySQL supportano due metodi per replicare i dati. La differenza tra questi metodi di replica ha a che fare con il modo in cui le repliche tengono traccia degli eventi del database dall'origine che hanno già elaborato.

MySQL fa riferimento al suo metodo di replica tradizionale come replica basata sulla posizione del file di registro binario. Quando trasformi un'istanza MySQL in una replica utilizzando questo metodo, devi fornirle un set di coordinate di log binario. Questi consistono nel nome del file di log binario sull'origine che la replica deve leggere e in una posizione specifica all'interno di quel file che rappresenta il primo evento del database che la replica deve copiare nella propria istanza MySQL.

Queste coordinate sono importanti poiché le repliche ricevono una copia dell'intero registro binario della loro origine e, senza le giuste coordinate, inizieranno a replicare ogni evento del database registrato al suo interno. Ciò può causare problemi se si desidera replicare i dati solo dopo un determinato momento o se si desidera replicare solo un sottoinsieme dei dati di origine.

La replica basata sulla posizione del file di registro binario è praticabile per molti casi d'uso, ma questo metodo può diventare goffo in configurazioni più complesse. Ciò ha portato allo sviluppo del nuovo metodo di replica nativo di MySQL, a volte indicato come replica basata sulle transazioni. Questo metodo comporta la creazione di un identificatore di transazione globale (GTID) per ogni transazione, o un pezzo di lavoro isolato eseguito da un database, eseguito dall'istanza MySQL di origine.

I meccanismi della replica basata su transazione sono simili alla replica basata su file di registro binario: ogni volta che si verifica una transazione di database sull'origine, MySQL assegna e registra un GTID per la transazione nel file di registro binario insieme alla transazione stessa. Il GTID e la transazione vengono quindi trasmessi alle repliche dell'origine affinché vengano elaborati.

La replica basata sulle transazioni di MySQL ha una serie di vantaggi rispetto al suo metodo di replica tradizionale. Ad esempio, poiché sia un'origine che le relative repliche conservano i GTID, se l'origine o una replica incontrano una transazione con un GTID che hanno elaborato prima, salteranno tale transazione. Ciò consente di garantire la coerenza tra l'origine e le relative repliche. Inoltre, con la replica basata sulle transazioni, le repliche non hanno bisogno di conoscere le coordinate del registro binario del successivo evento del database da elaborare. Ciò significa che l'avvio di nuove repliche o la modifica dell'ordine delle repliche in una catena di replica è molto meno complicato.

Tieni presente che questa è solo una spiegazione generale di come MySQL gestisce la replica; MySQL offre molte opzioni che puoi modificare per ottimizzare la tua configurazione di replica. Questa guida illustra come configurare la replica basata sulla posizione del file di registro binario. Se sei interessato a configurare un diverso tipo di ambiente di replica, ti invitiamo a consultare la documentazione ufficiale di MySQL .

Passaggio 1: regolazione del firewall del server di origine

Supponendo che tu abbia seguito il prerequisito Guida all'installazione iniziale del server, avrai configurato un firewall su entrambi i tuoi server con UFW. Ciò contribuirà a proteggere entrambi i server, ma il firewall dell'origine bloccherà qualsiasi tentativo di connessione dall'istanza MySQL di replica.

Per modificare questa impostazione, dovrai includere una regola UFW che consenta le connessioni dalla tua replica attraverso il firewall dell'origine. Puoi farlo eseguendo un comando come il seguente sul tuo server di origine.

Questo particolare comando consente tutte le connessioni che hanno origine dall'indirizzo IP del server di replica — rappresentato da replica_server_ip — al numero di porta predefinito di MySQL, 3306:

  1. sudo ufw allow from replica_server_ip to any port 3306

Assicurati di sostituire replica_server_ip con l'effettivo indirizzo IP del tuo server di replica. Se la regola è stata aggiunta correttamente, vedrai il seguente output:

Output
Rule added

Successivamente, non sarà necessario apportare alcuna modifica alle regole del firewall della replica, poiché il server di replica non riceverà alcuna connessione in entrata e le connessioni in uscita al server MySQL di origine non sono bloccate da UFW. Puoi passare all'aggiornamento della configurazione dell'istanza MySQL di origine per abilitare la replica.

Passaggio 2: configurazione del database di origine

Affinché il database MySQL di origine inizi a replicare i dati, è necessario apportare alcune modifiche alla sua configurazione.

Su Ubuntu 20.04, il file di configurazione predefinito del server MySQL è denominato mysqld.cnf e può essere trovato nella directory /etc/mysql/mysql.conf.d/. Apri questo file sul server di origine con il tuo editor di testo preferito. Qui useremo nano:

  1. sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

All'interno del file, trova la direttiva bind-address. Sarà simile a questo per impostazione predefinita:

. . .
bind-address            = 127.0.0.1
. . .

127.0.0.1 è un indirizzo di loopback IPv4 che rappresenta localhost e impostandolo come valore per la direttiva bind-address istruisce MySQL ad ascoltare solo le connessioni sull'indirizzo localhost. In altre parole, questa istanza MySQL sarà in grado di accettare solo connessioni che provengono dal server su cui è installata.

Ricorda che stai trasformando l'altra tua istanza MySQL in una replica di questa, quindi la replica deve essere in grado di leggere qualunque nuovo dato venga scritto nell'installazione di origine. Per consentire ciò, è necessario configurare l'istanza MySQL di origine in modo che ascolti le connessioni su un indirizzo IP che la replica sarà in grado di raggiungere, ad esempio l'indirizzo IP pubblico del server di origine.

Sostituisci 127.0.0.1 con l'indirizzo IP del server di origine. Dopo averlo fatto, la direttiva bind-address avrà questo aspetto, con l'indirizzo IP del tuo server al posto di source_server_ip:

. . .
bind-address            = source_server_ip
. . .

Successivamente, trova la direttiva server-id, che definisce un identificatore che MySQL utilizza internamente per distinguere i server in una configurazione di replica. Ogni server in un ambiente di replica, inclusa l'origine e tutte le sue repliche, deve avere il proprio valore server-id univoco. Questa direttiva sarà commentata per impostazione predefinita e sarà simile a questa:

. . .
# server-id             = 1
. . .

Rimuovere il commento da questa riga rimuovendo il cancelletto (#). Puoi scegliere qualsiasi numero come valore di questa direttiva, ma ricorda che il numero deve essere univoco e non può corrispondere a nessun altro server-id nel tuo gruppo di replica. Per semplificare le cose, il seguente esempio lascia questo valore come predefinito, 1:

. . .
server-id               = 1
. . .

Sotto la riga server-id, trova la direttiva log_bin. Questo definisce il nome di base e la posizione del file di log binario di MySQL.

Quando è commentato, poiché questa direttiva è per impostazione predefinita, la registrazione binaria è disabilitata. Il tuo server di replica deve leggere il file di log binario dell'origine in modo da sapere quando e come replicare i dati dell'origine, quindi decommenta questa riga per abilitare la registrazione binaria sull'origine. Dopo averlo fatto, sarà simile a questo:

. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

Infine, scorri verso il basso fino alla fine del file per trovare la direttiva binlog_do_db commentata:

. . .
# binlog_do_db          = include_database_name

Rimuovi il cancelletto per rimuovere il commento da questa riga e sostituisci include_database_name con il nome del database che vuoi replicare. Questo esempio mostra la direttiva binlog_do_db che punta a un database chiamato db, ma se hai un database esistente sulla tua sorgente che vuoi replicare, usa il suo nome al posto di db:

. . .
binlog_do_db          = db

Nota: se desideri replicare più di un database, puoi aggiungere un'altra direttiva binlog_do_db per ogni database che desideri aggiungere. Questo tutorial continuerà con la replica di un solo database, ma se volessi replicarne di più potrebbe assomigliare a questo:

. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2

In alternativa, puoi specificare quali database MySQL non dovrebbe replicare aggiungendo una direttiva binlog_ignore_db per ciascuno di essi:

. . .
binlog_ignore_db          = db_to_ignore

Dopo aver apportato queste modifiche, salva e chiudi il file. Se hai utilizzato nano per modificare il file, fallo premendo CTRL + X, Y e poi INVIO .

Quindi riavviare il servizio MySQL eseguendo il seguente comando:

  1. sudo systemctl restart mysql

Con ciò, questa istanza MySQL è pronta per funzionare come database di origine che verrà replicato dall'altro server MySQL. Prima di poter configurare la replica, tuttavia, ci sono ancora alcuni passaggi da eseguire sull'origine per garantire che la topologia di replica funzioni correttamente. Il primo di questi è creare un utente MySQL dedicato che eseguirà tutte le azioni relative al processo di replica.

Passaggio 3: creazione di un utente di replica

Ogni replica in un ambiente di replica MySQL si connette al database di origine con un nome utente e una password. Le repliche possono connettersi utilizzando qualsiasi profilo utente MySQL che esiste nel database di origine e dispone dei privilegi appropriati, ma questo tutorial illustrerà come creare un utente dedicato per questo scopo.

Inizia aprendo la shell MySQL:

  1. sudo mysql

Nota: se hai configurato un utente MySQL dedicato che si autentica utilizzando una password, puoi invece connetterti a MySQL con un comando come questo:

  1. mysql -u sammy -p

Sostituisci sammy con il nome del tuo utente dedicato e inserisci la password di questo utente quando richiesto.

Tenere presente che alcune operazioni in questa guida, incluse alcune che devono essere eseguite sul server di replica, richiedono privilegi avanzati. Per questo motivo, potrebbe essere più conveniente connettersi come utente amministrativo, come è possibile con il precedente comando sudo mysql. Tuttavia, se desideri utilizzare un utente MySQL meno privilegiato in questa guida, dovresti almeno concedergli CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE e REPLICATION_SLAVE_ADMIN privilegi.

Dal prompt, crea un nuovo utente MySQL. L'esempio seguente creerà un utente chiamato replica_user, ma puoi nominare il tuo come preferisci. Assicurati di cambiare replica_server_ip con l'indirizzo IP pubblico del tuo server di replica e di cambiare la password con una password complessa del tuo scegliendo:

  1. CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

Tieni presente che questo comando specifica che replica_user utilizzerà il plug-in di autenticazione mysql_native_password. È possibile utilizzare invece il meccanismo di autenticazione predefinito di MySQL, caching_sha2_password, ma ciò richiederebbe l'impostazione di una connessione crittografata tra l'origine e la replica. Questo tipo di configurazione sarebbe ottimale per gli ambienti di produzione, ma la configurazione delle connessioni crittografate esula dall'ambito di questa esercitazione. La documentazione di MySQL include istruzioni su come configurare un ambiente di replica che utilizza connessioni crittografate se desideri configurarlo.

Dopo aver creato il nuovo utente, concedigli i privilegi appropriati. Come minimo, un utente di replica MySQL deve disporre delle autorizzazioni REPLICATION SLAVE:

  1. GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

Successivamente, è buona norma eseguire il comando FLUSH PRIVILEGES. Ciò libererà tutta la memoria che il server ha memorizzato nella cache come risultato delle precedenti istruzioni CREATE USER e GRANT:

  1. FLUSH PRIVILEGES;

Con ciò, hai finito di configurare un utente di replica sulla tua istanza MySQL di origine. Tuttavia, non uscire dalla shell MySQL. Tienilo aperto per ora, poiché lo utilizzerai nel passaggio successivo per ottenere alcune informazioni importanti sul file di registro binario del database di origine.

Passaggio 4: recupero delle coordinate del registro binario dalla sorgente

Ricordiamo dalla sezione Understanding Replication in MySQL che MySQL implementa la replica copiando gli eventi del database dal file di log binario dell'origine riga per riga e implementando ogni evento sulla replica. Quando si utilizza la replica basata sulla posizione del file di registro binario di MySQL, è necessario fornire alla replica un insieme di coordinate che descrivono in dettaglio il nome del file di registro binario di origine e una posizione specifica all'interno di tale file. La replica utilizza quindi queste coordinate per determinare il punto nel file di registro da cui deve iniziare a copiare gli eventi del database e tenere traccia degli eventi che ha già elaborato.

Questo passaggio illustra come ottenere le coordinate del log binario corrente dell'istanza di origine per impostare le repliche in modo che inizino a replicare i dati dall'ultimo punto nel file di log. Per assicurarti che nessun utente modifichi i dati mentre recuperi le coordinate, il che potrebbe causare problemi, dovrai bloccare il database per impedire a qualsiasi client di leggere o scrivere dati mentre ottieni le coordinate. Sbloccherai tutto a breve, ma questa procedura causerà un certo periodo di inattività del tuo database.

Dovresti comunque avere la shell MySQL del tuo server di origine aperta dalla fine del passaggio precedente. Dal prompt, esegui il seguente comando che chiuderà tutte le tabelle aperte in ogni database sull'istanza di origine e le bloccherà:

  1. FLUSH TABLES WITH READ LOCK;

Quindi eseguire la seguente operazione che restituirà le informazioni sullo stato corrente per i file di registro binario dell'origine:

  1. SHOW MASTER STATUS;

Vedrai una tabella simile a questo esempio nel tuo output:

Output
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      899 | db           |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Questa è la posizione da cui la replica inizierà a copiare gli eventi del database. Registra il nome File e il valore Position, poiché ti serviranno in seguito quando avvierai la replica.

Quello che fai subito dopo aver ottenuto queste informazioni dipende dal fatto che il tuo database di origine disponga di dati esistenti che desideri migrare alle tue repliche. Passa a qualsiasi delle due seguenti sottosezioni abbia più senso per la tua situazione.

Se la tua fonte non ha dati esistenti da migrare

Se la tua istanza MySQL di origine è una nuova installazione o non dispone di dati esistenti che desideri migrare alle tue repliche, puoi a questo punto sbloccare le tabelle:

  1. UNLOCK TABLES;

Se non lo hai già fatto, puoi creare il database che hai scelto di replicare mentre hai ancora la shell MySQL aperta. In linea con l'esempio fornito nel passaggio 2, la seguente operazione creerà un database denominato db:

  1. CREATE DATABASE db;



Output
Query OK, 1 row affected (0.01 sec)

Successivamente, chiudi la shell MySQL:

  1. exit

Successivamente, puoi passare al passaggio successivo.

Se la tua fonte ha dati esistenti da migrare

Se disponi di dati sull'istanza MySQL di origine che desideri migrare alle tue repliche, puoi farlo creando un'istantanea del database con l'utilità mysqldump. Tuttavia, il tuo database dovrebbe essere ancora attualmente bloccato. Se apporti nuove modifiche nella stessa finestra, il database si sbloccherà automaticamente. Allo stesso modo, i tavoli si sbloccheranno automaticamente se esci dal client.

Lo sblocco delle tabelle potrebbe causare problemi poiché significherebbe che i client potrebbero modificare nuovamente i dati nel database. Ciò potrebbe potenzialmente portare a una mancata corrispondenza tra l'istantanea dei dati e le coordinate del registro binario appena recuperate.

Per questo motivo, è necessario aprire una nuova finestra o scheda del terminale sul computer locale in modo da poter creare l'istantanea del database senza sbloccare MySQL.

Dalla nuova finestra o scheda del terminale, apri un'altra sessione SSH al server che ospita la tua istanza MySQL di origine:

  1. ssh sammy@source_server_ip

Poi, dalla nuova scheda o finestra, esporta il tuo database usando mysqldump. L'esempio seguente crea un file dump denominato db.sql da un database denominato db, ma assicurati di includere invece il nome del tuo database. Inoltre, assicurati di eseguire questo comando nella shell bash, non nella shell MySQL:

  1. sudo mysqldump -u root db > db.sql

Successivamente puoi chiudere questa finestra o scheda del terminale e tornare alla prima, che dovrebbe avere ancora la shell MySQL aperta. Dal prompt di MySQL, sblocca i database per renderli nuovamente scrivibili:

  1. UNLOCK TABLES;

Quindi puoi uscire dalla shell MySQL:

  1. exit

È ora possibile inviare il file dell'istantanea al server di replica. Supponendo che tu abbia configurato le chiavi SSH sul tuo server di origine e abbia aggiunto la chiave pubblica dell'origine al file authorized_keys della tua replica, puoi farlo in modo sicuro con un comando scp come questo:

  1. scp db.sql sammy@replica_server_ip:/tmp/

Assicurati di sostituire sammy con il nome del profilo utente Ubuntu amministrativo che hai creato sul tuo server di replica e di sostituire replica_server_ip con l'indirizzo IP del server di replica. Inoltre, tieni presente che questo comando posiziona lo snapshot nella directory /tmp/ del server di replica.

Dopo aver inviato lo snapshot al server di replica, SSH in esso:

  1. ssh sammy@replica_server_ip

Quindi apri la shell MySQL:

  1. sudo mysql

Dal prompt, crea il nuovo database che replicherai dall'origine:

  1. CREATE DATABASE db;

Non è necessario creare alcuna tabella o caricare questo database con dati di esempio. Tutto ciò verrà risolto quando importi il database utilizzando l'istantanea che hai appena creato. Invece, esci dalla shell MySQL:

  1. exit

Quindi importa lo snapshot del database:

  1. sudo mysql db < /tmp/db.sql

La tua replica ora ha tutti i dati esistenti dal database di origine. È possibile completare il passaggio finale di questa guida per configurare il server di replica per iniziare a replicare le nuove modifiche apportate al database di origine.

Passaggio 5: configurazione del database di replica

Tutto ciò che resta da fare è modificare la configurazione della replica in modo simile a come hai modificato la sorgente. Apri il file di configurazione di MySQL, mysqld.cnf, questa volta sul tuo server di replica:

  1. sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Come accennato in precedenza, ogni istanza MySQL in una configurazione di replica deve avere un valore server-id univoco. Trova la direttiva server-id della replica, decommentala e cambia il suo valore in qualsiasi numero intero positivo, purché sia diverso da quello dell'origine:

server-id               = 2

Successivamente, aggiorna i valori log_bin e binlog_do_db in modo che siano allineati con i valori impostati nel file di configurazione della macchina di origine:

. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

Infine, aggiungi una direttiva relay-log che definisce la posizione del file di registro di inoltro della replica. Includere la seguente riga alla fine del file di configurazione:

. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

Dopo aver apportato queste modifiche, salva e chiudi il file. Quindi riavvia MySQL sulla replica per implementare la nuova configurazione:

  1. sudo systemctl restart mysql

Dopo aver riavviato il servizio mysql, sei finalmente pronto per iniziare a replicare i dati dal tuo database di origine.

Passaggio 6: avvio e verifica della replica

A questo punto, entrambe le istanze MySQL sono completamente configurate per consentire la replica. Per iniziare a replicare i dati dalla tua fonte, apri la shell MySQL sul tuo server di replica:

  1. sudo mysql

Dal prompt, eseguire la seguente operazione, che configura contemporaneamente diverse impostazioni di replica MySQL. Dopo aver eseguito questo comando, una volta abilitata la replica su questa istanza, proverà a connettersi all'indirizzo IP seguente SOURCE_HOST utilizzando il nome utente e la password seguenti SOURCE_USER e SOURCE_PASSWORD< /codice>, rispettivamente. Cercherà anche un file di log binario con il nome che segue SOURCE_LOG_FILE e inizierà a leggerlo dalla posizione dopo SOURCE_LOG_POS.

Assicurati di sostituire source_server_ip con l'indirizzo IP del tuo server di origine. Allo stesso modo, replica_user e password dovrebbero essere allineati con l'utente di replica che hai creato nel passaggio 2; e mysql-bin.000001 e 899 dovrebbero riflettere le coordinate del log binario ottenute nel passaggio 3.

Potresti voler digitare questo comando in un editor di testo prima di eseguirlo sul tuo server di replica in modo da poter sostituire più facilmente tutte le informazioni rilevanti:

  1. CHANGE REPLICATION SOURCE TO

  2. SOURCE_HOST='source_server_ip',

  3. SOURCE_USER='replica_user',

  4. SOURCE_PASSWORD='password',

  5. SOURCE_LOG_FILE='mysql-bin.000001',

  6. SOURCE_LOG_POS=899;

Successivamente, attiva il server di replica:

  1. START REPLICA;

Se hai inserito correttamente tutti i dettagli, questa istanza inizierà a replicare tutte le modifiche apportate al database db sull'origine.

Puoi visualizzare i dettagli sullo stato corrente della replica eseguendo la seguente operazione. Il modificatore \G in questo comando riorganizza il testo per renderlo più leggibile:

  1. SHOW REPLICA STATUS\G;

Questo comando restituisce molte informazioni che possono essere utili durante la risoluzione dei problemi:

Output
*************************** 1. row ***************************
             Replica_IO_State: Waiting for master to send event
                  Source_Host: 138.197.3.190
                  Source_User: replica_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000001
          Read_Source_Log_Pos: 1273
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 729
        Relay_Source_Log_File: mysql-bin.000001
. . .

Nota: se la replica presenta un problema di connessione o la replica si interrompe in modo imprevisto, è possibile che un evento nel file di log binario dell'origine stia impedendo la replica. In questi casi, puoi eseguire il comando SET GLOBAL SQL_SLAVE_SKIP_COUNTER per saltare un certo numero di eventi dopo la posizione del file di log binario che hai definito nel comando precedente. Questo esempio salta solo il primo evento:

  1. SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Successivamente, dovrai riavviare la replica:

  1. START REPLICA;

Inoltre, se hai bisogno di interrompere la replica, tieni presente che puoi farlo eseguendo la seguente operazione sull'istanza di replica:

  1. STOP REPLICA;

La tua replica sta ora replicando i dati dall'origine. Qualsiasi modifica apportata al database di origine si rifletterà sull'istanza MySQL di replica. Puoi verificarlo creando una tabella di esempio nel database di origine e controllando se viene replicata correttamente.

Inizia aprendo la shell MySQL sul tuo computer sorgente:

  1. sudo mysql

Seleziona il database che hai scelto di replicare:

  1. USE db;

Quindi crea una tabella all'interno di quel database. La seguente operazione SQL crea una tabella denominata example_table con una colonna denominata example_column:

  1. CREATE TABLE example_table (

  2. example_column varchar(30)

  3. );



Output
Query OK, 0 rows affected (0.03 sec)

Se lo desideri, puoi anche aggiungere alcuni dati di esempio a questa tabella:

  1. INSERT INTO example_table VALUES

  2. ('This is the first row'),

  3. ('This is the second row'),

  4. ('This is the third row');



Output
Query OK, 3 rows affected (0.03 sec)
Records: 3  Duplicates: 0  Warnings: 0

Dopo aver creato una tabella e avervi aggiunto facoltativamente alcuni dati di esempio, torna alla shell MySQL del tuo server di replica e seleziona il database replicato:

  1. USE db;

Quindi esegui l'istruzione SHOW TABLES per elencare tutte le tabelle all'interno del database selezionato:

  1. SHOW TABLES;

Se la replica funziona correttamente, vedrai la tabella che hai appena aggiunto all'origine elencata nell'output di questo comando:

Output
+---------------+
| Tables_in_db  |
+---------------+
| example_table |
+---------------+
1 row in set (0.00 sec)

Inoltre, se hai aggiunto alcuni dati di esempio alla tabella nell'origine, puoi verificare se tali dati sono stati replicati anche con una query come la seguente:

  1. SELECT * FROM example_table;

In SQL, un asterisco (*) è l'abbreviazione \tutte le colonne. Quindi questa query essenzialmente dice a MySQL di restituire ogni colonna da example_table.Se la replica funziona come previsto, questa operazione restituirà quei dati nel suo output:

Output
+------------------------+
| example_column         |
+------------------------+
| This is the first row  |
| This is the second row |
| This is the third row  |
+------------------------+
3 rows in set (0.00 sec)

Se una di queste operazioni non riesce a restituire la tabella di esempio oi dati che hai aggiunto all'origine, è possibile che tu abbia un errore da qualche parte nella configurazione della replica. In questi casi, puoi eseguire l'operazione SHOW REPLICA STATUS\G per provare a trovare la causa del problema. Inoltre, puoi consultare la documentazione di MySQL sulla risoluzione dei problemi di replica per suggerimenti su come risolvere i problemi di replica.

Conclusione

Completando questo tutorial, avrai configurato un ambiente di replica MySQL che utilizza il metodo di replica basato sulla posizione del file di registro binario di MySQL con un'origine e una replica. Tieni presente, tuttavia, che la procedura delineata in questa guida rappresenta solo un modo per configurare la replica in MySQL. MySQL fornisce una serie di diverse opzioni di replica che puoi utilizzare per produrre un ambiente di replica ottimizzato per le tue esigenze. Esistono anche numerosi strumenti di terze parti, come Galera Cluster, che puoi utilizzare per espandere le funzionalità di replica integrate di MySQL.

Se hai ulteriori domande sulle capacità specifiche di replica in MySQL, ti invitiamo a consultare la nostra intera libreria di contenuti relativi a MySQL.