Práctica 4 base de datos

De Wikiversidad
Ir a la navegación Ir a la búsqueda

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

Actividad 1[editar]

  • Replicación via BINLOG

Empezamos configurando el "Master":


Rep1


Activamos el log_bin.


Rep2


Activamos los siguientes parametros y paramos el servicio mysql.


Rep3


Rep4


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


Rep5


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

Realizamos una instrucción DML:


Rep6


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


Rep7


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


Rep8


Rep9


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

Primero creamos un backup de la máquina.


Rep10


Modificamos el archivo master_backup.sql


Rep11


Ahora configuramos el "Slave":

Paramos el servicio mysql.


Rep12


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.


Rep13


Y encendemos otra vez el servicio mysql.


Rep14


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


Rep15


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


Rep16


Actividad 2[editar]

  • 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)


Rep17


Parametros 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 leido 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.


Rep18


Configuración del Slave1:


Rep19


Configuración del Slave2:


Rep20


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


Rep21


Rep22


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


Rep23


Rep24


Rep25


Actividad 3[editar]

  • 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, deberiamos 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.


rep31


rep33


Y comprovamos que se haya instalado correctamente:


rep32


rep34


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


rep35


Y luego en el Master pasivo:


rep37


Y comprovamos que funcione.


rep36


rep38

Actividad 4[editar]

  • Explica el funcionamiento de estas herramientas:
  • pt-table-checksum:

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


rep26


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):


rep26


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[editar]

  • 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?


Rep22


  • 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";


rep36