lunes, 29 de abril de 2013

Replicacion

Introducción a la replicación

Las características de MySQL 5 soportan replicación asíncrona unidireccional: un servidor actúa como maestro y uno o más actúan como esclavos. El servidor maestro escribe actualizaciones en el fichero de log binario, y mantiene un índice de los ficheros para rastrear las rotaciones de logs. Estos logs sirven como registros de actualizaciones para enviar a los servidores esclavos. Cuando un esclavo se conecta al maestro, informa al maestro de la posición hasta la que el esclavo ha leído los logs en la última actualización satisfactoria. El esclavo recibe cualquier actualización que han tenido lugar desde entonces, y se bloquea y espera para que el master le envíe nuevas actualizaciones.
Un esclavo servidor puede servir como maestro si quiere preparar una cadena de replicaciones de replicación.
Tenga en cuenta que cuando usa replicación, todas las actualizaciones de las tablas que se replican deben realizarse en el servidor maestro. De otro modo, debe ser cuidadoso para evitar conflictos entre actualizaciones que hacen los usuarios a las tablas en el maestro y las actualizaciones que hacen en las tablas de los esclavos.
La replicación unidireccional tiene beneficios para la robustez, velocidad, y administración del sistema:
  • La robustez se incrementa con un escenario maestro/esclavo. En caso de problemas con el maestro, puede cambiar al esclavo como copia de seguridad.
  • Puede conseguirse un mejor tiempo de respuesta dividiendo la carga de consultas de clientes a procesar entre los servidores maestro y esclavo. Se puede enviar consultas SELECT al esclavo para reducir la carga de proceso de conultas del maestro. Sin embargo, las sentencias que modifican datos deben enviarse siempre al maestro, de forma que el maestro y el esclavo no se desincronicen. Esta estrategia de balanceo de carga es efectiva si dominan consultas que no actualizan datos, pero este es el caso más habitual.
  • Otro beneficio de usar replicación es que puede realizar copias de seguridad usando un servidor esclavo sin molestar al maestro. El maestro continúa procesando actualizaciones mientras se realiza la copia de seguridad.

    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.

    Características de la replicación y problemas conocidos

    En general, la compatibilidad de la replicación en nivel SQL requiere que cualquier característica usada sea soportado tanto por el maestro como por los servidores esclavos. Por ejemplo, la función TIMESTAMPADD() se implementó en MySQL 5.0.0. Si usa esta función en el maestro, no puede replicar a un servidor esclavo que sea más antiguo que MySQL 5.0.0. Si planea usar replicación entre 5.0 y versiones prévias de MySQL debe consultar el Manual de referencia de MySQL 4.1 para información acerca de las características de replicación en versiones prévias de MySQL.

    • La replicación se da correctamente con AUTO_INCREMENT, LAST_INSERT_ID(), y TIMESTAMP .
    • Las funciones USER(), UUID(), y LOAD_FILE() se replican sin cambios y no funcionan correctamente con el esclavo.
    • Las funciones que tratan bloqueos a nivel de usuario: GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK() se replican sin que el esclavo sepa el contexto de concurrencia del maestro; así que estas funciones no deben usarse para insertar en una tabla del maestro ya que el contexto del esclavo puede diferir (p.e. no haga INSERT INTO mytable VALUES(GET_LOCK(...))).
    • Las variables FOREIGN_KEY_CHECKS, SQL_MODE, UNIQUE_CHECKS, and SQL_AUTO_IS_NULL se replican todas en MySQL 5.0. La variable TABLE_TYPE, también conocida como STORAGE_ENGINE no se replica todavía, lo que es bueno para replicación entre distintos motores de almacenamiento.
    • A partir de MySQL 5.0.3 (maestro y esclavo), la replicación funciona bien incluso si el maestro y el esclavo tienen distintos conjuntos de caracteres globalres. A partir de MySQL 5.0.4 (maestro y esclavo), la replicación funciona bien incluso si el maestro y el esclavo tienen distintas variables de zonas horarias.
    • Lo siguiente se aplica para replicación entre servidores MySQL usando distintos conjuntos de caracteres:
      1. Debe siempre usar las mismas colaciones y conjuntos de caracteres globales (--default-character-set, --default-collation) en el maestro y esclavo. De otro modo, puede obtener errores de claves duplicadas en el esclavo, debido a que una clave que se trata como única en el conjunto de caracteres del maestro puede no ser único en el conjunto de caracteres del esclavo.
      2. Si el maestro es anterior a MySQL 4.1.3, el conjunto de caracteres de la sesión nunca debería ser distinto al del valor global (en otras palabras, no use SET NAMES, SET CHARACTER SET, y así) ya que este cambio del conjunto de caracteres no es conocido por el esclavo. Si tanto el maestro coom el esclavo son de la versión 4.1.3 o posterior, la sesión puede cambiar los valores locales del conjunto de caracteres (tales como NAMES, CHARACTER SET, COLLATION_CLIENT, y COLLATION_SERVER) ya que estos cambios se escriben en el log binario y son conocidos por el esclavo. Sin embargo, la sesión no puede cambiar estos valores globales ya que el maestro y esclavo deben tener conjuntos de caracteres idénticos.
      3. Si tiene bases de datos en el maestro con distintos conjuntos de caracteres al valor global de collation_server , debe diseñar su comando CREATE TABLE que no se base en el conjunto de caracteres por defecto de la base de datos, ya que actualmente hay un bug (Bug #2326); una solución es poner el conjunto de caracteres y colación explícitamente en CREATE TABLE.
    • Tanto el maestro como el esclavo deben tener la misma zona horaria. De otro modo algunos comandos, por ejemplo comandos que usen NOW() o FROM_UNIXTIME() no se replicarán apropiadamente. Se podría poner una zona horaria en que el servidor MySQL se ejecute usando la opción --timezone=timezone_name del script mysqld_safe o asignando un valor a la variable de entorno TZ. Tanto el maestro como el esclavo deben tener la misma zona horaria para las conexiones; esto es, el parámetro --default-time-zone debe tener el mismo valor para maestro y servidor.
    • CONVERT_TZ(...,...,@global.time_zone) no se replica apropiadamente. CONVERT_TZ(...,...,@session.time_zone) se replica apropiadamente sólo si el maestro y esclavo son de la versión 5.0.4 o posterior.
    • Las variables de sesión no se replican apropiadamente cuando se usan en comandos que actualizan tablas; por ejemplo: SET MAX_JOIN_SIZE=1000; INSERT INTO mytable VALUES(@MAX_JOIN_SIZE); no insertará los mismos datos en el maestro y el esclavo. Esto no se aplica a SET TIME_ZONE=...; INSERT INTO mytable VALUES(CONVERT_TZ(...,...,@time_zone)), que se arregla en MySQL 5.0.4.
    • Es posible replicar tablas transaccionales en el maestro usando tablas no transaccionales en el esclavo. Por ejemplo, puede replicar una tabla maestra InnoDB como una tabla esclava MyISAM . Sin embargo, si lo hace, hay problemas si el esclavo se para en medio de un bloque BEGIN/COMMIT , ya que el esclavo reinicia al principio del bloque BEGIN . Este tema se encuentra en la lista de temas pendientes y se arreglará próximamente.
    • Los comandos de actualización que se refieren a variables de usuario (esto es, variables de la forma @var_name) se replican correctamente en MySQL 5.0; sin embargo esto no es cierto para versiones prévias a 4.1. Tenga en cuenta que los nombres de las variables de usuario no son sensibles a mayúsculas desde MySQL 5.0; debe tener esto en cuenta cuando prepare una replicación entre 5.0 y versiones antiguas.
    • Los esclavos MySQL 5.0 pueden conectar a maestros 5.0 usando SSL.
    • En MYSQL 5.0 (desde 5.0.3), hay una variable de sistema global slave_transaction_retries: Si el flujo SQL del esclavo de replicación falla al ejecutar una transacción debido a un deadlock InnoDB o excede el innodb_lock_wait_timeout de InnoDB o TransactionDeadlockDetectionTimeout o TransactionInactiveTimeout de NDB, automáticamente reintenta slave_transaction_retries veces antes de parar con un error. El valor por defecto en MySQL 5.0 es 10. A partir de MySQL 5.0.4, el número total de reintentos pueden verse en la salida de SHOW STATUS;
    • Si DATA DIRECTORY o INDEX DIRECTORY se usa en un comando CREATE TABLE en el maestro, la cláusula se usa en el esclavo. Esto puede causar problemas si no existe el directorio correspondiente en el sistema de ficheros del esclavo o existe pero no es accesible en el esclavo. MySQL 5.0 soporta una opción sql_mode llamada NO_DIR_IN_CREATE. Si el esclavo se ejecuta con este modo SQL , ignora estas cláusulas al replicar el comando CREATE TABLE . El resultado es que los datos MyISAM y ficheros índice se crean en el directorio de la base de datos de la tabla.
    • Es posible que los datos del maestro y el esclavo diverjan si se diseña una consulta tal que la modificación de los datos no sea determinista; esto es, si se deja a criterio del optimizador de consultas. (Esto no es generalmente una buena práctica en ningún caso, incluso fuera de la replicación.)
    • Lo siguiente se aplica sólo si el maestro o el esclavo están ejecutando la versión 5.0.3 o anterior: Si se interrumpe un LOAD DATA INFILE en el maestro (violación de integridad, conexión muerta, o así), el esclavo ignora el LOAD DATA INFILE totalmente. Esto significa que si este comando inserta o actualiza registros en tablas de forma permanente antes de interrumpirse, estas modificaciones no se replican en el esclavo.
    • FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, y FLUSH TABLES WITH READ LOCK no se loguean ya que cualquiera de ellos puede causar problemas al replicarse en un esclavo.) Para un ejemplo de sintaxis, FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE, y REPAIR TABLE se escriben en el log binario y por lo tanto se replican en los esclavos. Esto no es un problema normalmente porque estos comandos no modifican los datos de las tablas. Sin embaargo, esto puede causar dificultades bajo ciertas circunstancias. Si replica las tablas de privilegios en la base de datos mysql y actualiza estas tablas directamente sin usar GRANT, debe ejecutar un comando FLUSH PRIVILEGES en los esclavos para poner los nuevos privilegios en efecto. Además, si usa FLUSH TABLES cuando queda una tabla MyISAM que es parte de una tabla MERGE , debe ejecutar un FLUSH TABLES manualmente en los esclavos. En MySQL 5.0, estos comandos se escriben en el log binario a no ser que especifique NO_WRITE_TO_BINLOG o su alias LOCAL.
    • MySQL sólo soporta un maestro y varios esclavos. En el futuro planeamos añadir un algoritmo de voto para cambiar el maestro automáticamente en caso de problemas con el maestro actual. También planeamos introducir procesos agentes para ayudar a realizar balanceo de carga mandando consultas SELECT a distintos esclavos.
    • Cuando un servidor para y reinicia, sus tablas MEMORY (HEAP) se vacían . En MySQL 5.0, el maestro replica este efecto como sigue: La primera vez que el maestro usa cada tabla MEMORY tras arrancar, lo notifica a los esclavos que la tabla necesita vacíar escribiendo un comando DELETE FROM para esa tabla en el log binario.
    • Las tablas temporales se replican excepto en el caso donde para el esclavo (no sólo los flujos esclavos) y ha replicado tablas temporales que se usan en actualizaciones que no se han ejecutado todavía en el esclavo. Si para el esclavo, las tablas temporales necesitadas por estas actualizaciones no están disponibles cuando el esclavo se reinicia. Para evitar este problema, no pare el esclavo mientras tiene tablas temporales abiertas. En lugar de eso, use el siguiente procedimiento:
      1. Ejecute un comando STOP SLAVE .
      2. Use SHOW STATUS para chequear el valor de la variable Slave_open_temp_tables .
      3. Si el valor es 0, ejecute un comando mysqladmin shutdown para parar el esclavo.
      4. Si el valor no es 0, reinicie los flujos esclavos con START SLAVE.
      5. Repita el procedimiento posteriormente para comprobar si tiene mejor suerte la próxima vez.
      Planeamos arreglar este problema en el futuro cercano.
    • Es correcto conectar servidores de modo circular en una relación maestro/esclavo con la opción --log-slave-updates. Tenga en cuenta, sin embargo, que varios comandos no funcionan correctamente en esta clase de inicialización a no ser que su código cliente esté escrito para tener en cuenta que pueden ocurrir actualizaciones en distintas secuencias de diferentes servidores.
      Esto significa que puede crear una inicialización como esta: 
      A -> B -> C -> A
      Los IDs de los servidores se codifican en los logs binarios de eventos, así que el servidor A conoce cuando un evento que lee fue creado originalmente por sí mismo y no ejecuta el evento ( a no ser que el servidor A se iniciara con la opción --replicate-same-server-id, que tiene significado sólo en inicializaciones raras). Por lo tanto, no hay bucles infinitos. Sin embargo, esta inicialización circular funciona sólo si no realiza actualizaciones conflictivas entre tablas. En otras palabras, si inserta datos tanto en A y C, no debe insertar un registro en A que pueda tener una clave que entre en conflicto con un registro insertado en C. Tampoco debe actualizar el mismo registro en dos servidores si el orden de las actualizaciones es significativo.
    • Si un comando en el esclavo produce un error, el flujo esclavo SQL termina, y el esclavo escribe un mensaje en su log de errores. Luego debe conectar al esclavo manualmente, arreglar el problema (por ejemplo, una tabla no existente), y luego ejecutar START SLAVE.
    • Es correcto parar un maestro y reiniciarlo posteriormente. Si un esclavo pierde su conexión con el maestro, el esclavo trata de reconectar inmediatamente. Si falla, el esclavo reintenta periódicamente. (Por defecto reinicia cada 60 segundos. Esto puede cambiarse con la opción --master-connect-retry .) El esclavo también es capaz de tratar con problemas de conectividad de red. Sin embargo, el esclavo se da cuenta del problema de red sólo tras no recibir datos del maestro durante slave_net_timeout segundos. Si los problemas son cortos, puede decrementar slave_net_timeout.
    • Parar el esclavo (correctamente) es seguro, ya que toma nota de dónde lo dejó. Las paradas no correctas pueden producir problemas, especialmente si la caché de disco no se volcó a disco antes que parara el sistema. La tolerancia a fallos del sistema se incrementa generalmente si tiene proveedores de corriente ininterrumpidos. Las paradas no correctas del maestro pueden causar inconsistencias entre los contenidos de tablas y el log binario en el maestro; esto puede evitarse usando tablas InnoDB y la opción --innodb-safe-binlog en el maestro. Consulte.
    • Debido a la naturaleza no transaccional de las tablas MyISAM, es posible tener un comando que actualice parcialmente una tabla y retorne un código de error. Esto puede ocurrir, por ejemplo, en una inserción de varios registros que tenga un registro que viole una clave, o si una actualización larga se mata tras actualizar algunos de los registros. Si esto ocurre en el maestro, el flujo esclavo sale y para hasta que el administrador de base de datos decida qué hacer acerca de ello a no ser que el código de error se legitime y la ejecución del comando resulte en el mismo código de error. Si este comportamiento de validación de código de error no es deseable, algunos o todos los errores pueden ser ignorados con la opción --slave-skip-errors .
    • Si actualiza tablas transaccionales para tablas no transaccionales dentro de una secuencia BEGIN/COMMIT , las actualizaciones del log binario pueden desincronizarse si la tabla no transaccional se actualiza antes de que acabe la transacción. Esto se debe a que la transacción se escribe en el log binario sólo cuando acaba.
    • En situaciones donde las transacciones mezclan actualizaciones transaccionales y no transaccionales, el orden de los comandso en el log binario es correcto , y todos los comandos necesarios se escriben en el log binario incluso en caso de un ROLLBACK). Sin embargo, cuando una segunda conexión actualiza la tabla no transaccional antes que la primera transacción se complete, los comandos pueden loguearse fuera de orden, ya que la actualización de la segunda conexión se escribe inmediatamente al ejectarse, sin tener en cuenta el estado de la transacción que se ejecuta en la primera conexión.

      Opciones de arranque de replicación

      Tanto en el maestro como el esclavo, debe usar la opción server-id para establecer un ID de replicación único para cada servidor. Debe elegir un entero positivo único en el rango de 1 a 2^32 - 1 para cada maestro y esclavo. Ejemplo: server-id=3
      La siguiente tabla describe las opciones que puede usar en servidores esclavos de replicación MySQL 5.0. Puede especificar estas opciones por línea de comandos o en un fichero de opciones.
      Algunas opciones de replicación del esclavo se tratan de forma especial, en el sentido que se ignoran si existe un fichero master.info cuando el esclavo arranca y contiene valores para las opciones. Las siguientes opciones se tratan de este modo:
      • --master-host
      • --master-user
      • --master-password
      • --master-port
      • --master-connect-retry
      • --master-ssl
      • --master-ssl-ca
      • --master-ssl-capath
      • --master-ssl-cert
      • --master-ssl-cipher
      • --master-ssl-key
      El fichero master.info en formato 5.0 incluye valores correspondientes a las opciones SSL. Además, el formato del fichero incluye como primer línea el número de líneas en el fichero. Si actualiza de un servidor antiguo a uno nuevo, el nuevo servidor actualiza el fichero master.info al nuevo formato automáticamente cuando arranca. Sin embargo, si baja de versión un servidor nuevo a una versión antigua, debe borrar la primera línea manualmente antes de arrancar el servidor antiguo la primera vez.
      Si no existe un fichero master.info cuando arranca el esclavo, usa los valores para estas opciones que se especifican en el fichero de opciones o en línea de comandos. Esto ocurre cuando arranca el servidor como un esclavo de replicación la primera vez, o cuando ha ejecutado RESET SLAVE y luego ha parado y rearrancado el esclavo.
      Si el fichero master.info existe cuando el esclavo arranca, el servidor ignora estas opciones. En su lugar, usa los valores encontrados en el fichero master.info .
      Si reinicia el esclavo con valores distintos de las opciones de arranque que corresponden a los valores en el fichero master.info , los valores diferentes no tienen efecto, ya que el servidor continúa usando el fichero master.info . Para usar valores distintos, debe reiniciar tras borrar el fichero master.info o (preferiblemente) use el comando CHANGE MASTER TO para reiniciar los valores mientras el esclavo está corriendo.
      Soponga que especifica estas opciones en su fichero my.cnf : 
      [mysqld]
