Práctica 4 base de datos

Esta es la cuarta práctica de la UF3 de base de datos del grupo de Marc Grau y Marc Vaquero.

Actividad 1

Replicación via BINLOG

Empezamos configurando el "Master":

Activamos el log_bin.

Activamos los siguientes parámetros y paramos el servicio mysql.

Borramos todos los ficheros de log, encendemos el servicio y comprovamos los nuevos ficheros de log que ha creado:

Ha creado 2 logs nuevos: mgraurep.000001 i mgraurep.index.

Realizamos una instrucción DML:

Miramos el contenido de mgraurep.000001 con la comanda: mysqlbinlog mgraurep.000001

Seguidamente hacemos un flush de los logs y una comprovación utilizando el master.

Finalmente configuramos el "Master" para crear el "Slave":

Primero creamos un backup de la máquina.

Modificamos el archivo master_backup.sql

Ahora configuramos el "Slave":

Paramos el servicio mysql.

Modificamos el fichero mysqld.conf. Vemos que el log-bin ya esta comentado y en las nuevas versiones el binlog_format no aparece configurado por defecto, en caso contrario habría que comentarlos. También ponemos un valor distinto al del "Master" en el server-id.

Y encendemos otra vez el servicio mysql.

Seguidamente volvemos al "Master" y añadimos el usuario slave con la IP de la máquina "Slave":

Y le damos permiso de "REPLICATION SLAVE" al usuario que acabamos de crear.

Actividad 2

Replicación via GTID

Primero hacemos el mysqldump y lo pasamos a los "Slave".

Después configuramos el "Master": (Recordar que hay que reiniciar el servicio mysql después de cada cambio)

Parámetros importantes:

enforce-gtid-consistency=TRUE => Solo permite la ejecución de afirmaciones transaccionalmente seguras.

master-info-repository=TABLE => Determina que el registro de credenciales de inicio de sesión y las coordenadas que indican hasta que punto ha leído el "Slave" del registro binario del "Master" y lo escribe en forma de tabla o fichero.

relay-log-info-repository=TABLE => Determina la información de registro de estado sobre el punto de ejecución dentro del registro del "Slave" y lo escribe en forma de tabla o fichero.

Configuración del Slave1:

Configuración del Slave2:

Hacemos el "CHANGE MASTER TO" en el Slave1 y Slave2.

Una vez nos hemos asegurado de que funciona, mostramos el contenido del binary log.

Actividad 3

Entorno con replicación semisíncrona con máster pasivo.

Para este ejercicio utilizaremos las mismas máquinas que en el apartado anterior y modificaremos un "Slave" para que haga de Master pasivo.

En el caso que no hubiesemos utilizado las máquinas ya configuradas, deberíamos volver a configurar el "Master", crear el usuario Slave en mysql, configurar los "Slave" y volver a hacer el CHANGE MASTER TO.

Primero de todo instalamos el plugin "rpl_semi_sync_master" en el Master activo y el "rpl_semi_sync_slave" en el master pasivo.

Y comprovamos que se haya instalado correctamente:

Seguidamente, activaremos la replicación semisíncrona. Primero en el Master activo:

Y luego en el Master pasivo:

Y comprovamos que funcione.

Actividad 4

Explica el funcionamiento de estas herramientas:

pt-table-checksum:

Instalamos el paquete "percona-toolkit" donde se encuentran estas herramientas:

Esta herramienta sirve para encontrar las diferencias de datos de una manera eficiente entre el "Master" y los "Slave". "pt-table-checksum" se conecta al servidor que especifique y busca bases de datos y tablas que coincidan con los filtros que especifique (si corresponden).

Para esto tendremos que dar permisos al usuario mysql:

GRANT REPLICATION SLAVE,PROCESS,SUPER, SELECT ON *.* TO `checksum_user`@'%' IDENTIFIED BY 'checksum_password';

GRANT ALL PRIVILEGES ON percona.* TO `checksum_user`@'%';

Y usamos la herramienta:

pt-table-checksum --replicate=percona.checksums --ignore-databases mysql h=localhost,u=checksum_user,p=checksum_password

pt-table-sync:

Instalamos el paquete "percona-toolkit" (el mismo que en el apartado anterior):

Esta herramienta sincroniza los datos entre tablas de un "Master" y un "Slave", ya que esta herramienta cambia los datos es recomendable hacer una copia de seguridad de los datos. Al sincronizar un "Slave" con "--sync-to-master" o "--replicate" siempre realizará los cambios en el "Master", ya que en general esta es la única forma segura de sincronizas una réplica con el maestro.

Suponemos que antes de usar esta comanda hemos hecho "pt-table-checksum" y por lo tanto el usuario mysql ya tiene los permisos necesarios (los que le damos en el apartado anterior).

Y usamos la comanda:

pt-table-sync --print --replicate=percona.checksums --sync-to-master h=localhost,u=checksum_user,p=checksum_password

Preguntas

Si iniciamos una transacción en el "Master" donde hay una serie de operaciones DML, estas se guardan en el binlog?

Se guardará después de hacer el "COMMIT" ya que en el binary log se guardan todas las transacciones.

Comprueba utilizando "SHOW SLAVE STATUS", que valores te da?

Que significado tiene la opción "MASTER_CONNECT_RETRY" en la comanda "CHANGE MASTER TO"?

Determina la cantidad de veces que podrá intentar conectarse.

Que hace la comanda "RESET MASTER" en el caso de no utilizar GTID y utilizarlo?

Elimina todos los logs anteriores y crea uno nuevo .000001.

Mira alguna de las tablas (SHOW TABLES LIKE 'repl%') del "PERFORMANCE_SCHEMA";