Come configurare la replica di gruppo MySQL su Ubuntu 20.04

Introduzione

La replica di MySQL riflette in modo affidabile i dati e le operazioni da un database a un altro. La replica convenzionale coinvolge un server primario configurato per accettare operazioni di scrittura del database con server secondari che copiano e applicano azioni dal registro del server primario ai propri set di dati. Questi server secondari possono essere utilizzati per letture, ma di solito non possono eseguire scritture di dati.

La replica di gruppo è un modo per implementare un meccanismo di replica più flessibile e tollerante ai guasti. Questo processo prevede l’istituzione di un pool di server, ognuno dei quali è coinvolto nell’assicurare che i dati vengano copiati correttamente. Se il server primario riscontra problemi, le elezioni dei membri possono selezionare un nuovo primario dal gruppo. Questo consente ai nodi rimanenti di continuare a operare, anche di fronte a problemi. La negoziazione dell’appartenenza, il rilevamento dei guasti e la consegna dei messaggi sono forniti attraverso un’implementazione dell’algoritmo di consenso Paxos.

In questo tutorial, configurerai la replica di gruppo di MySQL utilizzando un set di tre server Ubuntu 20.04. Nota che tre è il numero minimo di istanze di MySQL necessarie per distribuire la replica di gruppo in MySQL, mentre nove è il massimo. Mentre procedi con questo tutorial, avrai la possibilità di configurare il gruppo come gruppo di replica a singolo primario o a multiprimario.

Prerequisiti

Per completare questa guida, avrai bisogno di:

• Tre server in esecuzione Ubuntu 20.04. Ognuno dovrebbe 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 ciascun server.
• MySQL installato su ciascun server. Questa guida presume che tu stia utilizzando l’ultima versione di MySQL disponibile dai repository predefiniti di Ubuntu che, alla data di questa stesura, è la versione 8.0.28. Per installare questo su tutti i tuoi server, segui la nostra guida su Come Installare MySQL su Ubuntu 20.04 per ogni macchina.

Per mantenere le cose chiare, questa guida farà riferimento ai tre server come member1, member2, e member3. Negli esempi presenti in questa guida, questi membri avranno i seguenti indirizzi IP:

Qualsiasi comando che deve essere eseguito su member1 avrà uno sfondo blu, come questo:

Allo stesso modo, qualsiasi comando che deve essere eseguito su member2 avrà uno sfondo rosso:

E qualsiasi comando che deve essere eseguito su member3 avrà uno sfondo verde:

Infine, qualsiasi comando che deve essere eseguito su ciascuno dei tre server avrà uno sfondo standard:

Passo 1 — Generazione di un UUID per identificare il gruppo MySQL

Prima di aprire il file di configurazione di MySQL per configurare le impostazioni di replica del gruppo, è necessario generare un UUID che potrai utilizzare per identificare il gruppo MySQL che stai per creare.

Su member1, utilizza il comando uuidgen per generare un UUID valido per il gruppo:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

Copia il valore che ricevi, poiché dovrai far riferimento a questo tra un momento quando configurerai un nome di gruppo per il tuo pool di server.

Passo 2 — Configurazione della replica di gruppo nel file di configurazione di MySQL

Ora sei pronto per modificare il file di configurazione di MySQL. Apri il file di configurazione principale di MySQL su ogni server MySQL utilizzando il tuo editor di testo preferito. Qui useremo nano:

sudo nano /etc/mysql/my.cnf

Su Ubuntu, MySQL viene installato con diversi file che è possibile utilizzare per definire varie modifiche di configurazione. Per impostazione predefinita, il file my.cnf viene utilizzato solo per includere file aggiuntivi da sottodirectory. Dovrai aggiungere la tua configurazione sotto le linee !includedir. Questo ti permetterà di sovrascrivere qualsiasi impostazione dei file inclusi.

