Skip navigation links
MySQL 5.0 Reference Manual :: 6 Replicación en MySQL :: 6.9 Preguntas y respuestas sobre replicación
6.10 Resolución de problemas de replicación »
Section Navigation      [Toggle]

6.9. Preguntas y respuestas sobre replicación

P: ¿Cómo configuro el esclavo si el maestro está en ejecución y no quiero pararlo?

R: Hay varias opciones. Si ha hecho una copia de seguridad del maestro en algún punto y ha guardado el nombre del log binario y el desplazamiento ( de la salida de SHOW MASTER STATUS) correspondiente a la muestra de datos, use el siguiente procedimiento:

  1. Asegúrese que el esclavo tiene asignado un ID de servidor único.

  2. Ejecute el siguiente comando en el esclavo, rellenando los valores apropiados en cada opción: 

    mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host_name',
    ->     MASTER_USER='master_user_name',
    ->     MASTER_PASSWORD='master_pass',
    ->     MASTER_LOG_FILE='recorded_log_file_name',
    ->     MASTER_LOG_POS=recorded_log_position;

  3. Ejecute START SLAVE en el esclavo.

Si no tiene una copia de seguridad del maestro, aquí hay un procedimiento rápido para crear uno. Todos los pasos deben realizarse en el maestro.

  1. Ejecute este comando: 

    mysql> FLUSH TABLES WITH READ LOCK;

  2. Con el bloqueo todavía activo, ejecute este comando (o una variación de él): 

    shell> tar zcf /tmp/backup.tar.gz /var/lib/mysql

  3. Ejecute este comando y asegúrese de guardar la salida, que necesitará posteriormente: 

    mysql> SHOW MASTER STATUS;

  4. Libere el bloqueo: 

    mysql> UNLOCK TABLES;

Una alternativa es hacer un volcado SQL del maestro en lugar de una copia binaria como en el procedimiento precedente. Para hacerlo, puede usar mysqldump --master-data en su maestro y cargar el volcado SQL posteriormetne en su esclavo. Sin embargo, esto es más lento que hacer una copia binaria.

No importa cuál de los dos métodos use, luego siga las instrucciones para el caso en que tenga una muestra de los datos y haya guardado el nombre del log y el desplazamiento. Puede usar la misma muestra de datos para preparar varios esclavos. Una vez que tenga la muesta de datos del maestro, puede esperar a preparar un esclavo mientras los logs binarios en el maestro queden intactos. Hay dos limitaciones prácticas en la cantidad de tiempo que puede esperar que son la cantidad de espacio disponible para guardar los logs binarios y el tiempo que tarda el esclavo en leerlos.

También puede usar LOAD DATA FROM MASTER. Este es un comando apropiado que transfiere una muestra de los datos al esclavo y ajusta el nombre del log y el desplazamiento a la vez. En un futuro LOAD DATA FROM MASTER será el método recomendado para preparar un esclavo. Tenga en cuenta, sin embargo, que sólo funciona para tablas MyISAM y que puede mantener un bloqueo de lectura durante un largo periodo de tiempo. Todavía no está implementado tan eficientemente como querríamos. Si tiene tablas muy grandes, el mejor método por ahora es tomar una muesta de datos binaria en el maestro tras ejecutar FLUSH TABLES WITH READ LOCK.

P: ¿Necesita el esclavo estar conectado todo el tiempo al maestro?

R: No, no hace falta. El esclavo puede caer o quedar desconectado durante horas o días, luego reconectar y leer las actualizaciones. Por ejemplo, puede preparar una relación maestro/servidor mediante un enlace telefónico que sólo esté disponible esporádicamente y durante cortos periodos de tiempo. La implicación de esto es, que en un momento dado, el esclavo no garantiza estar sincronizado con el maestro a no ser que tome medidas especiales. En el futuro, tendremos la opción de bloquear el maestro hasta que al menos un esclavo esté sincronizado.

P: ¿Cómo se qué retardo tiene esclavo comparado con el maestro? En otras palabras, ¿cómo se la fecha de la última consulta replicada por el esclavo?

R: Para un esclavo MySQL 5.0, puede leer la columna Seconds_Behind_Master en SHOW SLAVE STATUS. Consulte Sección 6.3, “Detalles de la implementación de la replicación”.

