¿Porqué la replicación MySQL es mejor que usar el mysqlbinlog para hacer un recovery?


Habitualmente, si hay necesidad de hacer un recovery point-in-time (PITR) por alguna razón, el método "tradicional" suele ser "restaurar el servidor de un backup y luego usar el mysqlbinlog para aplicar los binary logs". Pero en realidad hay una mejor forma de hacer todo esto.

La mejor forma consiste en levantar una instancia de servidor sin datos, y cargar los binary logs en ella. Llamaremos a ésta "binlog server". Luego restauramos el backup en el servidor afectado y cuando esté listo, iniciamos una replicación como esclavo del "binlog server". Así podremos aplicar los binlogs pero a través de la replicación, no con la herramienta mysqlbinlog.

¿Porqué es mejor? Porque la replicación es una manera de aplicar binary logs a un servidor mucho más testeada. Además, la replicación es mucho más fácil y conveniente de usar. Puedes hacer cosas como START SLAVE UNTIL, skip de determinados estamentos, parar, iniciar, etc, sin tener que pensar en donde lo dejastes, etc.

La replicación tiene además la habilidad de reproducir correctamente muchos tipos de cambios, que mysqlbinlog no tiene o no hace del todo como debería. Por ejemplo:

insert into tbl(col) values(connection_id());

Esto se ejecuta bien a través de la replicación porque el thread SQL en el slave cambiará el ID de conexión para que sea igual al original. En cambio esto no funcionará con la herramienta mysqlbinlog.

Podeis ver el artículo original de Xaprb aquí.

Have a nice day ;-)

TooManySecrets