Per iniziare, avvia una nuova sezione includendo un’intestazione [mysqld] e poi aggiungi le impostazioni necessarie per abilitare la replica di gruppo, come evidenziato nell’esempio seguente. Nota che queste impostazioni sono modificate rispetto alle impostazioni minime richieste per la replica di gruppo indicate nella documentazione ufficiale di MySQL. Il prefisso loose- consente a MySQL di gestire le opzioni che non riconosce in modo elegante e senza errori. Dovrai compilare e personalizzare alcune di queste impostazioni a breve:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Per spiegare tutte queste opzioni di configurazione con maggiore chiarezza, sono state suddivise nelle seguenti sottosezioni. Leggere attentamente, poiché alcune sezioni presentano scelte su come si desidera distribuire il proprio gruppo di replica o richiedono di inserire dettagli specifici alla propria configurazione.

Impostazioni di base per la Replica di Gruppo

La prima sezione contiene impostazioni generali richieste per la replica di gruppo che non richiedono modifiche:

. . .
# Impostazioni generali per la replica
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Un requisito particolare per la replica di gruppo in MySQL è che i dati debbano essere memorizzati nel motore di archiviazione InnoDB. La documentazione di MySQL consiglia esplicitamente di disabilitare l’uso di altri motori di archiviazione che potrebbero causare errori in modo simile alla prima riga non commentata in questa sezione.

Le impostazioni rimanenti attivano gli ID di transazione globali, configurano il logging binario richiesto per la replica di gruppo e configurano SSL per il gruppo. Questa configurazione imposta anche alcuni altri elementi che aiutano nel ripristino e nel bootstrap. Non è necessario modificare nulla in questa sezione e dovrebbe essere identica su tutti e tre i server, quindi puoi procedere dopo averla aggiunta.

Impostazioni di Replica di Gruppo Condivise

La seconda sezione imposta le impostazioni condivise per il gruppo. Dovrai personalizzarle una volta e quindi utilizzare le stesse impostazioni su ciascuno dei tuoi nodi. In particolare, devi aggiungere l’UUID del gruppo (che hai creato nel passaggio precedente), un elenco di membri autorizzati del gruppo e i membri seed da contattare per ottenere i dati iniziali quando si uniscono al gruppo.

Imposta il loose-group_replication_group_name al valore UUID generato in precedenza con il comando uuidgen. Assicurati di inserire l’UUID tra le coppie di virgolette vuote.

Successivamente, imposta loose-group_replication_ip_whitelist su un elenco di tutti gli indirizzi IP dei tuoi server MySQL, separati da virgole. L’impostazione loose-group_replication_group_seeds dovrebbe essere quasi la stessa della whitelist, ma dovrebbe aggiungere una porta designata per la replica di gruppo alla fine di ciascun membro. Per gli scopi di questa guida, utilizza la porta di replica di gruppo consigliata, 33061:

. . .
# Configurazione del gruppo di replica condiviso
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Questa sezione dovrebbe essere la stessa su ciascuno dei tuoi server MySQL, quindi assicurati di copiarla attentamente su ciascuno.

Scegliere singolo primario o multi-primario

Successivamente, devi decidere se configurare un gruppo single-primary o multi-primary. In una configurazione single-primary, MySQL designa un singolo server primario (quasi sempre il primo membro del gruppo) per gestire le operazioni di scrittura. Un gruppo multi-primario consente a ciascuno dei membri del gruppo di eseguire scritture.

Se desideri configurare un gruppo multi-primario, rimuovi il commento dalle direttive loose-group_replication_single_primary_mode e loose-group_replication_enforce_update_everywhere_checks. Questo imposterà un gruppo multi-primario. Per un gruppo con un singolo primario, lascia commentate quelle due linee:

. . .
# Modalità singolo o multi-primario? Rimuovi il commento da queste due linee
# per la modalità multi-primario, dove ogni host può accettare scritture
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Queste impostazioni devono essere le stesse su ciascuno dei tuoi server MySQL.

Puoi cambiare questa impostazione in un secondo momento, ma dopo averlo fatto devi riavviare ciascun membro del tuo gruppo MySQL. Per passare alla nuova configurazione, dovrai fermare ciascuna delle istanze MySQL nel gruppo, avviare ciascun membro con le nuove impostazioni, e quindi riavviare la replica di gruppo. Questo non influenzerà i tuoi dati, ma richiede una breve finestra di inattività.

Impostazioni di configurazione specifiche per l’host

