it-swarm.it

Qual è il modo migliore per creare la configurazione della replica master-slave di MySQL e risolverla?

Sono molto nuovo nell'amministrazione del database.

Devo affrontare molti problemi durante l'impostazione della replica master-slave mysql.

Devo anche affrontare regolari problemi di risoluzione dei problemi di replica mysql.

Qualcuno può aiutare a capire come dovrei affrontare tutti questi?

14
Abdul Manaf

Ho fornito collegamenti a tutorial. Tieni presente che su Ubuntu il file my.cnf è in /etc/mysql/my.cnf e non in /etc/my.cnf come nel tutorial di howtoforge. Nella mia configurazione, non ho usato TAVOLI FLUSH CON BLOCCO LETTURA; sul maestro. Se il server principale ha molte attività di scrittura, potrebbe essere necessario bloccare le tabelle eseguendo quel comando prima di eseguire il backup. Se usi FLUSH TABLES CON READ LOCK ;, quindi dopo il backup, vorrai eseguire UNLOCK TABLES. Se riscontri problemi, fammi sapere.

Ecco il tutorial che ho trovato su howto forge, realizzato per Redhat/CentOS: http://www.howtoforge.com/mysql_database_replication

Un altro tutorial che sembrava ok per Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Ecco la configurazione che ho usato:

Sul server MASTER

Configurare il server principale:

vi /etc/mysql/my.cnf

[mysqld]

# bind-address = 127.0.0.1 (comment this out)
server_id           = 1
log_bin             = /var/log/mysql/mysql-bin.log
log_bin_index       = /var/log/mysql/mysql-bin.log.index
max_binlog_size     = 100M
expire_logs_days    = 1

Riavvia MySQL:

/etc/init.d/mysql restart

Connettiti alla console di mysql: mysql -u root -ppassword

Creare e concedere le autorizzazioni all'utente di replica.

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'ipaddressofslave' IDENTIFIED BY 'replicationuserpassword';

Assicurati di copiare queste informazioni da qualche parte o di renderle visibili

SHOW MASTER STATUS \G;
mysql> show master status \G;
            File: mysql-bin.000001
        Position: 100
    Binlog_Do_DB: 
Binlog_Ignore_DB:

mysql> quit 

Dump del database in un file:

mysqldump -u root -p databasename > /tmp/databasename-backup.sql

Copia il dump del database sul server slave usando scp o usa ftp se ti piace:

scp /tmp/databasename-backup.sql [email protected]:/tmp/

Sul server SLAVE

Modifica la configurazione mysql:

vi /etc/mysql/my.cnf
[mysqld]

# slave server configuration
server_id           = 2

# this is optional, but I find it useful to specify where the relay logs go to control.  
# Don't forget to create the /var/log/mysql directory and give mysql rights to it.  
# chown mysql:mysql -R /var/log/mysql
# disk space
relay_log           = /var/log/mysql/mysql-relay-bin
relay_log_index     = /var/log/mysql/mysql-relay-bin.index
relay_log_space_limit = 2000M

Riavvia MySQL: /etc/init.d/mysql restart

Ripristina il backup:

mysql -u root -ppassword nameofthedatabase < /tmp/databasename-backup.sql

Connettiti a MySQL:

mysql -u root -ppassword

stop slave;

# master log file and master_log_pos taken from show master status above
CHANGE MASTER TO master_Host='ipaddressmaster', master_port=3306, master_user='replication', master_password='replicationuserpassword', master_log_file='mysql-bin.000001', master_log_pos=100;

start slave;

Correre SHOW SLAVE STATUS\G:

mysql> show slave status\G;
             Slave_IO_State: Waiting for master to send event
                Master_Host: ipaddressmaster
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.0000001
        Read_Master_Log_Pos: 100
             Relay_Log_File: mysql-relay-bin.000001
              Relay_Log_Pos: 1
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 17324288
            Relay_Log_Space: 17324425
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
          Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.02 sec)

Successivamente, tenere presente che la replica può non riuscire per vari motivi. Sullo slave, è possibile monitorare lo stato eseguendo il comando SHOW SLAVE STATUS\G; O impostare un processo cron per monitorare lo stato e inviare e-mail in caso di errore. Familiarità con l'output di questo comando. Se la replica funziona correttamente, dovresti vedere "Slave_IO_State: in attesa che il master invii l'evento".

Una volta ottenuta correttamente questa configurazione, posso fornirti uno script per monitorare tale replica.

Ecco uno script per monitorare il registro degli errori in MySQL. Se aggiungi la linea

[Mysqld]

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

restart mysql: /etc/init.d/mysql restart

Quindi è possibile utilizzare il seguente script per monitorare il file di registro. Se il registro cambia in qualche modo, riceverai un'email di notifica che si è verificato un errore sul server slave. Se vuoi che il registro degli errori sia controllato su base regolare, dovrai aggiungere questo script al tuo crontab.

Ecco uno script di esempio: /somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="[email protected]"

# This is the log that will be monitored.
# If any changes occur to this, then take appropriate action.
MONITORED_LOG=/var/log/mysql/mysql.err

# We will need this log to see whether any changes occured to /tmp/goreb.log
TEMP_LOG=/tmp/.mysql.err.1

# This is a 1-time command i.e. create the log file if it does nto exist.
[ ! -f $TEMP_LOG ] && touch -r $MONITORED_LOG $TEMP_LOG

[ $MONITORED_LOG -nt $TEMP_LOG ] && echo "an error occurred in mysql" | mail -s "Error on MySQL" $MAILTO

