"Si no somos capaces de pensar por nosotros mismos..."

"“Si no somos capaces de pensar por nosotros mismos, si somos renuentes a cuestionar la autoridad, entonces somos sólo marionetas en las manos de quienes están en el poder. Pero si los ciudadanos están educados y son capaces de formarse su propia opinión, entonces los que están en el poder trabajarán para nosotros."

Carl Sagan

Tagged citas carlsagan

¿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

Tagged mysql replicacion mysqlbinlog dba
​