La quarta sezione contiene impostazioni che saranno diverse su ciascuno dei server, tra cui:

• L’ID del server
• L’indirizzo a cui fare il bind
• L’indirizzo a cui segnalare agli altri membri
• L’indirizzo di replica locale e la porta di ascolto

La direttiva server_id deve essere impostata su un numero univoco. Per il primo membro, impostalo su 1 e incrementa il numero per ogni host aggiuntivo. Imposta bind-address e report_host sull’indirizzo IP del server rispettivo in modo che l’istanza di MySQL ascolti le connessioni esterne e segnali correttamente il suo indirizzo agli altri host. Anche il loose-group_replication_local_address dovrebbe essere impostato sull’indirizzo IP attuale del server con la porta di replicazione di gruppo (33061) aggiunta all’indirizzo IP.

Come esempio, ecco questa parte della configurazione per member1 utilizzando il suo indirizzo IP di esempio:

. . .
# Configurazione di replicazione specifica dell'host
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Completa questo processo su ciascuno dei tuoi server MySQL. Ecco la configurazione per member2:

. . .
# Configurazione di replicazione specifica dell'host
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

E ecco la configurazione per member3:

. . .
# Configurazione di replicazione specifica dell'host
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Assicurati di aggiornare ciascun indirizzo IP evidenziato con quello del server di cui stai modificando la configurazione.

Quando hai finito, controlla due volte che le impostazioni di replicazione condivise siano le stesse su ciascun host e che le impostazioni specifiche dell’host siano personalizzate per ciascun host. Salva e chiudi il file su ciascun host quando hai finito. Se hai usato nano per modificare il file, puoi farlo premendo CTRL + X, Y e poi ENTER.

Ogni file di configurazione MySQL dei tuoi server ora contiene le direttive necessarie per avviare la replicazione del gruppo MySQL. Per applicare le nuove impostazioni all’istanza MySQL, riavvia il servizio su ognuno dei tuoi server con il seguente comando:

sudo systemctl restart mysql

Con questo, puoi procedere all’abilitazione dell’accesso remoto aggiornando le regole del firewall di ciascuno dei tuoi server.

Passaggio 3 — Aggiornamento delle Regole UFW di Ciascun Server

Presumendo di aver seguito la guida preliminare alla configurazione iniziale del server, avrai configurato un firewall su ciascuno dei server su cui hai installato MySQL e abilitato l’accesso per il profilo UFW OpenSSH. Questa è una misura di sicurezza importante, poiché questi firewall attualmente bloccano le connessioni a qualsiasi porta dei tuoi server, ad eccezione delle connessioni ssh che presentano chiavi che corrispondono a quelle nel file authorized_keys di ciascun server.

Nel file di configurazione di MySQL, hai configurato il servizio per ascoltare le connessioni esterne sulla porta predefinita 3306. Hai inoltre definito 33061 come la porta che i membri dovrebbero utilizzare per la coordinazione della replica.

Su ciascuno dei tuoi server membri, è necessario aprire l’accesso a entrambe queste porte per gli altri membri di questo gruppo in modo che possano comunicare tra loro. Per aprire l’accesso a queste porte su membro1 per membro2, eseguire i seguenti comandi ufw su membro1:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Assicurati di modificare member2_server_ip per riflettere l’effettivo indirizzo IP del server di membro2. Quindi, per aprire le stesse porte per membro3, eseguire questi comandi:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Successivamente, aggiorna le regole del firewall per gli altri due server. Esegui i seguenti comandi su membro2, assicurandoti di cambiare gli indirizzi IP per riflettere quelli di membro1 e membro3, rispettivamente:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Infine, esegui questi due comandi su membro3. Di nuovo, assicurati di inserire gli indirizzi IP corretti per ciascun server:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Dopo aver aggiunto queste regole UFW, ciascuna delle tue tre istanze MySQL avrà accesso alle porte utilizzate da MySQL sugli altri due server.

Con l’accesso alle porte MySQL aperto, è ora possibile creare un utente di replica e abilitare il plugin di replica del gruppo.

Passaggio 4 — Configurazione degli Utenti di Replica e Abilitazione del Plugin di Replica del Gruppo

