Aprendendo A Programar

INDICE

6. Replicación en MySQL 3

6.1. Introducción a la replicación 3

6.2. Panorámica de la implementación de la replicación 3

6.3. Detalles de la implementación de la replicación 4

6.3.1. Estados de los subprocesos del maestro de replicación 6

6.3.2. Estados de proceso E/S (I/O) del esclavo de replicación 6

6.3.3. Estados del flujo SQL de un esclavo de replicación 7

6.3.4. Ficheros de replicación, retardados y de estado 8

6.4. Cómo montar la replicación 9

6.5. Compatibilidad entre versiones de MySQL con respecto a la replicación 14

6.6. Aumentar la versión de la replicación 14

6.6.1. Aumentar la versión de la replicación a 5.0 14

6.7. Características de la replicación y problemas conocidos 15

6.8. Opciones de arranque de replicación 19

6. Replicación en MySQL

Las capacidades de replicación que permiten a las bases de datos de un servidor MySQL ser duplicadas en otro se introdujeron en MySQL 3.23.15. Este capítulo describe las características de replicación proporcionadas por MySQL . Presenta conceptos de replicación, muestra cómo preparar servidores de replicación, y sirve como referencia para las opciones de replicación disponibles. También proporciona una lista de preguntas frecuentes (con respuestas), y consejos para resolver problemas.

Para una descripción de la sintaxis de comandos SQL relacionados con replicación, consulte Sección 13.6, “Sentencias de replicación”.

Sugerimos que visite nuestra página web http://www.mysql.com frecuentemente así como que chequee para revisiones de este capítulo. La replicación está siendo mejorada constantemente, y actualizamos frecuentemente el manual con la información más actual.

6.1. Introducción a la replicación

Las características de MySQL 5 soportan replicación asíncrona unidireccional: un servidor actúa como maestro y uno o más actúan como esclavos. (Esto contrasta con la replicación síncrona que es una característica de MySQL Cluster — consulte Capítulo 16, MySQL Cluster). El servidor maestro escribe actualizaciones en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, informa al maestro de la posición hasta la que el esclavo ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que han tenido lugar desde entonces, y se bloquea y espera para que el master le envíe nuevas actualizaciones.

Un esclavo servidor puede servir como maestro si quiere preparar una cadena de replicaciones de replicación.

Tenga en cuenta que cuando usa replicación, todas las actualizaciones de las tablas que se replican deben realizarse en el servidor maestro. De otro modo, debe ser cuidadoso para evitar conflictos entre actualizaciones que hacen los usuarios a las tablas en el maestro y las actualizaciones que hacen en las tablas de los esclavos.

La replicación unidireccional tiene beneficios para la robustez, velocidad, y administración del sistema:

• La robustez se incrementa con un escenario maestro/esclavo. En caso de problemas con el maestro, puede cambiar al esclavo como copia de seguridad.

• Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de consultas de clientes a procesar entre los servidores maestro y esclavo. Se puede enviar consultas SELECT al esclavo para reducir la carga de proceso de conultas del maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al maestro, de forma que el maestro y el esclavo no se desincronicen. Esta estrategia de balanceo de carga es efectiva si dominan consultas que no actualizan datos, pero este es el caso más habitual.

• Otro beneficio de usar replicación es que puede realizar copias de seguridad usando un servidor esclavo sin molestar al maestro. El maestro continúa procesando actualizaciones mientras se realiza la copia de seguridad. Consulte Sección 5.8.1, “Copias de seguridad de bases de datos”.

6.2. Panorámica de la implementación de la replicación

La replicación en MySQL se basa en un servidor maestro que toma nota de todos los cambios en las bases de datos (actualizaciones, borrados, y así) en los logs binarios. Por lo tanto, para usar replicación, debe activar el log binario en el servidor maestro. Consulte Sección 5.10.3, “El registro binario (Binary Log)”.

Cada servidor esclavo recibe del maestro las actualizaciones guardadas que el maestro ha guardado en su log binario, de forma que el esclavo puede ejecutar las mismas actualizaciones en su copia de los datos.

Es extremadamente importante tener en cuenta que el log binario simplemente es un registro que comienza en un punto fijo en el tiempo en el que activa el log binario. Cualquier esclavo que inicialice necesita copias de las bases de datos del maestro tal y como estaban en el momento en que activó el log binario en el maestro. Si arranca sus esclavos con bases de datos que no están en el mismo estado que las del maestro cuando arrancó el log binario, es muy posible que fallen sus esclavos.

Una forma de copiar los datos del maestro al esclavo es usar el comando LOAD DATA FROM MASTER . Tenga en cuenta que LOAD DATA FROM MASTER funciona sólo si todas las tablas en el maestro usan el motor de almacenamiento MyISAM. Además, este comando adquiere un bloqueo de lectura global, así que no se puede actualizar el maestro mientras las tablas se transfieren al esclavo. Cuando implementemos la copia en caliente sin bloqueo, ya no será necesario el bloqueo global de lectura.

Debido a estas limitaciones, recomendamos que en este punto use LOAD DATA FROM MASTER sólo si el conjunto de datos en el maestro es relativamente pequeño, o si se puede realizar un bloqueo de lectura prolongado en el maestro. Mientras que la velocidad

...