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

MySQL 5.0

previous page next page

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 , 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 en la salida de en el maestro. El flujo de entrada/salida del esclavo lee lo que el flujo 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 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 .

En el servidor maestro, la salida de 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 conectado. La información indica que todas las actualizaciones se han enviado al esclavo y que el maestro está esperando más actualizaciones.

En el servidor esclavo, la salida para tiene este aspecto: 

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 10
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Waiting for master to send event
   Info: NULL
*************************** 2. row ***************************
     Id: 11
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O
         thread to update it
   Info: NULL

Esta información indica que el flujo 10 es el flujo de entrada/salida que se comunica con el maestro, y el flujo 11 es el flujo SQL que procesa las actualizaciones almacenadas en los logs retardados. Cuando se ejecuta ambos flujos estaban en espera de actualizaciones nuevas.

Tenga en cuenta que los valores en la columna pueden mostrar la diferencia de tiempo en la comparación del esclavo con el maestro. Consulte Sección 6.9, “Preguntas y respuestas sobre replicación”.

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

La siguiente lista muestra los estados más comunes que puede ver en la columna del flujo maestro . Si no ve ningún flujo en un servidor maestro, esto significa que la replicación no está corriendo — esto es, que no hay ningún esclavo conectado.

  • Los logs binarios consisten en eventos, donde un evento usualmente es una actualicación más otra información. El flujo lee un evento del log binario y lo envía al esclavo.

  • El flujo ha acabado de leer un fichero de log binario y está abriendo el siguiente para enviar al esclavo.

  • El flujo ha leído todas las actualizaciones destacadas del log binario y las ha enviado al esclavo. El flujo ahora está en espera, esperando nuevos eventos en el log binario que resulten en nuevas actualizaciones en el maestro.

  • Estado muy breve que ocurre cuando el flujo está parando.

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

La siguiente lista muestra los estados más comunes que puede ver en la columna para un flujo de entrada/salida en el servidor esclavo. Este estado también aparece en la columna mostrada por . Esto significa que puede obtener una vista muy buena de lo que ocurre simplemente usando este comando.

  • El flujo trata de conectar al maestro.

  • Estado que ocurre brevemente, inmediatamente tras establecer la conexión con el maestro.

  • Estado que ocurre brevemente, inmediatamente tras establecer la conexión con el maestro.

  • Estado que ocurre brevemente, inmediatamente tras establecer la conexión con el maestro. El flujo envía al maestro una petición para los contenidos de su log binario, comenzando por el nombre del log binario pedido y la posición.

  • Si la petición del volcado del log binario falla (debido a una desconexión), el flujo pasa a este estado mientras duerme, luego trata de reconectar periódicamente. El intervalo entre reintentos puede especificarse usando la opción .

  • El flujo está tratando de reconectar con el maestro.

  • El flujo ha conectado con el maestro y está esperando a que lleguen los eventos del log binario. Esto puede tardar un tiempo largo si el maestro está en espera. Si la espera dura segundos, se produce un timeout. En este punto, el flujo considera la conexión rota e intenta reconectar.

  • El flujo ha leído un evento y lo está copiando en el log retardado para que el flujo SQL pueda procesarlo.

  • Un error ocurre durante la lectura (debido a una desconexión). El flujo duerme durante segundos antes de intentar reconectar.

  • El flujo trata de reconectar con el maestro. Cuando la conexión se vuelve a establecer, el estado pasa a .

  • Está usando un valor distinto a cero, y el log retardado ha crecido hasta que su tamaño combinado escede este valor. El flujo de entrada/salida está en espera hasta que el flujo SQL libera suficiente espacio procesando los contenidos del log retardado de forma que pueda leer algunos ficheros de log retardado.

  • Estado que ocurre brevemente al parar el flujo.

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