Cuando un flujo SQL esclavo ejecuta un evento leído del maestro, modifica su propia hora a la hora del evento (esto es el porqué TIMESTAMP se replica bien). En la columna Time en la salida de SHOW PROCESSLIST, el número de segundos mostrados por el flujo SQL del esclavo es el número de segundos entre la hora del último evento replicado y la hora real de la máquina esclava. Puede usar esto para determinar la fecha del último evento replicado. Tenga en cuenta que si su esclavo se ha desconectado del maestro durante una hora, y luego reconecta, puede ver de forma inmediata valores Time como 3600 para el flujo SQL esclavo en SHOW PROCESSLIST. Esto ocurriría debido a que el esclavo está ejecutando comandos que tienen una hora.

P: ¿Cómo fuerzo al maestro a bloquear actualizaciones hasta que el esclavo las lee?

R: Use el siguiente procedimiento:

  1. En el maestro, ejecute estos 2 comandos: 

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

    Registra el nombre y desplazamiento del log de la salida del comando SHOW . Estas són las coordinaciones de replicación.

  2. En el esclavo, ejecute el siguiente comando, donde el argumento de la función MASTER_POS_WAIT() son las coordenadas de replicación obtenidos en el prévio paso: 

    mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);

    El comando SELECT bloquea hasta que el esclavo alcanza el fichero y desplazamiento de log especificado. En este punto, el esclavo está sincronizado con el maestro y el comando retorna.

  3. En el maestro, ejectue el siguiente comando para permitir al maestro comenzar a ejecutar actualizaciones otra vez: 

    mysql> UNLOCK TABLES;

P: ¿Qué cuestiones debo considerar al preparar una replicación bidireccional?

R: La replicación MySQL actualmente no sopota ningún protocolo de bloqueo entre maestro y servidor para garantizar la atomicidad de una actualización distribuida (entre servidores). En otras palabras, es posible para el cliente A hacer una actualización del co-maestro 1, y mientras tanto, antes de propagar al co-maestro 2, el cliente B puede hacer una actualización en el co-maesto 2 que haga que la actualización del cliente A funcione de forma distinta que haría en el co-maestro 1. Por lo tanto, cuando la actualización del cliente A se hace en el co-maestro 2, produce tablas que son distintas que las que tiene en el co-maestro 1, incluso tras todas las actualizaciones del co-maestro 2 se hayan propagado. Esto significa que no debe encadenar dos servidores en una relación de replicación bidireccional a no ser que esté seguro que sus actualizaciones pueden hacerse en cualquier orden, o a no ser que se encarge de actualizaciones desordenadas de algún modo en el código del cliente.

Debe tener en cuenta que replicación bidireccional no mejora mucho el rendimiento (o nada), en lo que se refiere a actualizaciones. Ambos servidores tienen que hacer el mismo número de actualizaciones, lo mismo que haría un servidor. La única diferencia es que hay un poco menos de bloqueos, ya que las actualizaciones originadas en otro servidor se serializan en un flojo esclavo. Incluso este beneficio puede verse penalizado por retardos de red.

P: ¿Cómo puedo usar replicación para mejorar rendimiento en mi sistema?

R: Debe preparar un servidor como maestro y dirigir todas las escrituras al mismo. Luego configure tantos esclavos como quiera, y distribuya las lecturas entre los esclavos y maestro. También puede arrancar esclavos con las opciones --skip-innodb, --skip-bdb, --low-priority-updates, y --delay-key-write=ALL para mejorar la velocidad en el esclavo. En este caso, el esclavo usa tablas no transaccionales MyISAM en lugar de InnoDB y BDB para obtener más velocidad.

P: ¿Qué debo hacer para preparar código cliente en mis propias aplicaciones para usar replicación que mejore el rendimiento?

R: Si la parte de su código que es responsable de acceso a bases de datos se ha modularizado correctamente, convertiéndola para correr con un entorno de replicación debe ser algo sencillo. Cambie la implementación de su acceso a base de datos para enviar todas las escrituras al maestro, y enviar lecturas al maestro o al esclavo. Si su código no tiene este nivel de abstacción, preparar un sistema de replicación le da la oportunidad de limpiarlo. Debe comenzar creando una biblioteca o módulo con las siguientes funciones:

  • safe_writer_connect()

  • safe_reader_connect()

  • safe_reader_statement()

  • safe_writer_statement()

