🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.os.linux.programacion
Article #6483

Re: MySQL

#6483
From: Jesús M. NAVARRO
Date: Wed, 11 Jun 2003 00:00
50 lines
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-mail
References: <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