Per stabilire connessioni con gli altri server nel gruppo di replica, ogni istanza di MySQL deve avere un utente di replica dedicato.

Su ciascuno dei tuoi server MySQL , accedi alla tua istanza MySQL con l’utente amministratore per avviare una sessione interattiva:

sudo mysql

Poiché ogni server avrà il proprio utente di replica, è necessario disattivare il logging binario durante il processo di creazione. Altrimenti, una volta avviata la replica, il gruppo cercherebbe di propagare l’utente di replica dal server primario agli altri server, creando un conflitto con l’utente di replica già presente. Esegui il seguente comando dall’interfaccia MySQL su ciascuno dei tuoi server :

SET SQL_LOG_BIN=0;

Ora puoi eseguire un’istruzione CREATE USER per creare il tuo utente di replica. Esegui il seguente comando, che crea un utente chiamato repl. Questo comando specifica che l’utente di replica deve connettersi utilizzando SSL. Inoltre, assicurati di utilizzare una password sicura al posto di password durante la creazione di questo utente di replica:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Successivamente, concedi al nuovo utente i privilegi di replica sul server:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Quindi, esegui il flush dei privilegi per implementare le modifiche:

FLUSH PRIVILEGES;

Dopo di che, riattiva il logging binario per riprendere le operazioni normali:

SET SQL_LOG_BIN=1;

Successivamente, imposta il canale group_replication_recovery per utilizzare il tuo nuovo utente di replica e la relativa password. Ogni server utilizzerà quindi queste credenziali per autenticarsi al gruppo:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Con l’utente di replica configurato, puoi abilitare il plugin group_replication per prepararti a inizializzare il gruppo:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Verifica che il plugin sia attivo eseguendo il seguente comando:

SHOW PLUGINS;

Il plugin group_replication apparirà in fondo all’elenco poiché è il plugin aggiunto più di recente:

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

Questa output conferma che il plugin è stato caricato e attualmente è attivo. Prima di procedere al passaggio successivo, assicurati di aver eseguito ogni comando in questa sezione su ciascuna delle tue istanze MySQL.

Passaggio 5 — Avvio della Replica di Gruppo

Ora che ogni server MySQL ha un utente di replica configurato e il plugin di replica di gruppo abilitato, puoi iniziare ad avviare il tuo gruppo.

Inizializzazione del Primo Nodo

Per avviare il gruppo, completa i seguenti passaggi su un singolo membro del gruppo. A scopo dimostrativo, questa guida completerà questi passaggi su membro1.

I membri del gruppo si affidano ai membri esistenti per inviare dati di replica, elenchi di membri aggiornati e altre informazioni quando si uniscono inizialmente al gruppo. A causa di questo, è necessario utilizzare una procedura leggermente diversa per avviare il membro del gruppo iniziale in modo che sappia di non aspettarsi queste informazioni dagli altri membri nel suo elenco seed.

Se impostato, la variabile group_replication_bootstrap_group indica a un membro che non dovrebbe aspettarsi di ricevere informazioni dai pari e dovrebbe invece stabilire un nuovo gruppo ed eleggersi membro primario. Puoi attivare questa variabile con il seguente comando:

SET GLOBAL group_replication_bootstrap_group=ON;

Quindi puoi avviare la replica per il membro del gruppo iniziale:

START GROUP_REPLICATION;

In seguito, puoi reimpostare la variabile group_replication_bootstrap_group su OFF, poiché l’unica situazione in cui ciò è appropriato è quando non ci sono membri del gruppo esistenti:

SET GLOBAL group_replication_bootstrap_group=OFF;

Il gruppo sarà avviato con questo server come unico membro. Verifica questo controllando le voci all’interno della tabella replication_group_members nel database performance_schema:

SELECT * FROM performance_schema.replication_group_members;

Questa query restituirà una singola riga rappresentante l’host corrente:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

Il valore ONLINE per lo stato membro (MEMBER_STATE) indica che questo nodo è completamente operativo all’interno del gruppo.