safe_ en cada nombre de función significa que la función se encarga de tratar todas las condiciones de error. Puede usar distintos nombres para las funciones. Lo importante es tener una interfaz unificada para conectar para lecturas, conectar para escrituras, hacer una lectura y hacer una escritura.

Luego debe convertir su código de cliente para usar la biblioteca. Este es un proceso largo y complicado en principio, pero vale la pena a la larga. Todas las aplicaciones que usen la aproximación descrita son capaces de aprovechar al configuración maestro/esclavo, incluso uno en el que intervengan varios esclavos. El código es mucho más fácil de mantener, y añadiendo opciones para tratar problemas es trivial. Necesita modificar una o dos funciones sólo; por ejemplo, para loguear cuánto tarda cada comando, o qué comando provoca un error.

Si ha escrito mucho código, puede querer automatizar la tarea de conversión usando la utilidad replace que viene con la distribución estándar MySQL, o escribir su propio script de conversión. Idealmente, su código usa convenciones de estilo. Si no, probablemente es mejor reescribirlo, o al menos regularizarlo manualmente para usar un estilo consistente.

P: ¿Cuándo y cómo puede mejorar la replicación MySQL el rendimiento de mi sistema?

R: La replicación MySQL es más benéfica para sistemas con lecturas frecuentes y escrituras infrecuentes. En teoría, usando una inicialización un maestro/múltiples esclavos, puede escalar el sistema añadiendo más esclavos hasta que se queda sin ancho de banda, o la carga de actualización crece hasta el punto que el maestro no puede tratarla.

Para determinar cuántos esclavos puede tener antes que los beneficios empiecen a notarse, necesita conocer el patrón de consultas, y determinar empíricamente con pruebas la relación entre las lecturas (lecturas por segundo , o max_reads) y las escrituras (max_writes) en un típico maestro y típico esclavo. El ejemplo muestra un cálculo simplificado de qué puede obtener con replicación para un sistema hipotético.

Digamos que la carga del sistema consiste en 10% de escrituras y 90% de lecturas, y hemos determinado con pruebas que max_reads es 1200 - 2 * max_writes. En otras palabras, el sistema puede hacer 1,200 lecturas por segundo sin escrituras, la escritura media es el doble de lenta que la lectura media, y la relación es linear. Supongamos que el maestro y cada esclavo tienen la misma capacidad, y que tienen un maestro y N esclavos. Tenemos para cada servidor (maestro o esclavo):

lecturas = 1200 - 2 * escrituras

lecturas = 9 * escrituras / (N + 1) (las lecturas se dividen, pero las escrituras van a todos los servidores)

9 * escrituras / (N + 1) + 2 * escrituras = 1200

escrituras = 1200 / (2 + 9/(N+1))

La última ecuación indica que el número máximo de escrituras para N esclavos, dado el ratio máximo de lecturas de 1,200 por minuto y un rato de nueve lecturas por escritura.

Este análisis lleva a las siguientes conclusiones:

  • Si N = 0 (que significa que no tenemos replicación), nuestro sistema puede tratar unas 1200/11 = 109 escrituras por segundo.

  • Si N = 1, tenemos 184 escrituras por segundo.

  • Si N = 8,tenemos 400 escrituras por segundo.

  • Si N = 17, tenemos 480 escrituras por segundo.

  • Eventualmente, mientras N se aproxima al infinito ( y el presupuesto a infinito negativo ), podemos llegar carca de 600 escrituras por segundo, incrementando el rendimiento del sistema 5.5 veces. Sin embargo, con sólo ocho servidores, lo incrementamos cerca de cuatro veces.

Tenga en cuenta que estos cálculos asumen ancho de banda infinito y no tiene en cuenta muchos otros factores que pueden ser significativos en el sistema. En muchos casos, puede no ser capaz de realizar una computación similar al mostrado que prediga que ocurre en su sistema si añade N esclavos de replicación. Sin embargo, responder las siguientes cuestiones deben ayudarle a decidir si y cuánto la replicación mejorará el rendimiento de su sistema:

  • ¿Cuál es el ratio de lectura/escritura en su sistema?

  • ¿Cúanta carga de escritura puede tratar un servidor si reduce las lecturas?

  • ¿Para cuántos esclavos tiene ancho de banda disponible?

