13.6. Sentencias de replicación

MySQL 5.0

previous page next page

13.6. Sentencias de replicación

Esta sección describe comandos SQL relacionados con replicación. Un grupo de comandos se usa para controlar los servidores maestros. El otro se usa para controlar servidores esclavos.

13.6.1. Sentencias SQL para el control de servidores maestros

La replicación puede controlarse mediante la interfaz SQL. Esta sección discute los comandos para administrar los maestros de replicación. Sección 13.6.2, “Sentencias SQL para el control de servidores esclavos” discute comandos para administrar servidores esclavos.

13.6.1.1. Sintaxis de 

PURGE {MASTER | BINARY} LOGS TO ''
PURGE {MASTER | BINARY} LOGS BEFORE ''

Borra todos los logs binarios listados en el índice de log prévio al log especificado o fecha. Los logs se borran de la lista guardada en el fichero de índice de log, así que el log dado pasa a ser el primero.

Ejemplo: 

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

El argumento de puede estar en formato . y son sinónimos en MySQL 5.0.

Si tiene un esclavo activo que actualmente esté leyendo uno de los logs que está intentando borrar, este comando no hace nada y falla con un error. Sin embargo, si un esclavo está dormido y purga los logs que quiere leer, el esclavo no es capaz de replicar cuando se despierta. El comando puede ejecutarse mientras los esclavos se replican. No necesita pararlos.

Para purgar logs, siga este procedimiento:

  1. En cada servidor esclavo, use para chequear qué log está leyendo.

  2. Obtinga una lista de los logs en el servidor maestro con .

  3. Determine el primer log entre todos los esclavos. Este es el log objetivo. Si todos los esclavos están actualizados, este es el último log de la lista.

  4. Haga una copia de seguridad de todos los logs que vaya a borrar. (Este paso es opcional, pero siempre recomendable.)

  5. Purgue todos los logs hasta el log objetivo, pero no lo incluya.

13.6.1.2. Sintaxis de 

RESET MASTER

Borra todos los logs binarios listados en el fichero índice, resetea el fichero índice de lob binario a vaciar, y recrea un nuevo fichero de log binario.

13.6.1.3. Sintaxis de 

SET SQL_LOG_BIN = {0|1}

Activa o desactiva el logueo binario para la conexión actual ( es una variable de sesión) si el cliente conecta usando una cuenta que tenga el permiso . En MySQL 5.0, el comando se rechaza con un error si el cliente no tiene este permiso.

13.6.1.4. Sintaxis de 

SHOW BINLOG EVENTS
   [IN ''] [FROM ] [LIMIT [,] ]

Muestra los eventos en el log binario. Si no especifica , se muestra el primer log binario.

La cláusula tiene la misma sintaxis que para el comando . Consulte Sección 13.2.7, “Sintaxis de ”.

Nota: Realizar sin cláusula puede iniciar un proceso muy largo y que consume muchos recursos mientras el servidor vuelca los contenidos completos del log binario (lo que incluye la mayoría de las consultas ejecutadas por MySQL) a stdout. Para guardar el log binario en un fichero de texto para analizar posteriormente, use la utilidad mysqlbinlog . Consulte Sección 8.5, “La utilidad mysqlbinlog para registros binarios”.

13.6.1.5. Sintaxis de 

SHOW MASTER LOGS
SHOW BINARY LOGS

Lista los ficheros del log binario en el servidor. Este comando se usa como parte del procedimiento descrito en Sección 13.6.1.1, “Sintaxis de ” para determinar qué logs pueden purgarse. 

mysql> SHOW BINARY LOGS;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000015 |    724935 |
| binlog.000016 |    733481 |
+---------------+-----------+

En MySQL 5.0, , es equivalente a . La columna se muestra desde MySQL 5.0.7.

13.6.1.6. Sintaxis de 

SHOW MASTER STATUS

Proporciona información de estado en los ficheros del log binario del maestro de replicación.