Successivamente, crea un database di test e una tabella con alcuni dati di esempio. Una volta che più membri vengono aggiunti a questo gruppo, questi dati verranno replicati automaticamente a loro.

Inizia creando un database di esempio chiamato playground:

CREATE DATABASE playground;

Di seguito, crea un esempio di tabella denominata equipment all’interno del database playground con il seguente comando:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Questa tabella contiene i seguenti quattro colonne:

• id: Questa colonna conterrà valori interi che aumentano automaticamente, il che significa che non dovrai specificare valori per questa colonna quando carichi la tabella con dati di esempio
• type: Questa colonna conterrà valori stringa che descrivono il tipo di attrezzatura da parco giochi rappresentato dalla riga
• quant: Questa colonna conterrà valori interi per rappresentare la quantità del dato tipo di attrezzatura da parco giochi
• color: Questa colonna conterrà valori stringa specificando il colore dell’attrezzatura fornita

Inoltre, nota che la colonna id è specificata come chiave primaria di questa tabella. In MySQL, ogni tabella replicata in un gruppo deve avere una colonna designata come chiave primaria.

Infine, esegui il seguente comando per inserire una riga di dati nella tabella:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Interroga la tabella per assicurarti che i dati siano stati inseriti correttamente:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Dopo aver verificato che questo server è un membro del gruppo e che ha capacità di scrittura, gli altri server possono unirsi al gruppo.

Avvio dei Nodi Rimanenti

Successivamente, avvia la replicazione di gruppo su member2. Dato che già hai un membro attivo, non è necessario avviare il bootstrap del gruppo e questo membro può unirsi direttamente:

START GROUP_REPLICATION;

Su member3, avvia la replicazione di gruppo allo stesso modo:

START GROUP_REPLICATION;

Controlla nuovamente l’elenco dei membri su uno qualsiasi dei tre server. Questa volta, ci saranno tre server elencati nell’output:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Tutti i membri dovrebbero avere un valore di MEMBER_STATE di ONLINE. Per un nuovo gruppo, se uno dei nodi è elencato come RECOVERING per più di qualche secondo, di solito è un’indicazione che si è verificato un errore o che qualcosa è stato configurato in modo errato. Controlla i log in /var/log/mysql/error.log per ottenere informazioni aggiuntive su cosa è andato storto.

Successivamente, controlla se le informazioni del database di test sono state replicate sui nuovi membri:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Se i dati sono disponibili sui nuovi membri, significa che la replicazione di gruppo sta funzionando correttamente.

Passaggio 6 — Testing delle capacità di scrittura dei nuovi membri del gruppo

Successivamente, puoi provare a scrivere sul database dai nuovi membri del gruppo di replica. Se questo avviene con successo o meno dipende dal fatto che tu abbia scelto di configurare un singolo primario o un gruppo multi-primario.

Test di scrittura in un ambiente con singolo primario

In un gruppo con un singolo primario, ci si può aspettare che qualsiasi operazione di scrittura da parte di un server non primario venga rifiutata per motivi di coerenza. È possibile trovare il primario corrente in qualsiasi momento eseguendo la seguente query su qualsiasi membro del gruppo di replica:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

Il valore della query sarà un ID_MEMBRO che è possibile abbinare a un host interrogando la lista dei membri del gruppo come fatto in precedenza:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Come indica questo esempio di output, l’host su 203.0.113.1 — membro1 — è attualmente il server primario. Se si tenta di scrivere nel database da un altro membro, l’operazione verrà annullata:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Questo è previsto poiché attualmente il gruppo è configurato con un unico primario in grado di scrivere. Se il server primario ha problemi e lascia il gruppo, il gruppo eleggerà automaticamente un nuovo membro per essere il primario e accetterà le scritture.

Test di scrittura in un ambiente con multiprimario

Per i gruppi configurati con un’orientamento multiprimario, qualsiasi membro dovrebbe essere in grado di effettuare scritture nel database.

È possibile verificare che il gruppo stia operando in modalità multi-primaria controllando nuovamente il valore della variabile group_replication_primary_member:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

Se la variabile è vuota, ciò significa che non c’è un host primario designato e che ogni membro dovrebbe essere in grado di accettare scritture.

