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


14

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?


Un par de preguntas: ¿Por qué necesita replicar, qué está tratando de lograr? ¿Cuál es el sistema operativo de cada computadora que participa en la replicación? ¿Cuál es la versión de MySQL en cada computadora? ¿Son las tablas MyISAM, InnoDB, algo más?
Craig Efrein

@CraigEfrein Necesito configurar la replicación ya que estos servidores se usarán en producción. Estoy usando Debian / ubuntu en cada máquina. mysql5.1 como vaersion. Las tablas primarias son InnoDB.
Abdul Manaf

Ok, publicaré una configuración que usé entre dos Debians en un momento. Esto supone, por supuesto, que tiene MySQL instalado en todas las computadoras y que todas están usando la misma versión y tienen suficiente espacio en disco. Cuando use la replicación MySQL, debe pensar en dónde está colocando sus registros bin, que pueden crecer bastante dependiendo de varios factores. Incluiré esa información en mi publicación
Craig Efrein, el

Respuestas:


19

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="addressemail@something.com"

# 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.


muchas gracias me gustó esto y pude configurar la replicación ...
Abdul Manaf

¿Me puede proporcionar el script para monitorear la replicación?
Abdul Manaf

Solo una nota rápida, el script que acabo de agregar es algo que instalarías en los servidores esclavos. Puede instalarlo en el servidor maestro, pero el registro de errores en el servidor esclavo será el que más le interese según su pregunta.
Craig Efrein

gracias por su atención, pero básicamente estaba interesado en la solución de problemas de errores de replicación, creo que este script monitoreará los cambios del registro de errores para el cual lo configuraré.
Abdul Manaf

Dado que su servidor esclavo solo recibirá datos y no los actualizará, la mayor parte de la información registrada en el registro de errores se referirá a la replicación. Si, por ejemplo, una tabla en el maestro se corrompe, el esclavo no replicará la tabla y esencialmente dejará de replicar. Si ve un error en el registro de errores del servidor esclavo. Por lo general, es una buena indicación de que algo está mal con la replicación.
Craig Efrein

7

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.


¿Cuál es tu lealtad?
Pacerier

Ninguno, salvo como usuario satisfecho.
Synchro
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.