🚀 go-pugleaf

Hola, �lvaro:

Alvaro G. Vicario escribi� en es.comp.os.linux.programacion:

> "Jes�s M. NAVARRO" <jesus_navarro@undominio.net> escribi� en el mensaje
> news:j28ir-el9.ln1@mithrandir.intranet...
>> > Se hace una copia diaria de los archivos de datos, lo cual incluye lo
> que
>> > cuelga de /var/lib/mysql/. �Es una mala pr�ctica? �Es m�s recomendable
>> > usar las propias utilidades de MySQL?
>>
>> Es poner dinamita cerca del fuego.  Si est� cerrada y no saltan chispas,
> no
>> pasa nada...
> 
> He estado mirando el comando mysqldump que me sugeriste y parece muy f�cil
> de usar. De lo que no estoy muy seguro es de qu� opciones debo poner
> exactamente para garantizar la integridad del backup. La �nica vez que se
> menciona "flush" en la ayuda es acerca de los logs (�?). �Estar� bien as�
> simplemente?:
> 

Las opciones m�nimas desde el punto de vista del administrador del
administrador del RDBM son '--flush-logs --opt'.  Esto quiere decir que no
se *garantiza* perfectamente la integridad de los contenidos de la base de
datos, pero que si hay fallos de integridad, el culpable es el programador
de las aplicaciones que acceden al RDBM (los desarrolladores de esa web de
e-comercio, por ejemplo).  Para garantizar la integridad contra
programadores incompetentes, habr�a que bloquear contra escritura todas las
tablas a las que se pueda estar accediendo en un momento dado (como m�nimo,
bloquear a la vez todas las tablas de una base de datos antes de volcarla);
si adem�s sabes o sospechas que pueden estar escribi�ndose datos a varias
bases de datos como parte de una operaci�n �nica, entonces deber�as
bloquear completas esas bases de datos antes de volcarlas; si sabes que ese
tipo de escrituras existen pero no sabes a qu� bases de datos, deber�a
bloquear contra escritura todas las bases de datos del gestor antes de
empezar.  Por supuesto que en este caso el rendimiento de la copia puede
ser lamentable y tendr�s que replantearte los objetivos a cumplir, porque
probablemente sea m�s adecuado volver a las opciones m�nima y que cada palo
aguante su vela.
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***