¿Cuál es la mejor manera de crear la configuración de replicación maestro-esclavo MySQL y solucionar problemas?

Soy muy nuevo en la administración de bases de datos.

Me enfrento a muchos problemas al configurar la replicación maestro-esclavo mysql.

También me enfrento a problemas habituales de solución de problemas de replicación mysql.

¿Alguien puede ayudar a entender cómo debo lidiar con todo esto?

Proporcioné enlaces a tutoriales. Solo tenga en cuenta que en Ubuntu, el archivo my.cnf está en /etc/mysql/my.cnf y no en /etc/my.cnf como en el tutorial de howtoforge. En mi configuración, no utilicé FLUSH TABLES WITH READ LOCK; en el maestro Si su servidor maestro tiene mucha actividad de escritura, es posible que deba bloquear sus tablas ejecutando ese comando antes de realizar una copia de seguridad. Si usa FLUSH TABLES WITH READ LOCK ;, luego de su copia de seguridad, querrá ejecutar UNLOCK TABLES. Si tiene algún problema, avíseme.

Aquí está el tutorial que encontré sobre cómo forjar, hecho para Redhat / CentOS: http://www.howtoforge.com/mysql_database_replication

Otro tutorial que se veía bien para Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/

Aquí está la configuración que utilicé:

En el servidor MASTER

Configure el servidor maestro:

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

Reiniciar MySQL:

/etc/init.d/mysql restart

Conéctese a la consola de mysql: mysql -u root -ppassword

Crear y otorgar permisos al usuario de replicación.

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

Asegúrese de copiar esta información en algún lugar o dejarla visible

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

mysql> quit 

Volcar la base de datos a un archivo:

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

Copie el volcado de la base de datos al servidor esclavo usando scp o use ftp si lo desea:

scp /tmp/databasename-backup.sql root@ipaddressofslave:/tmp/

En el servidor SLAVE

Edite la configuración de 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

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

Restaurar la copia de seguridad:

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

Conéctese 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;

Ejecutar 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)

Luego, tenga en cuenta que la replicación puede fallar por varias razones. En el esclavo, puede monitorear el estado ejecutando el comando SHOW SLAVE STATUS \ G; O configurar un trabajo cron para monitorear el estado y enviar correos electrónicos si falla. Familiarícese con la salida de este comando. Si la replicación se ejecuta correctamente, debería ver "Slave_IO_State: esperando que el maestro envíe el evento".

Una vez que obtenga esta configuración correctamente, puedo proporcionarle un script para monitorear esa replicación.

Aquí hay un script para monitorear el registro de errores en MySQL. Si agrega la línea

[mysqld]

error de registro = /var/log/mysql/mysql.err

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

Luego puede usar el siguiente script para monitorear el archivo de registro. Si el registro cambia de alguna manera, recibirá un correo electrónico notificándole que ocurrió un error en el servidor esclavo. Si desea que el registro de errores se verifique regularmente, deberá agregar este script a su crontab.

Aquí hay un script de muestra: /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

Para agregar a crontab.

Haga que el script sea ejecutable:

chmod +x /somepath/monitor_mysql_log.sh

Actualizar crontab:

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

Y el script se ejecutará cada minuto.

El guión que proporcioné es un guión que acabo de armar rápidamente. Además, para que su servidor pueda enviar correos electrónicos, debe instalar algo como postfix o sendmail.

Mysqldump es rápido, pero la restauración de volcados puede ser muy lenta para una gran base de datos, y el bloqueo de tablas no es aceptable en un sitio en vivo. Una forma mucho mejor y más rápida de configurar esclavos es usar XtraBackup de Percona . XtraBackup impone poca carga en el maestro, no requiere bloqueos y la restauración en el esclavo es muy rápida. Este mecanismo produce un clon completo de toda la base de datos, incluidas cosas como tablas de usuarios, que romperán algunas cosas que se configuran mediante una instalación de stock, como el usuario debian-sys-maint, que no es necesariamente algo malo !

