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 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 SHOW PROCESSLIST 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 SHOW PROCESSLIST ambos flujos estaban en espera de actualizaciones nuevas.

Tenga en cuenta que los valores en la columna Time 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”.