Dal Wiki di Linux

Impostazione della replica

Server principale

mio.cnf sul server principale:

[mysqld]# ID server. Deve essere univoco su ciascun collegamento di server (sia master che slave). # È un numero compreso tra 1 e 4294967295 (2 ^32 -1 ) id-server = 1 # Percorso dei log binari in cui vengono salvate tutte le modifiche nel database del server principale. Dovrebbe esserci spazio sufficiente per questi log log-bin = /var/lib/mysql/mysql-bin # Quanti giorni conservare i log binari sul master. In qualche modo, questo determina anche quanto lo slave può rimanere indietro rispetto al master # scadenza_logs_days = 10 # Dimensione del file binlog (ogni singolo file) # max_binlog_size = 1024M # Abilita la compressione dei log inviati allo Slave slave_compressed_protocol = 1 # Nome dello il database per il quale eseguire la replica. Se è necessario replicare più database, ripetere l'opzione con il nome del database desiderato replicate-do-db = testdb # Oltre a questa opzione, ci sono altre opzioni "scelta inversa"- per escludere la selezione dei database # replicate-ignore-db= nome_database # così come le opzioni per replicare le singole tabelle (analogamente - selezionare uno/più ; escludere uno/più, così come la definizione dei nomi tramite caratteri jolly)# Questa opzione è necessaria nel caso in cui questo server master sia slave di un altro, in modo che anche lo slave per questo master (sub-slave del master principale) riceva gli aggiornamenti # Può essere utile quando si replica un master-master con uno slave # log -slave -aggiornamenti

Diamo i diritti al server slave per replicare da questo. Per fare ciò, nella console mysql diamo il comando:

mysql> GRANT replication slave ON * .* TO "repluser" @"replhost" IDENTIFICATO DA "replpass" ;

repluser- nome utente per connettersi. L'utente viene creato al momento dell'esecuzione del comando.
replhost- Indirizzo IP o dominio host del server slave che si collegherà a questo master e importerà le modifiche da esso.
sostituisci- password di connessione

La restrizione sulla base per la replica nella replica di concessione non sembra funzionare, ovvero consentiamo tutto e nella configurazione specifichiamo solo la base/le basi necessarie

Riavviamo il server, dopodiché puoi eseguire il comando nella console

mysql> MOSTRA STATO MASTER ;

che mostrerà il file di registro binario con cui il master sta attualmente lavorando e la posizione corrente nel registro, nonché le basi replicate.

Servitore schiavo

Aggiungi le opzioni necessarie nel file config mio.cnf sul server slave:

[mysqld]# ID server per questo bundle di server - vedere la descrizione sopra server-id = 2 # Registri di inoltro: registri scaricati dal server principale # Specificare il percorso per questi registri ; dovrebbe esserci spazio sufficiente per riporli.#relè-log= /var/lib/mysql/mysql-relay-bin#relay-log-index= /var/lib/mysql/mysql-relay-bin.index# Nome del database da replicare replicate-do-db = testdb # Abilita la compressione dei log inviati allo Slave slave_compressed_protocol = 1

Riavvia il server per applicare le modifiche

Avvia la replica

Sul master, blocchiamo le tabelle per la scrittura per ottenere un dump completamente corretto:

mysql> FLUSH TABELLE CON READ LOCK ; mysql> SET GLOBAL read_only = ON ;

Uniamo un dump dal server. In alcuni punti di solito scrivono che è necessario guardare la posizione e il nome del registro sul master - questo non è necessario ed è risolto dalla chiave --dati-master per mysqldump, che scriverà le informazioni necessarie nel dump stesso:

mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql

Successivamente, avviamo la procedura guidata per funzionare:

mysql> SET GLOBAL read_only = OFF;

(anche se sorge il pensiero: è davvero necessario bloccare il database durante il dump? Non appena il dump con --master-data ha iniziato a essere eseguito, il nome e la posizione del registro vengono inseriti in esso e le tabelle vengono automaticamente bloccate per scrittura - cioè tutto è uguale, solo in modalità automatica)