13.6.1.7. Sintaxis de 

SHOW SLAVE HOSTS

Muestra una lista de esclavos de replicación registrados actualmente en el maestro. Cualquier esclavo no arrancado con la opción no es visible en esta lista.

13.6.2. Sentencias SQL para el control de servidores esclavos

La replicación puede controlarse con la interfaz SQL. Esta sección discute comandos para administrar servidores de replicación esclavos. Sección 13.6.1, “Sentencias SQL para el control de servidores maestros” discute comandos para administrar servidores maestros.

13.6.2.1. Sintaxis de 

  CHANGE MASTER TO  [, ] ...

master_def:
      MASTER_HOST = ''
    | MASTER_USER = ''
    | MASTER_PASSWORD = ''
    | MASTER_PORT = 
    | MASTER_CONNECT_RETRY = 
    | MASTER_LOG_FILE = ''
    | MASTER_LOG_POS = 
    | RELAY_LOG_FILE = ''
    | RELAY_LOG_POS = 
    | MASTER_SSL = {0|1}
    | MASTER_SSL_CA = ''
    | MASTER_SSL_CAPATH = ''
    | MASTER_SSL_CERT = ''
    | MASTER_SSL_KEY = ''
    | MASTER_SSL_CIPHER = ''

Cambia los parámetros que usa el servidor esclavo para conectar y comunicar con el servidor maestro.

, , , , , , y proporciona información para el esclavo acerca de cómo conectar con su maestro.

Las opciones SSL (, , , , , y ) pueden cambiarse incluso en esclavos que se compilan sin soporte SSL. Se guardan en el fichero , pero se ignorarn hasta que use un servidor que tenga soporte SSL activado.

Si no especifica un parámetro dado, mantiene su valor antiguo, excepto cuando se indica en la siguiente discusión. Por ejemplo, si la contraseña para conectar a su maestro MySQL ha cambiado, necesita ejecutar este comando para decir al esclavo la nueva contraseña: 

mysql> STOP SLAVE; -- if replication was running
mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret';
mysql> START SLAVE; -- if you want to restart replication

Aquí no hay necesidad de especificar los parámetros que no cambian (equipo, puerto, usuario, y así).

y son el nombre de equipo (o dirección IP) del equipo maestro y su puerto TCP/IP. Tenga en cuenta que si es igual a , entonces, como en otras partes de MySQL, el puerto puede ignorarse (si los ficheros socket Unix pueden usarse, por ejemplo).

Si especifica o , el esclavo asume que el servidor maestro es distinto que antes (incluso si especifica un valor de equipo o de puerto igual que el anterior.) En este caso, los antiguos valores para el log binario del servidor maestro y su posición no se consideran aplicables por más tiempo, así que si no especifica y en el comando y se añaden al final.

y son las coordinadas en que flujo esclavo de entradea/salida debe empezar a leer del maestro la siguiente vez que el flujo arranque. Si especifica alguna de ellas, no puede especificar o . Si no se especifica ni , el esclavo usa las últimas coordenadas del flujo SQL del esclavo antes de realizar . Esto asegura que no hay discontinuidad en la replicación, incluso si el flujo SQL esclavo se comparó posteriormente con el flujo esclavo de entrada/salida, cuando símplemente quiere cambiar, digamos, la contraseña a usar.

borra todos los ficheros de log retardados y arranca uno nuevo, a no ser que especifique o . En tal caso, los logs retardados se guardan; en MySQL 5.0, la variable global se pone a 0.

actualiza los contenidos de los ficheros y .

es útil para inicializar un esclavo cuando tiene una imagen del maestro y ha guardado el log y el desplazamiento correspondientes a la misma. Tras cargar la imagen en el esclavo, puede ejecutar ', MASTER_LOG_POS= en el esclavo.

Ejemplos: 

mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master2.mycompany.com',
    ->     MASTER_USER='replication',
    ->     MASTER_PASSWORD='bigs3cret',
    ->     MASTER_PORT=3306,
    ->     MASTER_LOG_FILE='master2-bin.001',
    ->     MASTER_LOG_POS=4,
    ->     MASTER_CONNECT_RETRY=10;

mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='slave-relay-bin.006',
    ->     RELAY_LOG_POS=4025;

El primer ejemplo cambia el maestro y las coordenadas del log binario del maestro. Esto se usa cuando quiere preparar el esclavo para replicar el maestro.

El segundo ejemplo muestra una operación que se emplea menos frecuentemente. Si se usa cuando el esclavo tiene logs retardados que quiere ejecutar de nuevo por alguna razón. Para ello, el maestro no necesita ser accesible. Sólo necesita usar y arrancar el flujo SQL ().

Incluso puede usar la segunda operación en una configuración de no replicación con un servidor aislado, no esclavo, para recuperación de fallos posteriores. Suponga que su servidor ha fallado y ha restaurado una copia de seguridad. Quiere volver a ejecutar los logs binarios del servidor (no los logs retardados, sino los logs binarios regulares), llamados (por ejemplo) . En primer lugar, haga una copia de seguridad de los logs binarios en un sitio seguro, en caso que no siga exactamente el procedimiento posterior y accidentalmente haga que el servidor purgue los logs binarios. En MySQL 5.0, use para seguridad adicional. Cuando arranca el servidor sin la opción , En su lugar, use las opciones , (para que el servidor crea que los logs binarios regulares son los logs retardados), . Cuando el servidor arranca, ejecute estos comandos: 

mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='myhost-bin.153',
    ->     RELAY_LOG_POS=410,
    ->     MASTER_HOST='some_dummy_string';
mysql> START SLAVE SQL_THREAD;

El servidor lee y ejecuta sus propios logs binarios, permitiendo recuperación de fallos. Una vez que finaliza la recuperación, ejecute , pare el servidor, borre y , y reinicie el servidor con sus opciones originales.

Actualmente, especificar (incluso con un valor de prueba) se necesita para hacer que el servidor piense que es un esclavo. En el futuro, planeamos añadir opciones para evitar estas restricciones menores.

13.6.2.2. Sintaxis de 

LOAD DATA FROM MASTER

Este comando toma una muesta del maestro y la copia en el esclavo. Actualiza los valores de y para que el esclavo comience la replicación desde la posición correcta. Cualquier regla de exclusión de tabla y base de datos especificada con las opciones y se tienen en cuenta. no se tienen en cuenta. Esto es porque un usuario puede, con esta opción, configurar un mapeo no único tal como y , que puede confundir al esclavo al cargar tablas del maestro.

El uso de este comando está sujeto a las siguientes condiciones:

  • Esto sólo funciona con tablas . Intentos de cargar de una tabla no provoca el siguiente error: 

    ERROR 1189 (08S01): Net error reading from master

  • Adquiere un bloqueo de lectura global del maestro al tomar la muesta, que evita actualizaciones en el maestro durante la operación de carga.

En el futuro, planeamos hacer este comando compatible con tablas y eliminar la necesidad de bloqueo de lectura global usando una copia de seguridad no bloqueante en línea.

Si está cargando tablas grandes, puede tener que incrementar los valores de y en los servidores esclavos y maestros. Consulte Sección 5.3.3, “Variables de sistema del servidor”.

Tenga en cuenta que no copia ninguna tabla de la base de datos . Esto hace fácil tener distintos usuarios y permisos en el maestro y el esclavo.

El comando necesita la cuenta de replicación que se usa para conectar con el maesto para tener los permisos y en el maestro y el permiso para todas las tablas maestras que quiera cargar. Todas las tablas del maestro para las que el usuario no tiene el permiso se ignoran por . Esto es porque el maestro las oculta del usuario: llama para conocer las bases de datos a cargar por parte del maestro, pero retorna sólo bases de datos para las que el usuario tenga algunos permisos. Consulte Sección 13.5.4.6, “Sintaxis de ”. En la parte del esclavo, el usuario que ejecuta debe tener permisos para crear y borrar bases de datos y tablas que se copien.