La siguiente lista muestra los estados más comunes que puede ver en la columna para el flujo SQL del servidor esclavo:

  • El flujo ha leído un evente del log retardado para que el evento pueda ser procesado.

  • El flujo ha procesado todos los eventos en los ficheros de log retardado y está esperando que el flujo de entrada/salida escriba nuevos eventos en el log retardado.

  • Estado breve que ocurre cuando el flujo está parándose.

La columna para el flujo de entrada/salida también puede mostrar el texto de un comando. Esto indica que el flujo ha leído un evento del log retardado, ha extraído el comando de él y lo ha ejecutado.

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

Por defecto, los logs retardados se nombran usando nombres de ficheros de la forma -relay-bin., donde es el nombre del servidor esclavo y es un número de secuencia. Los ficheros de logs retardados sucesivos en MySQL 5.0 se crean usando números de secuencia sucesivos, comenzando a partir de . El esclavo guarda los logs retardados en unso en un fichero índice. El nombre del índice del log retardado por defecto es -relay-bin.index. Por defecto, estos ficheros se crean en el directorio de datos del esclavo. Por defecto los nombres de fichero pueden cambiarse con las opciones de servidor y . Consulte Sección 6.8, “Opciones de arranque de replicación”.

Los logs retardados tienen el mismo formato que los logs binarios, y pueden leerse usando mysqlbinlog. Un log retardado se borra automáticamente por el flujo SQL en cuanto ha ejecutado todos sus eventos y no los necesita más. No hay mecanismo explícito para borrar logs retardados, ya que el flujo SQL se encarga de ello. Sin embargo, rota los logs retardados, lo que influye cuando el flujo SQL los borra.

Un log retardado se crea bajo las siguientes condiciones:

  • En MySQL 5.0, se crea un nuevo log retardado cada vez que arranca el flujo de entrada/salida.

  • Cuando los logs se vuelcan; por ejemplo, con o mysqladmin flush-logs.

  • Cuando el tamaño del log retardado actual es demasiado grande. El significado de "muy grande" se determina así:

    • , si > 0

    • , si = 0

Un servidor esclavo de replicación crea dos pequeños ficheros adicionales en el directorio de datos. Estos ficheros de estado se llaman y por defecto. Contienen información como la mostrada en la salida del comando (consulte Sección 13.6.2, “Sentencias SQL para el control de servidores esclavos” para una descripción de este comando). Como ficheros en disco, sobreviven una parada del servidor esclavo. La siguiente vez que arranca el servidor esclavo, lee estos ficheros para determinar hasta dónde ha procesado los logs binarios del maestro y sus propios logs retardados.

El fichero lo actualiza el flujo de entrada/salida. En MySQL 5.0, la correspondencia entre las líneas en el fichero y las columnas mostradas por es la siguiente:

Línea Descripción
1 Número de líneas en el fichero
2
3
4
5
6 Contraseña (no mostrada por )
7
8
9
10
11
12
13
14

El fichero lo actualiza el flujo SQL. La correspondencia entre las líneas en el fichero y las columnas mostradas por se muestran aquí:

Línea Descripción
1
2
3
4

Cuando hace una copia de seguridad de los datos del esclavo, debe incluir también estos dos ficheros, junto con sus ficheros de log retardado. Son necesarios para reanudar la replicación tras restaurar los datos del esclavo. Si pierde los logs retardados pero todavía tiene el fichero , puede examinarlo para determinar hasta dónde ha ejecutado el flujo SQL en el log binario del maestro. Luego puede usar con las opciones y para decirle al esclavo que vuelva a leer los logs binarios a partir de ese punto. Por supuesto, esto requiere que los logs binarios existan en el servidor maestro.

Si su esclavo está sujeto a replicación de comandos , también debe incluir en la copia de seguridad cualquier fichero que existe en el directorio que el esclavo usa para este propósito. El esclavo necesita estos ficheros para reanudar replicación de cualquier operación interrumpida. La localización del directorio se especifica usando la opción . Si valor por defecto, si no se especifica, es el valor de la variable .

previous page start next page