mysql -hslavehost -uslaveuser -pslavepass slavedbname< dump.sql

IN questo caso slavedbname = masterdbname, sebbene se lo desideri, puoi fare in modo che il database venga replicato con un nome diverso.

Specificare l'indirizzo del server master allo slave:

mysql> CAMBIA MASTER IN MASTER_HOST = "masterip" , MASTER_USER = "repluser" , MASTER_PASSWORD = "replpass" ;

Dove masterip- L'indirizzo IP o il dominio del server principale e le opzioni rimanenti sono quelle specificate in precedenza durante l'impostazione del server principale. Il nome del file di registro e la posizione vengono presi dal dump, ma se lo si desidera, possono essere specificati manualmente tramite le opzioni MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = posizione

Dopo questo comando, le informazioni sul master vengono salvate in un file master.info nella directory del database dati mysql-server. Se lo desideri, puoi specificare queste opzioni nella configurazione del server slave:

master-host=masterip master-user=repluser master-password=replpass master-port=3306

Successivamente, avviamo il server slave tramite la console mysql:

mysql> START SLAVE;

Ora puoi controllare lo stato del server slave con il comando

mysql> MOSTRA STATO SLAVE ;

Da informazioni interessanti ci possono essere campi:

Slave_IO_State: in attesa che il master invii l'evento, Slave_IO_Running: Sì E Slave_SQL_Running: Sì- funziona tutto bene :)
Secondi_dietro_Master- quanto è lontano lo schiavo dal padrone. In modalità normale dovrebbe essere 0, ma in ritardo reale può anche essere 0 se vengono apportate molte modifiche al master e il canale tra master e slave è stretto e quest'ultimo non ha il tempo di scaricare binlog dal master. In questo caso "0" è corretto, ma solo per quanto è riuscito a scaricare dai log.

E altre informazioni aggiornate come assenza di errori, posizione corrente e nome del registro del server, registro dello slave, ecc.

Varie

Esistono 2 opzioni per mysqldump per scrivere il nome del registro e la posizione nel file di dump: --dati-master E --dump-schiavo. Il secondo non è ovunque:

[e-mail protetta]:~# mysqldump --help | grep "scaccia-schiavo" [e-mail protetta]:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, per portbld-freebsd8.2 (amd64)

Dump-slave[=valore] Questa opzione è simile a --master-data tranne per il fatto che viene utilizzata per eseguire il dump di un server slave di replica per produrre un file di dump che può essere utilizzato per configurare un altro server come slave che ha lo stesso master come server scaricato. Fa in modo che l'output del dump includa un'istruzione CHANGE MASTER TO che indica le coordinate del registro binario (nome file e posizione) del master dello slave scaricato (piuttosto che le coordinate del server scaricato, come viene fatto da --master- data). Queste sono le coordinate del server master da cui lo slave dovrebbe iniziare a replicare. Questa opzione è stata aggiunta in MySQL 5.5.3.

Di conseguenza, un'opzione è la clonazione di uno slave, la seconda è la creazione di un subslave. In altre parole, dump-slave permette di creare (utilizzando slave1) un altro slave1 nella catena master-slave1-slave2 (la posizione nel log e il file di log relativo ai log master verranno scritti nel dump), master- data consente di creare slave2 - la posizione/log relativo ai binlog di slave1.

Errori di replica

Quando la replica è in esecuzione, possono verificarsi errori, per qualsiasi motivo, ad esempio, inserendo manualmente i dati su un server slave.

Opzioni di soluzione.

Configurazione della replica MySQL senza interrompere la procedura guidata.

1. Configurazione del server principale:

Guardiamo dove dovrebbe trovarsi la configurazione.

# ps ausiliario | grep mio.cnf

