La replicación de MySQL es relativamente simple de configurar, todavía hay algunos puntos que no se deben pasar por alto y que se deben verificar antes de comenzar para evitar sorpresas.
Si he trabajado a menudo con servidores MySQL replicados, nunca antes había tenido que configurar uno. Esta operación es bastante simple, pero aún requiere una serie de controles previos para asegurarse de que todo va bien. Describiremos en este artículo la descripción de configurar una replicación maestro/esclavo.
Preparación de servidores para la replicación
Para poder configurar una replicación, necesita al menos dos servidores MySQL, uno que actuará como maestro (master), otro como esclavo (slave).
Para que se inicie la replicación, las bases de datos ya deben estar en un estado idéntico en ambas máquinas. Esto pasará ya sea por una duplicación de la máquina virtual si está en esta configuración, o por volcados del maestro para cargar en el esclavo.
Configuración básica para la replicación de MySQL
Configuración maestra
Para configurar su maestro, debe modificar líneas en my.cnf. Será necesario especificar un id de servidor (que debe ser diferente entre el maestro y el(los) esclavo(s), un registro binario, un registro de errores y el perímetro de las bases de datos a tener en cuenta. Este alcance se puede definir en el modo «replicar todas las bases de datos excepto…» o en el modo «replicar solo estas bases de datos…». Estas líneas las puedes definir tú mismo, o si lo tienes instalado, obtener ayuda de phpMyAdmin que, desde un formulario, te dará las líneas a insertar. Para obtener más detalles sobre la replicación con phpMyAdmin, puede seguir este enlace .
Al final, tendrá líneas para insertar (en la sección [mysqld]) que se ven así:
server-id=4218408 log_bin=mysql-bin log_error=mysql-bin.err binlog_ignore_db=nom_db_a_ignorer
Si estás en “solo replicar estas bases…. », tendrá en la última línea « binlog_do_db » en lugar de « binlog_ignore_db ». Deberá reiniciar el servicio MySQL.
En el maestro, también deberá crear una cuenta dedicada a la replicación (se recomienda) a la que podrán acceder los esclavos.
Configuración básica de esclavos para la replicación de MySQL
Del lado eslavo, hay poco que hacer. Debe definir una identificación de servidor en my.cnf que debe ser diferente del maestro. Luego, debe vincularse al maestro a través de la cuenta MySQL utilizada para la replicación. Puede volver a utilizar el enlace anterior para recibir ayuda de phpMyAdmin si es necesario. Deberá reiniciar el servicio MySQL.
Puntos a revisar
Una vez que se haya realizado esta configuración básica, deberá observar más de cerca ciertos puntos para asegurarse de que la replicación no tendrá ningún problema, o incluso que su maestro no se verá afectado por nuevas restricciones.
Funciones MySQL desarrolladas
Si ha desarrollado sus propias funciones de MySQL, deberá verificar si son «deterministas», las funciones no deterministas se consideran inseguras (porque potencialmente pueden desencadenar un resultado diferente en el maestro y el esclavo y, por lo tanto, preocuparse por su replicación) . Si sus funciones son deterministas, idealmente ya debería haberlo indicado en su declaración:
CREATE FUNCTION ..... DETERMINISTIC
Si tiene funciones no deterministas, si tiene un historial de funciones deterministas pero no está indicado como tal, tendrá errores al ejecutar estas funciones una vez que se hayan activado los registros binarios para la replicación. Por lo tanto, esto puede causar grandes problemas, porque su producción se verá afectada.
Si cree que sus funciones son confiables, puede agregar esta línea en my.cnf:
log_bin_trust_function_creators = On
En el nivel de función del sistema, algunas funciones no deterministas aún se consideran «seguras» para la replicación, por ejemplo, «LAST_INSERT_ID()».
Si desea más información sobre el tema, puede ir a esta página en el sitio de MySQL .
formato de archivo binario
Puede definir tres formatos para el binlog:
- declaración: basado en declaraciones, formato predeterminado antes de MySQL 5.7.7
- fila: formato predeterminado basado en filas de 5.7.7
- mixto: modo mixto
Si encuentra un error como este:
“No se puede ejecutar la declaración: imposible escribir en el registro binario ya que BINLOG_FORMAT = STATEMENT y al menos una tabla usa un motor de almacenamiento limitado al registro basado en filas. InnoDB se limita al registro de filas cuando el nivel de aislamiento de transacciones es LECTURA COMPROMETIDA o LECTURA NO COMPROMETIDA”
Su formato no es adecuado. Si tiene bases de datos y tablas heterogéneas, deberá pasar por el modo mixto a través de esta declaración en my.cnf:
binlog-format=mixed
Espacio en disco y purga de registros binarios
El intercambio entre su maestro y su (s) esclavo (s) se realizará a través del binlog, un registro binario donde las instrucciones son escritas por el maestro, recuperadas y reproducidas por el esclavo. Pero estos archivos de registro pueden representar un volumen significativo, por lo que es necesario proporcionar espacio en disco para acomodar estos datos.
A continuación, puede programar una purga deslizante de los archivos binarios. Proporcione suficiente historial para poder reiniciar la replicación sin tener que pasar por el cuadro de volcado.
Por ejemplo, si desea purgar su registro binario con un historial de tres días, puede ejecutar el siguiente comando:
PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);
Para que esta instrucción se reproduzca regularmente, puede llamarla a través de un script cron o, mejor aún, a través de un evento de MySQL.
Supervisión y gestión de errores
Supervisión
Ahora tiene todos los elementos para iniciar su replicación. Una vez lanzado, deberá ser monitoreado, solo para poder intervenir rápidamente si un evento detiene esta replicación.
Para hacer esto, debe monitorear el resultado de la siguiente consulta en el esclavo:
SHOW SLAVE STATUS;
Esto te dará una serie de elementos para saber la buena salud de tu replicación. La información a ser monitoreada en particular es:
- Slave_IO_Running: le permite saber si el subproceso IO se está ejecutando
- Slave_SQL_Running: le permite saber si el hilo de ejecución de SQL se está ejecutando
- Seconds_behind_master: el desplazamiento en segundos entre el maestro y el esclavo
Ambos subprocesos deben estar ejecutándose y, por lo general, el retraso entre el maestro y el esclavo es de 0 s.
Si usa Nagios, también puede encontrar complementos como este para monitorear su replicación.
Gestión de errores
Reiniciar el esclavo:
START SLAVE;
Reinicie el cable IO:
START SLAVE IO_THREAD;
Reinicie el hilo SQL:
START SLAVE SQL_THREAD;
Para desbloquear un error (generalmente un solo error bloquea la replicación, ignorarlo generalmente desbloquea la situación):
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
Con el número (aquí 1) de la cantidad de solicitudes a saltar. Se mostrará un esclavo de inicio seguido de un estado de esclavo de demostración si el problema se resolvió y si la replicación se inició nuevamente.
Si algunos de los errores son recurrentes y no son una preocupación para su replicación, también puede optar por ignorarlos con una entrada en my.cnf:
slave-skip-errors=1062,1053