# Update $TEMP_LOG with the new modified date of $MONITORED_LOG
touch -r $MONITORED_LOG $TEMP_LOG

Da aggiungere a crontab.

Rendi eseguibile lo script:

chmod +x /somepath/monitor_mysql_log.sh

Aggiorna crontab:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

E lo script verrà eseguito ogni minuto.

La sceneggiatura che ho fornito è una sceneggiatura che ho appena messo insieme. Inoltre, affinché il tuo server sia in grado di inviare e-mail, dovresti installare qualcosa come postfix o sendmail.

19
Craig Efrein

Mysqldump è veloce, ma il ripristino dei dump può essere molto lento per un database di grandi dimensioni e il blocco delle tabelle non è accettabile su un sito live. Un modo molto migliore e più veloce per installare gli slave è usare XtraBackup di Percona . XtraBackup impone un piccolo carico sul master, non richiede blocchi e il ripristino sullo slave è molto veloce. Questo meccanismo produce un clone completo dell'intero database, inclusi elementi come le tabelle utente, che interromperanno alcuni elementi impostati da un'installazione stock, come l'utente debian-sys-maint, che non è necessariamente una cosa negativa !

Come bonus, una volta che sai come fare, puoi usare esattamente lo stesso meccanismo per i tuoi backup giornalieri. I backup sono più lenti di mysqldump, ma i ripristini sono molto più veloci, il che è proprio ciò di cui hai bisogno se ti trovi in ​​una situazione in cui sei nel panico e devi ripristinare un backup! Se si verifica un errore di replica grave, utilizzare questa procedura per eliminare lo slave e ricostruirlo; non ci vuole davvero molto.

Dovrai impostare rept apt/yum di Percona per la tua distribuzione, quindi installare il pacchetto xtrabackup sia su master che su slave. Consiglio vivamente anche l'uso dell'utilità di compressione pigz (gzip parallelo, disponibile nella maggior parte dei repository standard) poiché fa una differenza enorme nella velocità di backup.

Il processo procede in questo modo (su Ubuntu, altre distro possono variare leggermente) e presuppone che tu abbia già installato MySQL sul tuo slave:

  1. Innanzitutto, esegui un backup sul master: mkdir -p /var/xtrabackup; /usr/bin/innobackupex --slave-info --stream=tar --throttle=1500 /var/xtrabackup 2> /tmp/xtrabackup.out | /usr/bin/pigz -p 4 -c --best -q > /var/backups/mysql.tgz (Modifica il valore dell'acceleratore per limitare l'impatto del backup sul servizio live)
  2. Copia il file di backup sullo slave (usa scp -l 400000 per non morire di fame il padrone della larghezza di banda della rete per i client live)
  3. Stop mysql sullo slave: service mysql stop
  4. Sposta la vecchia directory di dati MySQL: mv /var/lib/mysql /var/lib/mysql2 (o comprimilo da qualche parte se hai poco spazio su disco)
  5. Crea una nuova directory di dati e spostati in essa: mkdir /var/lib/mysql; cd /var/lib/mysql
  6. Decomprimere il file di backup nella nuova cartella: tar xvzif /path/to/backup/mysql.tgz. Nota l'opzione i sull'operazione tar - non funzionerà senza di essa . Questo richiederà del tempo se si dispone di un database di grandi dimensioni.
  7. Esegui lo strumento Innobackupex sui file estratti: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. Ciò esegue efficacemente un ripristino di emergenza sui file dai registri binari. Questo richiede solo pochi secondi; utilizzare una quantità di memoria inferiore se su un server più piccolo.
  8. Supponendo che venga completato correttamente, eliminare il backup e impostare la proprietà dei file: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
  9. Avvia mysql: service mysql start
  10. Ottieni il nome del file di registro principale e la posizione del backup (nota NON le informazioni in xtrabackup_slave_info): cat xtrabackup_binlog_info. Dirà qualcosa come mysql-bin.000916 13889427
  11. Collegati a MySQL e verifica che ci siano cose.
  12. Ripristina le impostazioni di replica utilizzando i dettagli che hai sui registri: CHANGE MASTER TO MASTER_Host='192.168.0.1', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000916', MASTER_LOG_POS=13889427; (Modifica per corrispondere ai dettagli del server DB reale)
  13. Riavvia lo slave: START SLAVE;
  14. Controlla lo stato dello slave quando raggiunge il master fino a quando "seconds_behind_master" è 0: SHOW SLAVE STATUS\G

Il tuo schiavo è ora pronto. Se necessario, è ora possibile impostare la replica circolare:

  1. Sullo slave: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS; Nota il nome e la posizione del file di registro (qualcosa come mysql-bin.000031 e 17244785).
  2. Sul master: CHANGE MASTER TO MASTER_Host='192.168.0.2', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000031', MASTER_LOG_POS=17244785;, inserendo valori dallo slave che abbiamo appena visto.
  3. Sul master: START SLAVE;
  4. Sullo slave: UNLOCK TABLES;

Ora dovresti essere pronto con una replica circolare.

Per quanto riguarda la risoluzione dei problemi, Percona's toolkit ha tutti i tipi di cose da aiutare come il checksumming per individuare la corruzione silenziosa, la misurazione dei ritardi e altro ancora. Le forme più comuni di corruzione della replica possono essere evitate impostando binlog_format = MIXED nel tuo my.cnf. Detto questo, nella mia esperienza la replica non è generalmente problematica.

7
Synchro