Article View: es.comp.os.linux.programacion
Article #6483Re: MySQL
From: Jesús M. NAVARRO
Date: Wed, 11 Jun 2003 00:00
Date: Wed, 11 Jun 2003 00:00
50 lines
3479 bytes
3479 bytes
Hola, Alvaro: Alvaro G. Vicario escribi� en es.comp.os.linux.programacion: > "Jes�s M. NAVARRO" <jesus_navarro@undominio.net> escribi� en el mensaje > news:7e7hr-qgl.ln1@mithrandir.intranet... >> Espero que esa no sea una base de datos de producci�n, porque lo que > cuentas >> quiere decir que en ese plazo no se han hecho copias de seguridad (ya que >> mysqldump invoca impl�citamente un flush... adem�s, es conveniente lanzar >> el flush tambi�n antes de empezar la copia). > > 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... El problema est� en la transaccionalidad de las operaciones: copiando simplemente el contenido de los directorios, nadie te garantiza que las bases de datos est�n en una situaci�n consolidada. Ejemplo sencillo: una operaci�n de tu base de datos inserta una orden de pedido en la tabla de pedidos *y* elimina la entrada correspondiente en la tabla de stocks. La copia de la tabla de pedidos ocurre despu�s de la entrada en su tabla, pero la copia de la de stocks ocurre antes de la actualizaci�n correspondiente. Resultado: recuperar esa base de datos en esa situaci�n es peor que no recuperar nada. Si no puedes recuperar nada al menos *sabes* que tienes un problema; si puedes recuperar los datos bien en apariencia, ni sabes lo que est� pasando. Por otra parte, se trata de ficheros abiertos por una aplicaci�n. Como con cualquier fichero en estas circunstancias, su contenido es indefinible, al menos en potencia. Te pasar� (a m� me ha pasado) que una base de datos empiece a dar problemas (un problema con la integridad de los �ndices, por ejemplo): recuperar de una copia de sistema, seguramente s�lo empeorar� las cosas donde un dump de la base de datos es m�s resistente. En general, con cualquier base de datos, hay que seguir el procedimiento de su gestor para obtener im�genes consistentes. Son estas im�genes las que se llevan al dispositivo de almacenamiento secuencial (as�, el resultado de un mysqldump bien calculado se deja en el disco duro y, puesto que esta copia ya est� "fr�a", la copia de seguridad de sistema se encargar� de moverla a la cinta). -- SALUD, Jes�s *** jesus_navarro@undominio.net ***
Technical Details
Message-ID:
<j28ir-el9.ln1@mithrandir.intranet>Path:
arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!syros.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!212.97.187.70!not-for-mailReferences:
<bc45pv$f2shf$1@ID-157797.news.dfncis.de> <7e7hr-qgl.ln1@mithrandir.intranet> <bc52n0$fdgfh$1@ID-157797.news.dfncis.de>Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII X-Google-Thread: f86c8,950b6fc3ccf51558 X-Google-Attributes: gidf86c8,public X-Google-ArrivalTime: 2003-06-10 17:12:34 PST Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!syros.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!212.97.187.70!not-for-mail From: Jesús M. NAVARRO <jesus_navarro@undominio.net> Newsgroups: es.comp.os.linux.programacion Subject: Re: MySQL Date: Wed, 11 Jun 2003 02:00:49 +0200 Lines: 50 Message-ID: <j28ir-el9.ln1@mithrandir.intranet> References: <bc45pv$f2shf$1@ID-157797.news.dfncis.de> <7e7hr-qgl.ln1@mithrandir.intranet> <bc52n0$fdgfh$1@ID-157797.news.dfncis.de> NNTP-Posting-Host: 212.97.187.70 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit X-Trace: fu-berlin.de 1055290353 16723151 212.97.187.70 (16 [173178]) X-Orig-Path: mithrandir.intranet!news User-Agent: KNode/0.7.2