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 real de LOAD DATA FROM MASTER puede variar de sistema a sistema, una buena regla de estimar cuánto tarda es 1 segundo por 1MB de datos. Esta es una estimación aproximada, pero puede encontrar que es bastante buena si tanto el maestro como el esclavo son equivalentes a Pentium 700MHz y conectados mediante una red a 100Mbps .

Tras inicializar el esclavo con una copia de los datos del maestro, se conecta al maestro y espera a procesar actualizaciones. Si el maestro falla, o el esclavo pierde conectividad con el maestro, el esclavo sigue intentando conectar periódicamente hasta que es capaz de reanudar la espera de actualizaciones. El intervalo de reintento lo controla la opción --master-connect-retry. Por defecto es de 60 segundos.

Cada esclavo registra dónde lo dejó. El servidor maestro tiene conocimiento de cuántos esclavos hay o cuántos están activos en un momento dado.

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

Las capacidades de replicación de MySQL están implementadas usando tres flujos (uno en el servidor maestro y dos en el esclavo). Cuando se ejecuta un START SLAVE, el esclavo crea un flujo de entrada/salida, que conecta al maestro y le pide que envíe los comandos guardados en su log binario. El maestro crea un flujo para enviar los contenidos del log binario al esclavo. Este flujo puede identificarse como el flujo Binlog Dump en la salida de SHOW PROCESSLIST en el maestro. El flujo de entrada/salida del esclavo lee lo que el flujo Binlog Dump del maestro envía y copia estos datos en ficheros locales, llamados logs retardados, en el directorio de datos del esclavo. El tercer flujo es el flujo SQL, que crea el esclavo para leer los logs retardados y para ejecutar las actualizaciones que contiene.

En la descripción precedente, hay tres flujos por esclavo. Un maestro que tiene varios esclavos crea un flujo para cada esclavo conectado; cada esclavo tiene sus propios flujos de entrada/salida y SQL.

Leer dos comandos y ejecutarlos se divide en dos tareas independientes. La tarea de leer comandos no se ralentiza si la ejecución es lenta. Por ejemplo, si el servidor esclavo no ha estado en ejecución durante un periodo de tiempo, su flujo de entrada/salida puede tratar rápidamente todos los contenidos del log binario del maestro cuando arranca el esclavo, incluso si el flujo SQL se realentiza mucho. Si el esclavo para antes que el flujo SQL haya ejecutado todos los comandos tratados, el flujo de entrada/salida ha tratado todo de forma que hay una copia de los comandos almacenada localmente en los logs retardados, preparados para ejecutarse la siguiente vez que arranque el esclavo. Esto permite que se purguen los logs binarios del maestro, ya que no necesita esperar que los esclavos traten sus contenidos.

El comando SHOW PROCESSLIST proporciona información que le dice qué está ocurriendo en el maestro y en el esclavo teniendo en cuenta la replicación.

El siguiente ejemplo ilustra cómo los tres flujos se muestran en SHOW PROCESSLIST.

En el servidor maestro, la salida de SHOW PROCESSLIST tiene este aspecto:

mysql> SHOW PROCESSLIST\G

*************************** 1. row ***************************

Id: 2

User: root

Host: localhost:32931

db: NULL

Command: Binlog Dump

Time: 94

State: Has sent all binlog to slave; waiting for binlog to

be updated

Info: NULL

Aquí, el flujo 2 es un flujo de replicación para un esclavo

...