mysql 51189 0.0 0.0 17064 1912 - È 18:35 0:00.05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/mio.cnf--user=mysql --datadir=/var/db/mysql

Se il file è mancante, puoi copiarlo dall'esempio.

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

Oppure creane uno vuoto.

# tocca /var/db/mysql/my.cnf

Alla configurazione creata nella sezione noi scriviamo.

#ID server univoco. Il master deve essere al di sotto della replica e non duplicato

server - id = 1

#formato registro

binlog - formato = misto

#Percorso in cui si troverà il binlog (per impostazione predefinita, la dimensione di un registro è 1g)

#Binlog tempo di archiviazione

scadenza_logs_giorni = 30

replicate-do-db=database_1

replicate-do-db=database_2

replicate-do-db=database_3

replicate-do-db=database_4

#Registro errori

Concludiamo con la modifica e riavviamo MySQL con una nuova configurazione.

# /usr/local/etc/rc.d/mysql-server restart

Ora devi aggiungere un utente al server Master per lo Slave.

Per la replica saranno sufficienti i diritti REPLICATION SLAVE. Accedi come root al server MySQL.

# mysql -uroot -p

Crea un utente:

mysql> usa mysql;

mysql>CREA UTENTE 'replica'@'ip_address_slave_server';

mysql>GRANT REPLICATION SLAVE ON*.* TO 'replica'@'ip_address_slave_server' IDENTIFICATO DA 'password_per_utente_replica';

Ora puoi riavviare il server o dire

mysql>PRIVILEGI FLUSH;

2. Creare un dump dei database richiesti:

Tutte le basi.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql

determinate basi.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B DATABASE DATABASE1 DATABASE2 DATABASE3 > /usr/home/Timur/dump .sql

3. Osserviamo quale binlog utilizzare e la sua posizione:

# head -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"

- CAMBIA MASTER IN MASTER_LOG_FILE=' mysql-bin.000049',MASTER_LOG_POS= 107 ;

Per favore scrivilo!!!

4. Fare clic sul dump e trasferirlo sul server Slave:

# gzip /usr/home/Timur/dump.sql

Trasferiamo.

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. Configurazione del server Slave (my.cnf).

id-server=2

binlog - formato = misto

log-bin=/var/log/mysql/mysql-bin

scadenza_logs_giorni = 30

#Binglog schiavo

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

# Indica al server downstream di registrare gli aggiornamenti che si verificano sul server downstream in un registro binario. Questa opzione è disabilitata di default. Dovrebbe essere abilitato se si desidera collegare a margherita i server slave.

log-slave-aggiornamenti=1

#Imposta i database in sola lettura. Questa opzione non si applica ai superuser!!!

sola lettura = 1

#Salta voci duplicate. Dopo che Seconds_Behind_Master diventa 0, commenta e riavvia SLAVE

slave-skip-errors=all

# Specifica quali database dobbiamo replicare

replicate-do-db=database_1

replicate-do-db=database_2

replicate-do-db=database_3

replicate-do-db=database_4

#Registro errori

log-error=/var/log/mysql/mysqld-error.log

#In modo che lo Slave non si avvii all'avvio del server. Puoi avviarlo manualmente START SLAVE;

skip-slave-start = Attivo

Riavvia il server (MySQL).

6. Carica il dump su Slave e avvia la replica:

Decomprimiamo.

# gunzip /usr/local/Timur/dump.sql.gz

Caricamento della discarica.

# mysql -uroot -p< /usr/local/Timur/dump.sql

Diciamo a Slave da dove estrarre i dati e iniziare. MASTER_LOG_FILE e MASTER_LOG_POS prendono ciò che abbiamo scritto quando abbiamo scaricato le basi su Master 😉

mysql>CAMBIA MASTER IN MASTER_HOST= ‘<>' , MASTER_USER = 'replica' , MASTER_PASSWORD = 'password_per_utente_replica', MASTER_LOG_FILE= ‘mysql-bin.000049‘ , MASTER_LOG_POS = 107 ; AVVIA SCHIAVO ;