13.6.2.3. Sintaxis de FROM MASTER

LOAD TABLE  FROM MASTER

Transfiere una copia de la tabla desde el maestro al esclavo. Este comando se implementa principalmente para depurar . Requiere que la cuenta usada para conectar con el servidor maestro tenga los permisos y en el maestro y el permiso en la tabla maestra a cargar. En la parte del esclavo, el usuario que ejecuta debe tener permisos para borrar y crear la tabla.

Las condiciones para se aplican aquí. Por ejemplo, funciona sólo en tablas . También se aplican las notas sobre timeouts para .

13.6.2.4. Sintaxis de 

SELECT MASTER_POS_WAIT('', )

Esto es una función, no un comando. Se usa para asegurar que el esclavo ha leído y ejecutado eventos hasta la posición dada en el log binario del maestro. Consulte Sección 12.9.4, “Funciones varias” para una descripción completa.

13.6.2.5. Sintaxis de 

RESET SLAVE

Hace que el esclavo olvide su posición de replicación en el log binario del maestro. Este comando se debe usar para un inicio limpio: borra los ficheros y , todos los logs retardados, y arranca un nuevo log retardado.

Nota: Todos los logs retardados se borran, incluso si no se han ejecutado completamente por parte del flujo SQL esclavo . (Esta es una condición que es probable que exista en un esclavo de replicación si ha ejecutado un comando o si el esclavo está muy cargado.)

La información de conexión almacenada en el fichero se resetea inmediatamente usando cualquier valor especificado en las opciones de arranque correspondientes. Esta información incluye valores tales como el equipo maestro, puerto, usuario y contraseña del maestro. Si el flujo SQL esclavo está en medio de una operación de replicar tablas temporales cuando se paró, y se ejecuta , estas tablas temporales replicadas se borran en el esclavo.

13.6.2.6. Sintaxis de 

SET GLOBAL SQL_SLAVE_SKIP_COUNTER =

Ignora los siguientes eventos del maestro. Esto es útil para recuperarse de paradas de replicación provocadas por un comando.

Este comando es válido sólo cuando el flujo esclavo no está en ejecución. De otro modo, produce un error.

13.6.2.7. Sintaxis de 

SHOW SLAVE STATUS

Proporciona información de estado de parámetros esenciales de los flujos esclavos. Si ejecuta este comando usando el cliente mysql puede usar un terminador de comando en lugar de punto y coma para obtener una salida vertical más legible: 

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          Master_User: root
          Master_Port: 3306
        Connect_Retry: 3
      Master_Log_File: gbichot-bin.005
  Read_Master_Log_Pos: 79
       Relay_Log_File: gbichot-relay-bin.005
        Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
     Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
      Replicate_Do_DB:
  Replicate_Ignore_DB:
           Last_Errno: 0
           Last_Error:
         Skip_Counter: 0
  Exec_Master_Log_Pos: 79
      Relay_Log_Space: 552
      Until_Condition: None
       Until_Log_File:
        Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8

