Administracin de BDs

Replicacin

Replicacin

Consiste en configurar uno o varios servidores como esclavos o rplicas - de otro servidor Base para construir aplicaciones extensas y de alto rendimiento Problema a resolver: mantener los datos de los servidores sincronizados Admite diferentes topologas Muchos esclavos pueden conectarse a un maestro un esclavo puede, a su vez, actuar como maestro Se puede replicar: todo el servidor determinadas bases de datos slo algunas tablas

Problemas resueltos por la replicacin

Distribucin de datos

Replicacin no es de banda ancha intensiva Puede funcionar con una conexin intermitente til para mantener una copia de los datos en una ubicacin geogrficamente distante La replicacin permite distribuir peticiones de datos entre varios servidores Un servidor replicado no es una copia de seguridad La copia se carga sobre la rplica, no sobre el servidor original Los esclavos ayudan a reducir el tiempo de cada del servidor principal Configuramos un servidor esclavo con la nueva versin de MySQL, y la utilizamos para ver que las aplicaciones siguen funcionando correctamente

Balanceo de carga

Copias de seguridad

Alta disponibilidad y failover

Prueba de actualizaciones de MySQL

Funcionamiento en MySQL

El maestro registra todos sus cambios como eventos del registro binario El esclavo copia los eventos del registro binario a su registro retardado El esclavo repite todos los eventos del registro retardado sobre sus propios datos

El registro binario

El registro binario registra todas las operaciones del servidor, con independencia de los motores de almacenamiento Est formado por una secuencia de eventos
# at 277 #071030 10:47:21 server id 10 end_log_pos 369 Query thread_id=13 exec_time=0 error_code=0 SET TIMESTAMP=1193756641/*!*/; insert into test(a) values(2)/*!*/;

Incluye:

La fecha y hora del evento (un timestamp) Id del servidor de origen (se usa para evitar bucles infinitos en la replicacin) Byte de desplazamiento del evento siguiente (end_log_pos) Id del thread que ejecut el evento en el servidor de origen Tipo de evento (Query, en el ejemplo)

Tipos de replicacin

MySQL admite dos tipos de replicacin: Basada en sentencias

La nica replicacin disponible hasta MySQL 5.0 Se registra la peticin que cambia los datos en el maestro (la instruccin) Muy sencilla de implementar Representacin compacta Problema: hay instrucciones que no se pueden replicar fcilmente (CURRENT_DATE, CURRENT_USER, procedimientos almacenados, funciones definidas por el usuario) Otro problema: serializacin (por culpa de la concurrencia) Disponible desde versin 5.0 Se registran los cambios en los datos Facilita la replicacin Desventaja: puede ocupar mucho ms espacio

Basada en filas

MySQL escoge, de forma dinmica, la forma ms conveniente de registrar un evento en el registro binario

Configuracin de la replicacin

Pasos a seguir:

Configurar cuentas de replicacin en cada servidor Configurar maestro y esclavo Instruir al esclavo para conectarse al maestro

Configuracin de cuentas

MySQL incluye privilegios especiales para ejecutar los procesos de replicacin

Replication client: permite preguntar dnde estn los maestros y los esclavos (ya no se usa!) Replication slave: necesario para acceder al registro binario del maestro

El thread E/S del esclavo hace una conexin TCP/IP al maestro para leer el registro binario. Por lo tanto, necesita una cuenta de usuario en el maestro con los permisos apropiados
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* -> TO 'repluser'@'192.168.1.% IDENTIFIED BY replpassword

Se crea el mismo usuario en el maestro y el esclavo por si en algn momento fuese necesario intercambiar los papeles Limitamos el uso de la cuenta a la red local, porque la cuenta de replicacin es delicada

Configuracin del maestro y el esclavo

En el maestro, necesitamos activar el registro binario, y asignarle una id al servidor

Aadir en my.cnf:
log_bin = mysql-bin server_id = 10

Como id del servidor debemos evitar usar el valor 1, porque es el valor predeterminado (posibles conflictos)

Reiniciar el servidor Comprobar que el registro funciona

mysql> SHOW MASTER STATUS +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 98 | | | +------------------+----------+--------------+------------------+

posicin del ltimo evento en el registro binario del maestro