Guardiamo come una squadra MOSTRA STATO SLAVE\G Abbiamo iniziato tutti?

mysql> MOSTRA STATO SLAVE\G
****************************** 1a fila ****************** ** *******
Slave_IO_State: in attesa che il master invii l'evento
Master_Host: questo è l'indirizzo del server principale
Master_User: replica
Master_Port: 3306
Connetti_Riprova: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relè_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Sì
Slave_SQL_Running: Sì
Replica_Do_DB: database_1,database_2,database_3,database_4,database_1,database_2,database_3,database_4
Replica_Ignora_DB:
Replica_Esegui_Tabella:
Replica_Ignora_tabella:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Ultimo_Erno: 0
Ultimo_errore:
Salta_contatore: 0
Exec_Master_Log_Pos: 1919771
Relay_Log_Space: 3125
Fino alla_condizione: nessuna
Fino al_file_di_registro:
Fino a_Log_Pos: 0
Master_SSL_Consentito: No
Master_SSL_CA_File:
Master_SSL_CA_Percorso:
Master_SSL_Cert:
Master_SSL_Cipher:
Chiave_SSL_principale:
Secondi_dietro_master: 0
Master_SSL_Verify_Server_Cert: No
Ultimo_IO_Erno: 0
Ultimo_IO_Errore:
Last_SQL_Erno: 0
Ultimo_errore_SQL:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 5
1 riga nel set (0,00 sec)

Tutto è iniziato.

Dovrebbe crescere Exec_Master_Log_Pos: 1919771

Se si verifica un errore, puoi saltarlo eseguendo:

mysql> STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;

Questa è una breve descrizione di come configurare la replica completa sul tuo server MySQL. Si presuppone che tutti i database verranno replicati e la replica non è stata configurata in precedenza. Per completare i passaggi qui, dovrai farlo poco tempo arrestare il server principale.

Questo è il modo più semplice per installare un server slave, ma non è l'unico. Ad esempio, se si dispone già di un'immagine del server di appartenenza, l'ID del server è già impostato sul server di appartenenza ed è in corso la registrazione, il server slave può essere installato senza arrestare il server di appartenenza o anche impostare blocchi di aggiornamento (per ulteriori informazioni informazioni, vedere Vedere la sezione 4.10.7 Domande frequenti sulla replica frequente.