P: ¿Cómo puedo usar replicación para proporcionar redundancia/alta disponibilidad?

R: Con las características actuales, puede preparar un maestro y un esclavo (o varios esclavos), y escribir un scrip que monitorice el maestro para ver si está en marcha. Luego enseñe a su aplicación y a los esclavos a cambiar el maestro en caso de fallo. Algunas sugerencias:

  • Para decir al esclavo que cambie el maestro, use el comando CHANGE MASTER TO .

  • Una buena forma de mantener a las aplicaciones informadas de la localización del maestro es con una entrada de DNS dinámica para el maestro. Con bind puede usar nsupdate para actualizar dinámicamente el DNS.

  • Debe ejecutar los esclavos con la opción --log-bin y sin --log-slave-updates. De este modo, el esclavo está preparado para ser un maestro en cuanto ejecute STOP SLAVE; RESET MASTER, y CHANGE MASTER TO en los otros esclavos. Por ejemplo, asuma que tiene la siguiente configuración: 

           WC
        \
         v
 WC----> M
       / | \
      /  |  \
     v   v   v
    S1   S2  S3

    M es el maestro, S los esclavos, WC los clientes realizando escrituras y lecturas; los clientes que ejecutan sólo lecturas de bases de datos no se representan , ya que no necesitan cambiar. S1, S2, y S3 son esclavos ejecutándose con --log-bin y sin --log-slave-updates. Como las actualizaciones recibidas por un esclavo del maestro no se loguean en el log binario a no ser que se especifique --log-slave-updates, el log binario en cada esclavo está vacío. Si por alguna razón M no está disponible puede hacer que uno de los esclavos sea el nuevo maestro. Por ejemplo, si elige S1, todos los WC deben redirigirse a S1, y S2 y S3 deben replicar de S1.

    Asegúrese que todos los esclavos han procesado cualquier comando en su log retardado. En cada esclavo, ejecute STOP SLAVE IO_THREAD, luego chequee la salida de SHOW PROCESSLIST hasta que vea Has read all relay log. Mientras que esto es cierto para todos los esclavos, pueden reconfigurarse para una nueva configuración. En el esclavo S1 se promociona a ser el maestro, ejecute STOP SLAVE y RESET MASTER.

    En los otros esclavos S2 y S3, use STOP SLAVE y CHANGE MASTER TO MASTER_HOST='S1' (donde 'S1' representa el nombre de equipo de S1). Para CHANGE MASTER, añada toda la información acerca de cómo conectar a S1 desde S2 o S3 (user, password, port). En CHANGE MASTER, no es necesario especificar el nombre del log binario de S1 o la posición del log desde la que hay que leer: Sabemos que es el primer log binario y la posición 4, que son los defectos para CHANGE MASTER. Finalmente, use START SLAVE en S2 y S3.

    Luego enseñe a todos los WC a dirigir sus comandos a S1. Desde ese punto, todos los comandos de actualización enviados de WC a S1 se escriben en el log binario de S1, que contiene cada comando de actualización enviado S1 desde que M murió.

    El resultado es esta configuración: 

           WC
      /
      |
 WC   |  M(unavailable)
  \   |
   \  |
    v v
     S1<--S2  S3
      ^       |
      +-------+

    Cuando M está activo otra vez, debe ejecutar en la misma máquina CHANGE MASTER como el ejecutado en S2 y S3, así que M llega a ser un esclavo de S1 y recoge todos las escrituras de WC que se ha perdido mientras no estaba activo. Para hacer que M sea un maestro de nuevo (debido a que es la máquina más rápida, por ejemplo), use el anterior protocolo como si S1 no estuviera disponible y M fuera a ser el nuevo maestro. Durante este procedimiento, no olvide ejecutar RESET MASTER en M antes de hacer S1, S2, y S3 esclavos de M. De otro modo, ellos podrían recober antiguas escrituras de WC desde el punto en que M dejó de estar disponible.

Estamos trabajando en integrar un sistema de elección de maestro automático en MySQL, pero hasta que esté preparado, debe crear sus propias herramientas de monitoreo.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.