Configuracin del maestro y el esclavo

En el esclavo, realizamos una configuracin similar

Aadir en my.cnf:
log_bin = mysql-bin server_id = 2 relay_log = mysql-relay-bin log_slave_updates = 1 read_only = 1

Usamos como id del servidor uno distinto al del maestro Damos nombre tambin al registro retardado (relay_log) Y activamos igualmente el registro binario del esclavo (log_bin) Al activar log_slave_updates, hacemos que el esclavo registre sus cambios en su propio registro binario Esta opcin permite que el esclavo sea, a su vez, maestro de otros esclavos Los cambios en el maestro se propagan a los esclavos del esclavo Por eso es importante que todos los servidores tengan un id diferente (evitar bucles infinitos)

Reiniciar el servidor

Iniciar el esclavo

Hay que decirle al esclavo cmo conectarse al maestro y empezar a replicar los eventos de su registro binario Es posible hacerlo desde el interprete de comandos de MySQL en vez de desde my.cnf Desde lnea de comandos tambin podremos apuntar a otro maestro en el futuro sin necesidad de reiniciar el servidor
mysql> -> -> -> -> CHANGE MASTER TO MASTER_HOST=server1 MASTER_USER=repluser MASTER_PASSWORD=replpassword MASTER_LOG_FILE=mysql-bin.000001, MASTER_LOG_POS=0;

MASTER_LOG_POS se configura a 0 para que se empiece a replicar desde el principio del registro binario del maestro

Podemos usar SHOW SLAVE STATUS para comprobar que los ajustes son correctos
mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repluser Master_Port: 3306 Connect_Retry: 60 posicin del primer Master_Log_File: mysql-bin.000001 evento en el registro Read_Master_Log_Pos: 4 binario del maestro Relay_Log_File: mysql-relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Filtros Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: ... Seconds_Behind_Master: NULL

Lo timo que hay que hacer: iniciar la replicacin en el esclavo

mysql> START SLAVE;

mysql> SHOW SLAVE STATUS\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: server1 Master_User: repluser Master_Port: 3306 posicin del siguiente Connect_Retry: 60 evento a leer en el Master_Log_File: mysql-bin.000001 maestro Read_Master_Log_Pos: 164 Relay_Log_File: mysql-relay-bin.000001 siguiente evento en el Relay_Log_Pos: 164 registro retardado a Relay_Master_Log_File: mysql-bin.000001 aplicar sobre el Slave_IO_Running: Yes servidor Slave_SQL_Running: Yes Replicate_Do_DB: los threads ya estn Replicate_Ignore_DB: trabajando Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: estamos ... sincronizados con el Seconds_Behind_Master: 0

maestro!

Archivos de replicacin

Los archivos que contienen la informacin de la replicacin son:

mysql-bin.index: mantiene la lista de todos los archicos con el registro binario mysql-relay-bin.index: lo mismo, para el registro retardado master.info: la informacin que necesita el servidor esclavo para poder conectarse al maestro relay-log.info: contiene las coordenadas del registro retardado (la posicin del registro retardado desde la que hay que continuar la replicacin)

Filtros

Es posible replicar slo parte de los eventos de un servidor, utilizando diferentes tipos de filtros

Filtros sobre el registro binario del maestro Filtros sobre el registro retardado

binlog_do_db binlog_ignore_db replicate_do_db replicate_do_table replicate_ignore_db replicate_ignore_table replicate_rewrite_db replicate_wild_do_table replicate_wild_ignore_table

Se aplican mientras se va leyendo del registro binario del maestro

Se aplican mientras se va leyendo del registro retardado del esclavo

Usos tpicos: detener replicacin de instrucciones GRANT y REVOKE (propagacin de privilegios)

Para hacerlo:
replicate_ignore_table=mysql.columns_priv replicate_ignore_table=mysql.db replicate_ignore_table=mysql.host replicate_ignore_table=mysql.procs_priv replicate_ignore_table=mysql.tables_priv replicate_ignore_table=mysql.user

Alternativa: proteger toda la base de datos mysql

replicate_wild_ignore_table=mysql.%

Esta opcin impide replicar las instrucciones GRANT, pero tambin podra evitar otros eventos importantes.