Per diventare un vero guru della replica di MySQL, ti consigliamo di imparare, comprendere e provare prima tutti i comandi menzionati in Vedere la sezione 4.10.6 Comandi SQL relativi alla replica. Vedere la sezione 4.10.5 Opzioni di replica in `my.cnf" .

Assicurati che i server master e slave abbiano l'ultima versione di MySQL installata. Utilizzare la versione 3.23.29 o successiva. Le versioni precedenti utilizzavano un formato di registro binario diverso e contenevano bug che sono stati corretti nelle versioni più recenti. Grande richiesta: si prega di non inviare segnalazioni di bug senza verificare se questo bug è presente nell'ultima versione.
Imposta un singolo utente di replica sul server principale con privilegio FILE (nelle versioni MySQL precedenti alla 4.0.2) o privilegio REPLICATION SLAVE nelle versioni MySQL più recenti. Questo utente deve inoltre disporre dell'autorizzazione per connettersi da tutti i server downstream. Se l'utente eseguirà solo la replica (consigliato), non è necessario che gli vengano concessi privilegi aggiuntivi. Ad esempio, per creare un utente denominato repl che possa accedere al server principale da qualsiasi host, è possibile utilizzare il seguente comando: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
Spegni MySQL sul server principale. mysqladmin -u root -p arresto
Crea un'immagine di tutti i dati sul server principale. Il modo più semplice per farlo (su Unix) è creare con catrame un archivio della sua intera directory di dati. La posizione esatta della directory dei dati dipende dall'installazione. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Gli utenti Windows possono utilizzare WinZIP o un programma simile per creare un archivio di directory di dati.
In my.cnf sul server master, aggiungi voci alla sezione entry log-bin e server-id=numero univoco alla sezione e riavvia il server. È molto importante che l'ID del server slave sia diverso dall'ID del server padre. Possiamo pensare al server-id come a un indirizzo IP: identifica in modo univoco il server tra i membri della replica. log-bin server-id=1
Riavvia MySQL sul server principale.
Aggiungi quanto segue a my.cnf sui server slave: master-host= master-user= master-password= master-port= server-id= sostituendo i valori in con i valori appropriati per il tuo sistema . I valori server-id devono essere diversi su ciascun server coinvolto nella replica. Se server-id non è definito, verrà impostato su 1, se anche master-host non è definito, verrà impostato su 2. Si noti che se server-id viene omesso, il server master rifiuterà le connessioni a tutti gli slave server e il server slave - per rifiutare la connessione al server principale. Pertanto, è possibile omettere l'impostazione del valore server-id solo se si esegue il backup utilizzando un log binario.
Copiare i dati dell'istantanea nella directory dei dati sui server slave. Assicurati che le autorizzazioni per file e directory siano corrette. L'utente che esegue MySQL come deve essere in grado di leggere e scrivere dati su di essi allo stesso modo del server principale.
Riavviare il/i server/i slave.

Una volta completati questi passaggi, i server downstream devono connettersi al server upstream e modificare i dati in modo da riflettere eventuali modifiche apportate al server upstream da quando è stata scattata l'immagine.

Se il server -id non è impostato per il server downstream, nel log degli errori verrà registrato il seguente errore:

Attenzione: si dovrebbe impostare server_id su un valore diverso da 0 se master_host è impostato. Il server non fungerà da slave. (Attenzione: se master_host è impostato, server_id deve essere impostato su un valore diverso da zero. Il server non fungerà da server slave.)

Se l'ID del server master non è impostato, i server slave non saranno in grado di connettersi al server master.

Se un server downstream non è in grado di eseguire la replica per qualsiasi motivo, i messaggi di errore corrispondenti possono essere trovati nel log degli errori sul server downstream.

Dopo che il server slave ha avviato la replica, un file "master.info" apparirà nella stessa directory del log degli errori. Il file "master.info" è utilizzato dal server slave per tenere traccia di quali voci del log binario del server master sono stati elaborati. Non eliminare o modificare questo file a meno che tu non sia sicuro che sia necessario. Anche se c'è una tale fiducia, è comunque meglio usare il comando CHANGE MASTER TO.

replica- una tecnica utilizzata nell'architettura dei sistemi che operano sotto carico, il cui risultato è la distribuzione del carico quando si lavora con un database su più server. La replica MySQL MASTER SLAVE viene utilizzata più spesso, ma viene utilizzato anche un secondo tipo di replica: Master-Master.

Cos'è la replica MySQL MASTER SLAVE e a cosa serve?

replica padrone-schiavo comporta la duplicazione dei dati su uno slave Server MySQL, tale duplicazione viene effettuata per la maggior parte al fine di garantire l'affidabilità. In caso di guasto del server Master, le sue funzioni vengono commutate sullo Slave.

La replica può essere eseguita anche per migliorare le prestazioni del sistema, ma qui le prestazioni sono quasi sempre secondarie.
Quando un'applicazione lavora con un database, le operazioni più frequenti sono operazioni SELEZIONARE- richieste di lettura dati, modifica dati - richieste ELIMINARE, INSERIRE, AGGIORNAMENTO, ALTER statisticamente si verifica molto meno frequentemente.

Per evitare la perdita di dati in caso di guasto di uno dei server, le operazioni di modifica delle informazioni nelle tabelle vengono sempre elaborate dal server Master. Le modifiche vengono quindi replicate sullo Slave. La lettura può essere effettuata dal server che svolge il ruolo di Slave.
A causa di ciò, è possibile ottenere un aumento delle prestazioni insieme all'affidabilità.

La soluzione è popolare, ma non sempre applicabile, poiché la replica può subire ritardi: se ciò accade, le informazioni devono essere lette anche dal server principale.

L'indirizzamento di richieste di un certo tipo verso un particolare database server è comunque implementato a livello applicativo.

Se fai la divisione SELECT query e tutto il resto a livello di programma, inviandoli al server desiderato se uno di essi fallisce, l'applicazione che serve l'infrastruttura sarà inutilizzabile. Affinché funzioni, è necessario fornire uno schema più complesso e riservare ciascuno dei server.

La replica è per la tolleranza agli errori, non per il ridimensionamento.

Replica MySQL MASTER SLAVE - configurazione su Debian

Useremo due server con indirizzi:

Server principale 192.168.0.1
Server secondario 192.168.0.2

Per la dimostrazione, vengono utilizzati VDS collegati a una rete locale.
Per sapere sempre con certezza su quale server stiamo eseguendo questo o quel comando, modificheremo i file /etc/hosts su entrambi i server

192.168.0.1 master

192.168.0.2 schiavo

Sostituiremo i valori esistenti in /etc/hostname rispettivamente con master e slave, in modo che le modifiche abbiano effetto, riavvieremo il server.

1. Effettuiamo le impostazioni sul server principale.

[e-mail protetta]:/#

Modifica del file di configurazione del server del database principale

mcedit /etc/mysql/mio.cnf

Selezionare l'ID del server - è possibile specificare qualsiasi numero, il valore predefinito è 1 - rimuovere semplicemente il commento dalla riga

id-server = 1

Imposta il percorso del registro binario, anch'esso specificato per impostazione predefinita, decommenta

Impostiamo il nome del database che replicheremo su un altro server

binlog_do_db = db1

Riavvia Mysql in modo che il file di configurazione venga riletto e le modifiche abbiano effetto:

/etc/init.d/mysql riavvio

2. Impostare l'utente con i diritti necessari

Vai alla console del server del database:

Diamo all'utente sul server slave i diritti necessari:

GRANT REPLICATION SLAVE ON *.* TO "slave_user"@"%" IDENTIFICATO DA "123";

Blocco di tutte le tabelle nel database

TAVOLI A FILO CON SERRATURA LEGGERA;

Controlla lo stato del server principale:

3. Creare un dump del database sul server

Crea un dump del database:

mysqldump -u root -p db1 > db1.sql

Sblocca le tabelle nella console mysql:

4. Trasferire il dump del database sul server Slave

scp db1.sql [e-mail protetta]:/casa

Eseguiamo ulteriori azioni sul server Slave

[e-mail protetta]:/#

5. Creazione di un database

Caricamento della discarica:

mysql -u root -p db1< db1.sql

6. Apportare modifiche a my.cnf

mcedit /etc/mysql/mio.cnf

Assegnare un ID incrementando il valore impostato sul Master Server

id-server = 2

Impostare il percorso del registro di inoltro

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

e il percorso bin del registro sul server principale

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

Specificare la base

binlog_do_db = db1

Riavvio del servizio

/etc/init.d/mysql riavvio

7. Impostare la connessione al server principale

CAMBIA MASTER IN MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Iniziamo la replica sul server slave:

Puoi verificare il funzionamento della replica sullo Slave interrogando:

****************************** 1a fila ****************** ** *******
Slave_IO_State: in attesa che il master invii l'evento
Master_Host: 192.168.0.1
utente_master: utente_slave
Master_Port: 3306
Connetti_Riprova: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relè_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Sì
Slave_SQL_Running: Sì
Replica_Esegui_DB:
Replica_Ignora_DB:
Replica_Esegui_Tabella:
Replica_Ignora_tabella:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Ultimo_Erno: 0
Ultimo_errore:
Salta_contatore: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Fino alla_condizione: nessuna
Fino al_file_di_registro:
Fino a_Log_Pos: 0
Master_SSL_Consentito: No
Master_SSL_CA_File:
Master_SSL_CA_Percorso:
Master_SSL_Cert:
Master_SSL_Cipher:
Chiave_SSL_principale:
Secondi_dietro_master: 0
Master_SSL_Verify_Server_Cert: No
Ultimo_IO_Erno: 0
Ultimo_IO_Errore:
Last_SQL_Erno: 0
Ultimo_errore_SQL:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 riga nel set (0,00 sec)

Poiché non si sono verificati errori, possiamo concludere che la replica è configurata correttamente.

È buon strumento ridimensionamento, ma come principale svantaggio presenta la desincronizzazione della copia dei dati e ritardi, che possono essere critici.

Possono essere completamente evitati usando di più soluzione moderna. È facile da configurare, affidabile ed elimina la necessità di copiare manualmente i dump del database.

Al giorno d'oggi, il database MySQL viene utilizzato quasi ovunque, ove possibile. È impossibile immaginare un sito che funzioni senza MySQL. Naturalmente, ci sono alcune eccezioni, ma questo sistema di database occupa la maggior parte del mercato. E l'implementazione più popolare è MariaDB. Quando il progetto è piccolo, per eseguirlo è sufficiente un solo server, sul quale si trovano tutti i servizi: un web server, un database server e server email. Ma quando il progetto diventa più grande, potrebbe essere necessario dedicare un server separato per ogni servizio, o addirittura suddividere un servizio in più server, come MySQL.

Per mantenere uno stato sincrono dei database su tutti i server, la replica deve essere utilizzata contemporaneamente. In questo articolo vedremo come viene configurata la replica di MySQL utilizzando MariaDB Galera Cluster.

CHE COS'È MARIADB GALERA?

MariaDB Galera è un sistema cluster master-master per MariaDB. Da MariaDB 10.1 Software Galera Server e MariaDB Server sono disponibili in un unico pacchetto, quindi ottieni subito tutto il software di cui hai bisogno. SU questo momento MariaDB Galera può funzionare solo con motori di database InnoDB e XtraDB. Uno dei vantaggi dell'utilizzo della replica è l'aggiunta di ridondanza al database del sito. Se uno dei database fallisce, puoi passare immediatamente a un altro. Tutti i server mantengono uno stato sincronizzato tra loro e garantiscono l'assenza di transazioni perse.

Caratteristiche principali di MariaDB Galera:

Replica con sincronizzazione costante;
Unione automatica dei nodi;
Possibilità di connettere più nodi master;
Supporto per la scrittura su uno qualsiasi dei nodi;
Replica parallela trasparente;
Scalabilità in lettura e scrittura, latenza minima;
I nodi non riusciti vengono automaticamente disconnessi dal cluster;
Non puoi bloccare l'accesso ai tavoli.

IMPOSTA LA REPLICA DI MYSQL

In questo tutorial, useremo Ubuntu 16.04 e MariaDB versione 10.1 come esempio. Prima di iniziare, aggiorna completamente il sistema:

sudo aggiornamento apt-get-y
sudo apt-get upgrade -y

Poiché distribuiremo la nostra configurazione su più nodi, dobbiamo eseguire operazioni di aggiornamento su tutti loro. Se il server del database MariaDB non è già installato, deve essere installato. Innanzitutto, aggiungi il repository e la sua chiave:

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"

sudo apt-get update -y

Quando l'aggiornamento dell'elenco dei pacchetti è completo, installa MariaDB con il comando:

sudo apt install mariadb-server rsync -y

Abbiamo bisogno del pacchetto rsync per eseguire la sincronizzazione diretta. Una volta completata l'installazione, è necessario proteggere il database utilizzando lo script mysql_secure_installation:

sudo mysql_secure_installation

Per impostazione predefinita, è consentito l'accesso guest, esiste un database di prova e non è impostata alcuna password per l'utente root. Tutto questo deve essere corretto. Leggi di più nell'articolo. In breve, dovrai rispondere ad alcune domande:

Inserisci la password corrente per root (inserisci per nessuno):
Cambiare la password di root? N
Rimuovere gli utenti anonimi? Y
Non consentire l'accesso root da remoto? Y
Rimuovere il database di test e accedervi? Y
Ricaricare le tabelle dei privilegi ora? Y

Quando tutto è pronto, puoi procedere alla configurazione dei nodi tra i quali verranno replicati i database mysql. Per prima cosa, diamo un'occhiata alla configurazione del primo nodo. Puoi inserire tutte le impostazioni in my.cnf, ma sarebbe meglio creare fascicolo separato per questi scopi nella cartella /etc/mysql/conf.d/.

Aggiungi queste righe:

binlog_format=RIGA

innodb_autoinc_lock_mode=2
indirizzo-bind=0.0.0.0

wsrep_on=ON

wsrep_sst_method=rsync
# Configurazione del nodo Galera
wsrep_node_address="192.168.56.101"
wsrep_node_name="Nodo1"

Qui l'indirizzo 192.168.56.101 è l'indirizzo del nodo corrente. Quindi vai su un altro server e crea lo stesso file lì:

sudo vi /etc/mysql/conf.d/galera.cnf

binlog_format=RIGA
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
indirizzo-bind=0.0.0.0
# Configurazione del provider Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Configurazione cluster Galera
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Configurazione sincronizzazione Galera
wsrep_sst_method=rsync
# Configurazione del nodo Galera
wsrep_node_address="192.168.56.102"
wsrep_node_name="Nodo2"

Allo stesso modo, qui l'indirizzo del nodo è 192.168.0.103. Soffermiamoci sull'esempio con due server, poiché questo è sufficiente per dimostrare il funzionamento del sistema, ed è possibile aggiungere un altro server inserendo un indirizzo IP aggiuntivo nel campo wsrep_cluster_address. Considera ora cosa significano i valori dei parametri principali e procedi al lancio:

binlog_format- il formato del registro in cui verranno salvate le richieste, il valore della riga indica che i dati binari verranno archiviati lì;
default-storage-engine- motore Tabelle SQL che useremo;
innodb_autoinc_lock_mode- AUTO_INCREMENT modalità di funzionamento del generatore di valori;
indirizzo di associazione- indirizzo ip dove il programma ascolterà le connessioni, nel nostro caso tutti gli indirizzi ip;
wsrep_on- include la replica;
wsrep_provider- libreria con cui verrà eseguita la replica;
wsrep_cluster_name - nome del cluster, deve corrispondere su tutti i nodi;
wsrep_cluster_address- elenco degli indirizzi dei server tra i quali verranno replicati i database mysql, separati da virgole;
wsrep_sst_method- il trasporto che verrà utilizzato per la trasmissione dei dati;
wsrep_node_address- indirizzo ip del nodo corrente;
wsrep_node_name- il nome del nodo corrente.

Collocamento Replica di MySQL quasi completato. L'ultimo tocco rimasto prima del lancio è l'impostazione del firewall. Innanzitutto, abilita lo strumento di gestione delle regole iptables in Ubuntu - UFW:

Quindi apri queste porte:

sudo ufw consenti 3306/tcp
sudo ufw consenti 4444/tcp
sudo ufw consenti 4567/tcp
sudo ufw consenti 4568/tcp
sudo ufw consenti 4567/udp

LANCIO MARIADB GALERA

Dopo aver configurato con successo tutti i nodi, non ci resta che avviare il cluster Galera sul primo nodo. Prima di poter avviare il cluster, devi assicurarti che il servizio MariaDB sia interrotto su tutti i server:

sudo galera_new_cluster