Como beneficio adicional, una vez que sepa cómo hacer esto, puede usar exactamente el mismo mecanismo para sus copias de seguridad diarias. Las copias de seguridad son más lentas que mysqldump, pero las restauraciones son mucho más rápidas, ¡eso es justo lo que necesita si se encuentra en una situación de pánico y necesita restaurar una copia de seguridad! Si alguna vez obtiene un error de replicación importante, solo use este procedimiento para destruir el esclavo y reconstruirlo; Realmente no lleva mucho tiempo.

Tendrá que configurar el repositorio apt / yum de Percona para su distribución, luego instalar el xtrabackuppaquete tanto en maestro como en esclavo. También recomiendo encarecidamente el uso de la utilidad de compresión pigz (gzip paralelo, disponible en la mayoría de los repositorios estándar), ya que hace una gran diferencia en la velocidad de respaldo.

El proceso es así (en Ubuntu, otras distribuciones pueden variar ligeramente), y supone que ya ha instalado MySQL en su esclavo:

1. Primero, realice una copia de seguridad en el maestro: 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(ajuste el valor del acelerador para limitar el impacto de la copia de seguridad en el servicio en vivo)
2. Copie el archivo de copia de seguridad en el esclavo (úselo scp -l 400000para no privar al maestro del ancho de banda de la red para clientes activos)
3. Deja de mysql en el esclavo: service mysql stop
4. Mueva el antiguo directorio de datos MySQL fuera del camino: mv /var/lib/mysql /var/lib/mysql2(o comprímalo en algún lugar si tiene poco espacio en disco)
5. Crea un nuevo directorio de datos y muévete a él: mkdir /var/lib/mysql; cd /var/lib/mysql
6. Desempaquetar el archivo de copia de seguridad en la nueva carpeta: tar xvzif /path/to/backup/mysql.tgz. Tenga en cuenta la iopción sobre la operación tar: no funcionará sin ella . Esto llevará un tiempo si tiene una gran base de datos.
7. Ejecutar la herramienta Innobackupex en los archivos extraídos: /usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql. Esto efectivamente ejecuta una recuperación de bloqueo en los archivos de los registros binarios. Esto solo toma unos segundos; use una cantidad de memoria menor si está en un servidor más pequeño.
8. Suponiendo que se complete con éxito, elimine la copia de seguridad y establezca la propiedad de los archivos: rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
9. Inicie mysql: service mysql start
10. Obtener el nombre de archivo de registro principal y la posición de la copia de seguridad (NO nota la información en xtrabackup_slave_info): cat xtrabackup_binlog_info. Dirá algo comomysql-bin.000916 13889427
11. Conéctese a MySQL y verifique que hay cosas allí.
12. Restablezca la configuración de replicación utilizando los detalles que obtuvo sobre los registros: 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;(cambie para que coincida con los detalles del servidor de base de datos real)
13. Reiniciar el esclavo: START SLAVE;
14. Verifique el estado del esclavo cuando se pone al día con el maestro hasta que 'seconds_behind_master' sea 0: SHOW SLAVE STATUS\G

Tu esclavo ya está listo. Si es necesario, ahora puede configurar la replicación circular:

1. En el esclavo: FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;Anote el nombre y la posición del archivo de registro (algo así como mysql-bin.000031 y 17244785).
2. En el maestro: 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;insertando valores del esclavo que acabamos de ver.
3. En el maestro: START SLAVE;
4. En el esclavo: UNLOCK TABLES;

Ahora debería estar todo listo con una replicación circular.

En cuanto a la resolución de problemas, el kit de herramientas de Percona tiene todo tipo de cosas para ayudar, como la suma de comprobación para detectar la corrupción silenciosa, la medición de retraso y más. Las formas más comunes de corrupción de replicación se pueden evitar configurando binlog_format = MIXEDen my.cnf. Dicho esto, en mi experiencia, la replicación no suele ser problemática.