Las opciones binlog_do_db y binlog_ignore_db no funcionan como sera de esperar

binlog_ignore_db=sakila mysql> USE test; mysql> DELETE FROM sakila.film; mysql> USE sakila; mysql> DELETE FROM film;

No filtra esta instruccin porque el filtro se aplica sobre la base de datos por defecto (test)

Esta s se filtra

Topologas

La replicacin admite diferentes topologas, con diferentes aplicaciones Reglas a seguir:

Cada esclavo slo puede tener un maestro Cada esclavo slo puede tener una id de servidor Un maestro puede tener muchos esclavos Un esclavo puede propagar cambios desde su maestro, y tambin ser el maestro de otros esclavos

Un maestro, mltiples esclavos

La topologa ms sencilla til si tenemos varias escrituras y muchas lecturas Cualquier nmero de esclavos, hasta sobrecargar al maestro o el ancho de banda Utilidades:

Usar cada esclavo para diferentes funciones (con ndices diferentes, motores diferentes...) Un esclavo en centro remoto para recuperacin ante desastre Retrasar en el tiempo un esclavo para facilitar recuperacin Utilizar alguno de los esclavos para copia de seguridad, de pruebas o de desarrollo

Maestro-maestro en modo activo-activo

Cada maestro es esclavo del otro Posible uso: oficinas separadas geogrficamente, donde cada oficina necesita su copia local de los datos Problema: cambios conflictivos

Actualizacin simultnea de la misma fila en ambos servidores Inserciones simultneas con columnas AUTO_INCREMENT Y si la replicacin se detiene por un tiempo? Cmo reenganchamos despus?

Slo se recomienda si tenemos datos con buenas particiones y buen reparto de privilegios

Maestro-maestro en modo activo-pasivo

Uno de los servidores es un servidor pasivo de slo lectura Permite intercambiar los papeles de forma muy sencilla: las configuraciones son simtricas Mantenimiento, optimizacin de tablas, actualizaciones del sistema operativo... no implican inactividad Ejemplo: ALTER TABLE

Bloquea toda la tabla, incluyendo lecturas y escrituras sobre la misma Para no ralentizar:

Detenemos hilos esclavos en el servidor activo Hacemos cambio en el servidor pasivo Cambiamos los papeles Reiniciamos el hilo esclavo en el antiguo servidor activo (ahora de slo lectura)

Anillo

Tres o ms maestros Cada servidor es un esclavo del servidor que est antes en el anillo, y maestro del servidor que est despus Configuracin simtrica, failover fcil. Pero son frgiles.

Depende enormemente de que todos los nodos funcionen correctamente Difcil que estn todos sincronizados a la vez: detener algn nodo es complicado Si eliminamos un nodo sin tener cuidado, sus eventos pueden propagarse de forma infinita por el anillo.

El nico nodo que filtra un evento es el que lo ha generado!

Maestro, maestro de distribucin, esclavos

Para no sobrecargar demasiado al maestro El maestro, un esclavo, que usa motor blackhole: acta como maestro de distribucin

Motor blackhole slo graba en registro binario, pero no mantiene tablas ni datos De ese modo, las replicaciones en el maestro de distribucin son muy baratas

El maestro de distribucin lee y sirve los registros binarios desde el maestro a los esclavos Regla general:

si maestro funciona a pleno rendimiento, 10 esclavos Si hay poca actividad escrita, o se replica slo una fraccin de las tablas: pueden ser ms

rbol o pirmide

Si hay muchos esclavos, puede ser mas rentable un diseo en pirmide Eso alivia la carga del maestro y la redistribuye por los diferentes esclavos Desventaja: fallos en niveles intermedios afectan a un gran nmero de servidores Adems, cuantos ms niveles intermedios, ms difcil y complicado es manejar los fallos

Problemas tpicos

Medir desfase de los esclavos (seconds_behind_master no siempre es fiable) Determinar consistencia de los esclavos (los problemas ocurren) Resincronizacin de un esclavo desde el maestro Intercambiar maestros

Cmo se determina la posicin inicial en el nuevo maestro? Si mysqlbinlog deja de leer, toca usar edicin hexadecimal o similares para tratar de recomponer los registros

Registros binarios corruptos

...y miles de problemas ms!!!!!