retorna los siguientes campos:

  • Una copia del campo se la salida de para el flujo esclavo de entrada/salida. Le dice si el flujo está tratando de conectar con el maestro, esperando eventos del maestro, reconectando con el maestro, etc. Los estados posibles se listan en Sección 6.3, “Detalles de la implementación de la replicación”. Consultar este campo es necesario porque, por ejemplo, el flujo puede estar en ejecución pero intentando conectar con el maestro sin éxito; sólo este campo le muestra el problema de conexión. El estado del flujo SQL no se copia porque es más simple. Si está en ejecución, no hay problema; si no es así, puede encontrar el error en el campo (descrito posteriormente).

  • Equipo maestro actual

  • Usuario actual usado para conectar con el maestro.

  • Puerto maestro actual.

  • Valor actual de la opción .

  • Nombre del fichero de log binario desde el que está leyendo actualmente el flujo de entrada/salida.

  • La posición hasta la que el flujo de entrada/salida ha leído en el log binario del maestro.

  • Nombre del fichero de log retardado desde el que el flujo SQL está leyendo y ejecutando actualmente.

  • La posición hasta la que el flujo SQL ha leído y ejecutado en el flujo en el log retardado actual.

  • Nombre del log binario maestro que contiene la mayoría de los eventos recientes ejecutados por el flujo SQL.

  • Si el flujo de entrada/salida está activo.

  • Si el flujo SQL está activo.

  • La lista de bases de datos especificadas con las opciones y , si se dió alguna.

  • Lista de tablas especificadas con las opciones , , , y , si se dió alguna.

  • Número y mensaje de error retornados por la última consulta ejecutada. Un número de error 0 y mensaje vacío significa “no error.” Si el valor no está vacío, también aparece como mensaje en el log de errores del esclavo.

    Por ejemplo: 

    Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'

    El mensaje indica que la tabla existió en el maestro y se borró allí, pero no existió en el esclavo, así que falló en el esclavo. (Esto puede ocurrir, por ejemplo, si olvidó copiar la tabla en el esclavo al configurar la replicación.)

  • El último valor usado para .

  • La posición del último evento ejecutado por el flujo SQL del log binario del maestro (). (, ) en el log binario del maestro correspondiente a (, ) en el log retardado.

  • Tamaño total combinado de todos los logs retardados existentes.

  • Valores especificados en la cláusula del comando .

    tiene estos valores:

    • si no se especificó

    • si el esclavo está leyendo hasta una posición dada en el log binario del maestro

    • si el esclavo está leyendo hasta una posición dada en su log retardado

    y indica los valors del nombre de fichero y posición que definen el punto en que el flujo SQL para su ejecución.

  • Estos campos muestran los parámetros SSL usados por el esclavo para conectar con el maestro, si hay algo.

    tiene estos valores:

    • si se permite conexión SSL con el maestro

    • si no se permite una conexión SSL con el maestro

    • se se permite una conexión SSL pero el servidor esclavo no tiene soporte SSL activdo

    Los valores de los otros campos relacionados con SSL se corresponden con los valores de las opciones , , , , y .

  • Este campo indica el “retardo” del esclavo. Cuando el flujo SQL esclavo está en ejecución (procesando actualizaciones), este campo es el número de segundos que han pasado desde el momento del evento más reciente del maestro ejecutado por este flujo. Cuando ese flujo lo atrapa el flujo de entrada/salida esclavo y pasa a espera de más eventos del flujo de entrada/salida este campo es cero. En resumen, este campo mide en segundos la diferencia temporal entre el flujo SQL esclavo y el flujo de entrada/salida esclavo.

    Si la conexión de red entre maestro y esclavo es rápida, el flujo de entrada/salida esclavo es muy cercano al maestro, así que este campo es una buena aproximación de cuanto tarda el flujo SQL esclavo en compararse con el maestro. Si la red es lenta, esta no es una buena aproximación, el flujo SQL esclavo puede verse atrapado a menudo por un flujo de entrada/salida esclavo lento , así que a menudo muestra un valor de 0, incluso si el flujo de entrada/salida se compara posteriormente con el maestro. En otras palabras, esta columna es útil sólo para redes rápidas.

    Esta computación de diferencia temporal funciona incluso si el esclavo y maestro no tienen relojes idénticos ( la diferencia de tiempo se computa cuando el flujo de entrada/ salida del esclavo arranca, y se asume como que permance constante desde ese momento). es (que significa “desconocido”) si el flujo SQL esclavo no está en ejecución, o si el flujo de entrada/salida esclavo no está en ejecución o no conectado con el maestro. Por ejemplo si el flujo de entrada/salida esclavo está durmiendo durante segundos antes de reconectar, se muestra, ya que el esclavo no puede saber lo que hace el maestro, y así no puede asegurar el retardo.

    Este campo tiene una limitación. El timestamp se preserva a través de la replicación, lo que significa que, si un maestr M1 es un esclavo de M0, cualquier evento desde el log binario de M1 que se origine al replicar un evento del log binario M0 tiene el timestamp del evento. Esto permite a MySQL replicar con éxito. Sin embargo, la desventaja para es que si M1 también recibe actualizaciones directas de los clientes, el valor se desvía aleatoriamente, ya que a veces el último evento de M1 es de M0 y otras de actualización directa, y por lo tanto es el timestampo más reciente.