Testare ciò su member2 tentando di scrivere alcuni dati nella tabella equipment:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

member2 ha eseguito l’operazione di scrittura senza errori.

Su member3, eseguire la seguente query per verificare se il nuovo elemento è stato aggiunto:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Ciò conferma che la scrittura di member2 è stata replicata con successo.

Ora, testare le capacità di scrittura su member3 eseguendo la seguente istruzione INSERT:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

Tornando su member1, verificare che le operazioni di scrittura di entrambi i nuovi membri siano state replicate:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

Ciò conferma che la replica funziona in entrambe le direzioni e che ogni membro è in grado di eseguire operazioni di scrittura.

Passaggio 7 — Riportare il Gruppo Attivo

Una volta che il gruppo è avviato, i singoli membri possono unirsi e lasciare senza influenzare la disponibilità, purché ci siano abbastanza membri per eleggere i server primari. Tuttavia, se vengono apportate determinate modifiche alla configurazione (come il passaggio tra ambienti single e multi-primari), o se tutti i membri del gruppo lasciano, potrebbe essere necessario riavviare il gruppo allo stesso modo iniziale.

Il membro1, impostare la variabile group_replication_bootstrap_group su ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Inizializzare quindi il gruppo:

START GROUP_REPLICATION;

In seguito, è possibile reimpostare la variabile group_replication_bootstrap_group su OFF:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Una volta che il primo membro ha avviato il gruppo, gli altri membri possono unirsi:

START GROUP_REPLICATION;

Seguire questo processo per eventuali membri aggiuntivi:

START GROUP_REPLICATION;

Il gruppo dovrebbe ora essere online con tutti i membri disponibili:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Questo processo può essere utilizzato per avviare nuovamente il gruppo quando necessario.

Passaggio 8 — Unirsi automaticamente a un gruppo all’avvio di MySQL

Con le impostazioni attuali, se un server membro viene riavviato, non si riunirà automaticamente al gruppo all’avvio. Se desideri che i membri si riuniscano automaticamente al gruppo, è possibile modificare leggermente il file di configurazione.

L’impostazione delineata in questo passaggio è utile quando si desidera che i membri si uniscano automaticamente all’avvio. Tuttavia, ci sono alcune cose di cui dovresti essere consapevole. In primo luogo, questa impostazione influisce solo quando l’istanza di MySQL stessa viene avviata. Se il membro viene rimosso dal gruppo a causa di problemi di timeout, ma l’istanza di MySQL rimane online, il membro non si riunirà automaticamente.

In secondo luogo, avere questa impostazione abilitata durante il primo avvio di un gruppo può essere dannoso. Quando non c’è un gruppo esistente a cui unirsi, il processo MySQL impiegherà molto tempo per avviarsi perché cercherà di contattare altri membri non esistenti per inizializzarsi. Solo dopo un lungo timeout si arrenderà e avvierà normalmente. In seguito, dovrai utilizzare la procedura delineata sopra per avviare il gruppo.

Tenendo presenti le avvertenze sopra indicate, se desideri configurare i nodi per unirsi automaticamente al gruppo quando MySQL si avvia, apri il file di configurazione principale di MySQL:

sudo nano /etc/mysql/my.cnf

All’interno, trova la variabile loose-group_replication_start_on_boot e impostala su ON:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Salva e chiudi il file quando hai finito. Il membro dovrebbe tentare automaticamente di unirsi al gruppo la prossima volta che la sua istanza di MySQL viene avviata.

Conclusione

Completando questo tutorial, hai imparato come configurare la replica di gruppo MySQL tra tre server Ubuntu 20.04. Per configurazioni single-primary, i membri eleggeranno automaticamente un primario in grado di scrivere quando necessario. Per gruppi multi-primari, qualsiasi membro può eseguire scritture e aggiornamenti.

La replica di gruppo fornisce una topologia di replica flessibile che consente ai membri di unirsi o lasciare a volontà, garantendo contemporaneamente la consistenza dei dati e l’ordinamento dei messaggi. La replica di gruppo MySQL potrebbe essere un po’ più complessa da configurare, ma fornisce funzionalità che non sono possibili con la replica tradizionale.