master-host=some_host
      La primera vez que arranca el servidor como esclavo de replicación, lee y usa esta opción del fichero my.cnf. El servidor guarda el valor en el fichero master.info . La siguiente vez que arranque el servidor, lee el valor de la máquina maestra sólo desde el fichero master.info e ignora el valor en el fichero de opciones. Si modifica el fichero my.cnf para especificar un equipo maestro distinto a some_other_host, el cambio todavía no tiene efecto. Debe usar CHANGE MASTER TO en su lugar.
      Debido a que el servidor da una precedencia al fichero master.info sobre las opciones de arranque descritas, puede no usar las opciones de arranque para estos valores, y en su lugar especificarlos usando el comando CHANGE MASTER TO .
      Este ejemplo muestra un uso más extensivo de las opciones de arranque para configurar un esclavo: 
      [mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com
      La siguiente lista describe opciones de arranque para controlar la replicación: Muchas de estas opciones pueden cambiarse con el servidor en ejecución usando el comando CHANGE MASTER TO. Otras, tales como las opciones --replicate-*, sólo pueden cambiarse cuando arranca el esclavo. Planeamos arreglar esto.
      • --log-slave-updates
        Normalmente, las actualizaciones recibidas por un servidor maestro por un esclavo no se loguean en el log binario. Esta opción le dice al esclavo que loguee las actualizaciones realizadas por el flujo SQL en el log binario del esclavo. Para que esta opción tenga efecto, el esclavo debe arrancarse con la opción --log-bin para permitir logueo binario. --log-slave-updates se usa cuando quiere encadenar servidores de replicación . Por ejemplo, puede hacer una inicialización como esta: 
        A -> B -> C
        Esto es , A sirve como maestro para el esclavo B, y B sirve como maestro para el esclavo C. Para que funcione, B debe ser tanto maestro como esclavo. Debe arrancar tanto A como B con --log-bin para permitir logueo binario, y B con la opción --log-slave-updates .
      • --log-warnings
        Hace que el esclavo muestre más mensajes en el log de errores acerca de qué está haciendo. Por ejemplo, le advierte que ha podido reconectar tras un error de red, y le informa cada vez que arrancan los flujos del esclavo. Esta opción está activada por defecto en MySQL 5.0; para desactivarla, use --skip-log-warnings. En MySQL 5.0, las conexiones abortadas no se loguean en el log de errores a no ser que el valor sea mayor que 1.
        Tenga en cuenta que los efectos de esta opción no están limitados a replicación. Produce advertencias a través de un espectro de actividades de servidor.
      • --master-connect-retry=seconds
        Número de segundos que el flujo esclavo duerme antes de reintentar conectar al maestro en caso que caiga el maestro o se pierda la conexión. El valor en el fichero master.info tiene precedencia si puede leerse. Si no está especificado, por defecto es 60.
      • --master-host=host
        El nombre de equipo o número IP del maestro. Si no se da esta opción, el flujo esclavo no arranca. El valor en master.info tiene precedencia si puede leerse.
      • --master-info-file=file_name
        Nombre a usar para el fichero en que el esclavo guarda información acerca del maestro. El nombre por defecto es mysql.info en el directorio de datos.
      • --master-password=password
        Contraseña de la cuenta que el flujo esclavo usa para autenticar al conectar al maestro. El valor en el fichero master.info tiene precedencia si puede leerse. Si no está asignado, se asume la contraseña vacía.
      • --master-port=port_number
        El puerto TCP/IP en que está escuchando el maestro. El valor en el fichero master.info tiene precedencia si puede leerse. Si no está asignado, se usa la especificación compilada. Si no ha cambiado las opciones de configure debería ser 3306.
      • --master-ssl, --master-ssl-ca=file_name , --master-ssl-capath=directory_name , --master-ssl-cert=file_name , --master-ssl-cipher=cipher_list , --master-ssl-key=file_name
        Estas opciones se usan para preparar una conexión de replicación segura al maestro usando SSL. Sus significados son los mismos que los de las opciones correspondientes --ssl, --ssl-ca, --ssl-capath, --ssl-cert, --ssl-cipher, --ssl-key. Los valores en el fichero master.info tienen precedencia si pueden leerse.
      • --master-user=username
        El nombre de usuario que el flujo esclavo usa para autenticar al conectar con el maestro. En MySQL 5.0, esta cuenta debe tener el privilegio REPLICATION SLAVE . El valor en el fichero master.info , si puede leerse, tiene precedencia. Si el usuario maestro no está inicializado, se asume el usuario test .
      • --max-relay-log-size=#
        Para rotar el log retardado automáticamente.
      • --read-only
        Esta opción hace que el esclavo no permita ninguna actualización excepto de flujos esclavos o de usuarios con el privilegio SUPER . Esto puede ser útil para asegurar que un servidor esclavo no acepta actualizaciones de los clientes.
      • --relay-log=file_name
        El nombre para el log retardado. El nombre por defecto es host_name-relay-bin.nnnnnn, donde host_name es el nombre del esclavo y nnnnnn indica que los logs retardados se crean en secuencia enumerada. Puede especificar la opción para crear nombres de logs retardados independientes del nombre de la máquina, o si sus logs retardados tieneden a ser grandes ( y no quiere decrementar max_relay_log_size) y necesita ponerlos en algún área distinta del directorio de datos, o si quiere incrementar la velocidad balanceando carga entre discos.
      • --relay-log-index=file_name
        Localización y nombre que deben usarse para el fichero índice del log retardado. El nombre por defecto es host_name-relay-bin.index, donde host_name es el nombre del esclavo.
      • --relay-log-info-file=file_name
        El nombre a usar por el fichero en que el esclavo guarda información acerca del log retardado. El nombre por defecto es relay-log.info en el directorio de datos.
      • --relay-log-purge={0|1}
        Desactiva o activa la purga automática del log retardado en cuanto no se necesitan más. El valor por defecto es 1 (activado). Esta es una variable global que puede cambiarse dinámicamente con SET GLOBAL relay_log_purge.
      • --relay-log-space-limit=#
        Especifica un límite superior del tamaño total de todos los logs retardados en el esclavo (un valor de 0 significa que no hay limitación de tamaño). Esto es útil para un esclavo con espacio de disco limitado. Cuando se alcanza el límite, el flujo de entrada/salida para de leer eventos del log binario del maestro hasta que el flujo SQL borra algunos logs retardados no usados. Tenga en cuenta que este límite no es absoluto: Hay casos donde el flujo SQL necesita más eventos antes que pueda borrar logs retardados. En tal caso, el flujo de entrada/salida excede el límite hasta que es posible para el flujo SQL borrar algunos logs retardados. (El no hacerlo causaría un deadlock.) No debe asignar --relay-log-space-limit un valor menor al doble del valor de --max-relay-log-size (o --max-binlog-size si --max-relay-log-size es 0). En tal caso, hay una oportunidad que el flujo de entrada/salida espere espacio libre debido a que se excede --relay-log-space-limit, pero el flujo SQL no tiene log retardado para purgar y es incapaz de satisfacer el flujo de entrada/salida. Esto fuerza al flujo de entrada/salida a que ignore temporalmente --relay-log-space-limit.
      • --replicate-do-db=db_name
        Le dice al esclavo que restrinja replicación a comandos donde la base de datos por defecto (esto es, la seleccionada por USE) es db_name. Para especificar más de una base de datos, use esta opción múltiples veces, una para cada base de datos. Tenga en cuenta que esto no replica comandos entre bases de datos tales como UPDATE some_db.some_table SET foo='bar' mientras se haya seleccionado una base de datos distinta o ninguna base de datos. Si necesita actualizaciones entre bases de datos distintas use --replicate-wild-do-table=db_name.%. Por favor lea las notas que hay a continuación de esta lista de opciones.
        Un ejemplo de lo que no funciona como podría esperar: Si el esclavo arranca con --replicate-do-db=sales y realiza el siguiente comando en el maestro, el comando UPDATE no se replica: 
        USE prices;
UPDATE sales.january SET amount=amount+1000;
        Si necesita que funcionen actualizaciones entre varias bases de datos, use --replicate-wild-do-table=db_name.% en su lugar.
        La razón principal para este comportamiento “sólo chequee la base de datos por defecto ” es que es difícil para el comando conocer si debe o no debe ser replicado (por ejemplo, si está usando comandos DELETE de múltiples tablas o comandos UPDATE de múltiples tablas que actúan entre múltiples bases de datos). También es más rápido chequear sólo la base de datos por defecto en lugar de todas las bases de datos si no hay necesidad.
      • --replicate-do-table=db_name.tbl_name
        Le dice al flujo esclavo que restrinja replicación a la tabla especificada. Para especificar más de una tabla, use esta opción múltiples veces, una para cada tabla. Esto funciona para actualizaciones entre bases de datos, en contraste con --replicate-do-db. Lea los comentarios a continuación de esta lista de opciones.
      • --replicate-ignore-db=db_name
        Le dice al esclavo que no replique ningún comando donde la base de datos por defecto (esto es, la seleccionada por USE) es db_name. Para especificar más de una base de datos a ignorar, use esta opción múltiples veces, una para cada base de datos. No debe usar esta opción si está usando actualizaciones entre bases de datos y no quiere que estas acutalizaciones se repliquen. Lea las notas después de esta lista de opciones.
        Une ejemplo de lo que no funciona como podría esperar: Si el esclavo arranca con --replicate-ignore-db=sales y ejecuta el siguiente comando en el maestro, el comando UPDATE se replica not : 
        USE prices;
UPDATE sales.january SET amount=amount+1000;
        Si necesita que funcionen actualizaciones entre bases de datos, use --replicate-wild-ignore-table=db_name.% en su lugar.
      • --replicate-ignore-table=db_name.tbl_name
        Le dice al esclavo que no replique ningún comando que actualice la tabla especificada (incluso si otras tablas se actualizan en el mismo comando). Para especificar más de una tabla a ignorar, use esta opción múltiples veces, una para cada tabla. Esto funciona para actualizaciones entre bases de datos, en contraste con --replicate-ignore-db. Lea los comentarios a continuación de esta lista de opciones.
      • --replicate-wild-do-table=db_name.tbl_name
        Le dice al esclavo que restrinja la replicación a comandos donde cualquiera de las tablas actualizadas coincida con el patrón de base de datos y tabla. Los patrones pueden contener el comodín '%' and '_' , que tiene el mismo significado que para el operador LIKE . Para especificar más de una tabla, use esta opción múltiples veces, una para cada tabla. Esto funciona para actualizaciones entre bases de datos. Lea los comentarios a continuación de esta lista de opciones.
        Ejemplo: --replicate-wild-do-table=foo%.bar% replica sólo actualizaciones que usen una tabla donde el nombre de la base de datos comience con foo y el nombre de la tabla comienza con bar.
        Si el patrón del nombre de la tabla es %, coincide con cualquier nombre de tabla y la opción se aplica a commandos a nivel de base de datos (CREATE DATABASE, DROP DATABASE, y ALTER DATABASE). Por ejemplo, si usa --replicate-wild-do-table=foo%.%, comandos a nivel de base de datos se replican si el nombre de la base de datos coinciden con el patrón foo%.
        Para incluir caracteres comodín literales en el nombre de la base de datos o de tabla, debe introducir un carácter de antibarra de escape. Por ejemplo, para replicar todas las tablas de una base de datos que se llama my_own%db, pero no replicar tablas de la base de datos my1ownAABCdb , debe escapar los caracteres '_' y '%' así: --replicate-wild-do-table=my\_own\%db. Si usa la opción en la línea de comandos, puede necesitar doblar las antibarras o poner el valor de la opción entre comillas, dependiendo del intérprete de comandos. Por ejemplo, con el shell bash , tendría que escribir --replicate-wild-do-table=my\\_own\\%db.
      • --replicate-wild-ignore-table=db_name.tbl_name
        Le dice al esclavo que no replique un comando donde cualquier tabla coincida con el patrón dado. Para especificar más de una tabla a ignorar, use esta opción múltiples veces, una para cada tabla. Esto funciona para actualizaciones entre bases de datos. Lea los comentarios a continuación de esta lista de opciones.
        Ejemplo: --replicate-wild-ignore-table=foo%.bar% no replica actualizaciones que use una tabla donde el nombre de la base de datos comience con foo y el nombre de tabla comience con bar.
        Para información acerca de cómo funcionan las coincidencias, consulte la descripción de la opción --replicate-wild-do-table . Las reglas para incluir caracteres comodín en la opción son las mismas que para --replicate-wild-ignore-table .
      • --replicate-rewrite-db=from_name->to_name
        Le dice al esclavo que traduzca la base de datos por defecto (esto es, la seleccionada por USE) a to_name si era from_name en el maestro. Sólo los comandos que tengan que ver con tablas están afectados (no comandos tales como CREATE DATABASE, DROP DATABASE, y ALTER DATABASE), si y sólo si from_name era la base de datos por defecto en el maestro. Esto no funciona para actualizaciones entre bases de datos. Tenga en cuenta que la traducción del nombre de la base de datos se hace antes que se testeen las reglas de --replicate-*.
        Si usa esta opción en la línea de comandos y el carácter '>' es especial en su intérprete de comandos, ponga entre comillas el valor de la opción. Por ejemplo: 
        shell> mysqld --replicate-rewrite-db="olddb->newdb"
      • --replicate-same-server-id
        Para usar en esclavos. Usualmente puede usar el valor por defecto de 0, para evitar bucles infinitos en replicación circular. Si se pone a 1, este esclavo no evita eventos que tengan su propio id de servidor; normalmente esto es útil sólo en configuraciones raras. No puede ponerse a 1 si se usa --log-slave-updates . Tenga en cuenta que por defecto el flujo de entrada/salida del esclavo no escribe eventos en el log binario si tiene el id del esclavo (esta optimización ayuda a ahorrar espacio de disco). Así que si quiere usar --replicate-same-server-id, asegúrese de arrancar el esclavo con esta opción antes de hacer que el esclavo lea sus propios eventos que quiera que ejecute el flujo SQL del esclavo.
      • --report-host=slave_name
        El nombre de máquina o número IP del esclavo que debe reportar al maestro durante el registro del esclavo. Este valor aparece en la salida de SHOW SLAVE HOSTS en el maestro. No ponga ningún valor si no quiere que el esclavo se registre él mismo en el maestro. Tenga en cuenta que no es suficiente para el maestro leer el número IP del esclavo en el socket TCP/IP una vez que el esclavo conecte. Debido a NAT y otros elementos de enrutamiento, esa IP puede no ser válida para conectar del esclavo al maestro y otros equipos.
      • --report-port=slave_port
        El número de puerto TCP/IP para conectar al esclavo, a ser reportado al maestro durante el registro del esclavo. Asigne un valor sólo si el esclavo está escuchando en un puerto no estándar o si tiene un túnel especial desde el maestro u otros clientes al esclavo. Si no está seguro, deje esta opción sin asignar ningún valor.
      • --skip-slave-start
        Le dice a un esclavo que no arranque el flujo del esclavo cuando el servidor arranque. Para arrancar el flujo posteriormente, use START SLAVE .
      • --slave_compressed_protocol={0|1}
        Si se pone esta opción a 1, use compresión para el protocolo esclavo/maestro si ambos lo soportan.
      • --slave-load-tmpdir=file_name
        Nombre del directorio en el que el esclavo crea ficheros temporales. Esta opción por defecto es el valor de la variable de sistema tmpdir . Cuando el flujo SQL del esclavo replica un comando LOAD DATA INFILE, extrae el fichero a ser cargado del log retardado en ficheros temporales, luego los carga en la tabla .Si el fichero cargado en el maestro es muy grande, los ficheros temporales en el esclavo también lo son. Por lo tanto, es una buena idea usar esta opción para decirle al esclavo que ponga los ficheros temporales en un sistema de ficheros con mucho espacio disponible. En tal caso, puede usar la opción --relay-log en ese sistema de ficheros, debido a que los logs retardados también son muy grandes. --slave-load-tmpdir debe apuntar un sistema de ficheros en disco, no en memoria. El esclavo necesita los ficheros temporales usados para replicar LOAD DATA INFILE para sobrevivir a un reinicio de la máquina. El directorio no debe ser uno que limpie el sistema operativo durante el arranque.
      • --slave-net-timeout=seconds
        El número de segundos a esperar para más datos del maestro antes de abortar la lectura, considerando la conexión rota y tratando de reconectar. El primer reintento se hace inmediatamente tras el timeout. El intervalo entre reintentos se controla mediante la opción --master-connect-retry .
      • --slave-skip-errors= [err_code1,err_code2,... | all]
        Normalmente, la replicación para cuando ocurre un error, lo que le da la oportunidad de resolver la inconsistencia en los datos manualmente. Esta opción le dice al flujo SQL esclavo que continue la replicación cuando un comando retorna cualquiera de los errores listados en la opción.
        No use esta opción a no ser que entienda porqué esta obteniendo opciones. Si no hay bugs en la preparación de la replicación ni en los programas cliente, y no hay bugs en el propio MySQL, nunca ocurre un error que pare la replicación. El uso indiscriminado de esta opción provoca que el esclavo pueda quedar desincronizado con el maestro, sin que usted sepa porqué ha ocurrido.
        Para códigos de error, debe usar los números proporcionados por el mensaje de error en su log de errores del esclavo y en la salida de SHOW SLAVE STATUS.
        También puede (pero no debería) usar el valor no recomendable de all que ignora todos los mensajes de error y continúa funcionando sin tener en cuenta qué ocurre. No hace falta decir que, si lo usa, no podemos garantizar la integridad de los datos. Por favor no proteste (ni envíe reportes de bug) en este caso si los datos del esclavo no se parecen a lo que hay en el maestro. Le hemos advertido.
        Ejemplos: 
        --slave-skip-errors=1062,1053
--slave-skip-errors=all
      Las reglas --replicate-* se evalúan como se explica para determinar si un comando se ejecuta por el esclavo o se ignora:
      1. ¿Hay algunas reglas --replicate-do-db o --replicate-ignore-db ?
        • Sí: Puede testearlas como --binlog-do-db y --binlog-ignore-db . ¿Cuál es el resultado del test?
          • Ignora el comando: Lo ignora y sale.
          • Ejecuta el comando: No lo ejecuta inmediatamente; difiere la decisión; continúa con el siguiente paso.
        • No: Continúa con el siguiente paso.
      2. ¿Estamos ejecutando ahora una función o procedimiento almacenado?
        • Sí: Ejecuta la consulta y sale.
        • No: Continúa con el siguiente paso.
      3. ¿Hay alguna regla --replicate-*-table ?
        • No: Continúa con el siguiente paso.
        • Sí: Continúa con el siguiente paso. Sólo las tablas que van a ser actualizadas se comparan con las reglas (INSERT INTO sales SELECT * FROM prices: sólo sales se compara con las reglas). Si varias tablas van a actualizarse (comando de múltiples tablas), la primera tabla coincidente (coincidencia “do” o “ignore”) gana. Esto es, la primera tabla se compara con las reglas. A continuación, si no se puede tomar ninguna decisión, la segunda tabla se compara con las reglas, y así.
      4. ¿Hay algunas tablas --replicate-do-table ?
        • Sí: ¿Coincide la tabla con alguna de ellas?
          • Sí: Ejecuta la consulta y sale.
          • No: Sigue con el siguiente paso.
        • No: Sigue con el siguiente paso.
      5. ¿Hay alguna regla --replicate-ignore-table?
        • Sí: ¿Coincide la tabla con alguna de ellas?
          • Sí: Ignora la consulta y sale.
          • No: Continúa con el siguiente paso.
        • No: Continúa con el siguiente paso.
      6. ¿Hay alguna regla --replicate-wild-do-table?
        • Sí: ¿Coincide la tabla con alguna de ellas?
          • Sí: Ejecuta la consulta y sale.
          • No: Continúa con el siguiente paso.
        • No: Continúa con el siguiente paso.
      7. ¿Hay alguna regla --replicate-wild-ignore-table?
        • Sí: ¿Coincide la tabla con alguna de ellas?
          • Sí: Ignora la consulta y sale.
          • No: Continúa con el siguiente paso.
        • No: Continúa con el siguiente paso.
      8. No coincide ninguna regla --replicate-*-table . ¿Hay alguna otra tabla para comprobar con las reglas?
        • Sí: Bucle.
        • No: Hemos testeados todas las tablas a actualizar y no podemos encontrar ninguna coincidencia con ninguna regla. ¿Hay alguna regla --replicate-do-table o --replicate-wild-do-table ?
          • Sí: Ignora la consulta y sale.
          • No: Ejecuta la consulta y sale.
Publicado por en

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)