13.6.2.8. Sintaxis de 

START SLAVE [ [, ] ... ]
START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = '', MASTER_LOG_POS = 
START SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = '', RELAY_LOG_POS = 

thread_type: IO_THREAD | SQL_THREAD

sin opciones arranca los flujos esclavos. El flujo de entrada/salida lee consultas del servidor maestro y las almacena en el log retardado. El flujo SQL lee el log retardado y ejecuta las consultas. require el permiso .

Si tiene éxito al arrancar los flujos esclavos, retorna sin ningún error. Sin emgargo, incluso en tal caso, puede ser que el flujo esclavo arranqu y luego pare (por ejemplo, porque no puede conectar con el maestro o leer sus logs binarios, o algún otro problema). no le advierte acerca de esto. Debe chequear el log de errores esclavo para mensajes de error generados por los flujos esclavos, o chequear que estén ejecutándos correctamente con .

En MySQL 5.0, puede añadir las opciones y al comando para decir qué flujo arrancar.

Una cláusula puede añadirse para especificar que el esclavo debe arrancar y ejecutar hasta que el flujo SQL llegue a un punto dado en los logs binarios del maestro o en los logs retardados del esclavo. Cuando el flujo SQL llega a ese punto, para. Si la opción se especifica en el comando, arranca sólo el flujo SQL. De otro modo, arranca ambos flujos esclavos. Si el flujo SQL está en ejecución, la cláusula se ignora y se muestra una advertencia.

Para una cláusula , debe especificar nombre de fichero de log y posición. No mezcle opciones de maestro y log retardado.

Cualquier condición se resetea mediante un comando , un comando que no incluya cláusula , o reinicio de servidor.

La cláusula puede ser útil para depurar replicación, o para que la replicación proceda justo antes del punto en que quiera evitar tener un esclavo replicando un comando. Por ejemplo, si se ejecuta un comando no deseado, puede usar para decir al esclavo que ejecute hasta ese punto pero no más. Para encontrar el evento, use mysqlbinlog con los logs maestros o los logs retardados del esclavo, o usando un comando .

Si está usando para tener las consultas replicadas por el proceso esclavo en secciones, se recomienda que arranque el esclavo con la opción para evitar que el flujo SQL se ejecute cuando arranque el servidor. Es probablemente mejor usar esta opción con un fichero de opciones en lugar que en la línea de comandos, así que un reinicio inesperado del servidor no hace que se olvide.

El comando incluye campos de salida que muestran los valores actuales de la condición .

En versiones prévias de MySQL, este comando se llamó cuyo uso todavía se acepta en MySQL 5.0 por compatibilidad con versiones anteriores, pero ahora está obsoleto.

13.6.2.9. Sintaxis de 

STOP SLAVE [ [, ] ... ]

thread_type: IO_THREAD | SQL_THREAD

Para el flujo esclavo. necesita el permiso .

Como , este comando puede usarse con las opciones y para nombrar el flujo o flujos a parar.

En versiones prévias de MySQL, este comando se llamó . Su uso se acepta en MySQL 5.0 por compatibilidad con versiones anteriores, pero ahora está obsoleto.

previous page start next page