[+/-]
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”.
É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.