CHANGE MASTER TO master_def [, master_def] ...

master_def:
      MASTER_HOST = 'host_name'
    | MASTER_USER = 'user_name'
    | MASTER_PASSWORD = 'password'
    | MASTER_PORT = port_num
    | MASTER_CONNECT_RETRY = count
    | MASTER_LOG_FILE = 'master_log_name'
    | MASTER_LOG_POS = master_log_pos
    | RELAY_LOG_FILE = 'relay_log_name'
    | RELAY_LOG_POS = relay_log_pos
    | MASTER_SSL = {0|1}
    | MASTER_SSL_CA = 'ca_file_name'
    | MASTER_SSL_CAPATH = 'ca_directory_name'
    | MASTER_SSL_CERT = 'cert_file_name'
    | MASTER_SSL_KEY = 'key_file_name'
    | MASTER_SSL_CIPHER = 'cipher_list'

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

MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, y MASTER_SSL_CIPHER proporciona información para el esclavo acerca de cómo conectar con su maestro.

Las opciones SSL (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, y MASTER_SSL_CIPHER) pueden cambiarse incluso en esclavos que se compilan sin soporte SSL. Se guardan en el fichero master.info, 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í).

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

Si especifica MASTER_HOST o MASTER_PORT, 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 MASTER_LOG_FILE y MASTER_LOG_POS en el comando MASTER_LOG_FILE='' y MASTER_LOG_POS=4 se añaden al final.

MASTER_LOG_FILE y MASTER_LOG_POS 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 RELAY_LOG_FILE o RELAY_LOG_POS. Si no se especifica MASTER_LOG_FILE ni MASTER_LOG_POS , el esclavo usa las últimas coordenadas del flujo SQL del esclavo antes de realizar CHANGE MASTER. 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.

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

CHANGE MASTER TO actualiza los contenidos de los ficheros master.info y relay-log.info .

CHANGE MASTER 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 CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master 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 CHANGE MASTER TO y arrancar el flujo SQL (START SLAVE SQL_THREAD).

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) myhost-bin.*. 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 SET GLOBAL relay_log_purge=0 para seguridad adicional. Cuando arranca el servidor sin la opción --log-bin , En su lugar, use las opciones --replicate-same-server-id, --relay-log=myhost-bin (para que el servidor crea que los logs binarios regulares son los logs retardados), --skip-slave-start . 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 STOP SLAVE, pare el servidor, borre master.info y relay-log.info, y reinicie el servidor con sus opciones originales.

Actualmente, especificar MASTER_HOST (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.