backup online serveru

Daniel.Brnak na gmail.com Daniel.Brnak na gmail.com
Čtvrtek Březen 15 18:18:40 CET 2007


Ahoj,

> nema mysql nejakou vychytavku, kdy by se zapnulo neco journal, a
> probihajici zapisy a nove zapisy by se presmerovaly do nejakeho logu a
> nezapisovaly se do databaze dokud by se zase neodemkla? neco na zpusob datoveho
> journalu v ext3, jestli to dobre chapu. pro probihajici transakcni zapisy by
> to nesynchronizovalo celou transakci.
> stejne neco na ten zpusob musi v mysql existovat, aby mohli garantovat
> konzistenci transakcnich operaci, ne?
> nebo jsem totalne mimo misu?

To "neco" sa vola transakcia ;-) a tvoja idea so snapshotmi disku je
spravna.
Spravny postup je:

1. precitat si tretiu sekciu http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html
2. FLUSH TABLES WITH READ LOCK;
3. urobit snapshot disku
4. UNLOCK TABLES;

Na horeuvedenej stranke je vysvetlene, ze i ked interne nebude InnoDB
snapshot konzistentny, nevadi to:

"Internally (inside the InnoDB storage engine) the snapshot won't be
consistent (because the InnoDB caches are not flushed), but this is
not a cause for concern, because InnoDB resolves this at startup and
delivers a consistent result. This means that InnoDB can perform crash
recovery when started on this snapshot, without corruption."

Tak ahoj
Daniel

PS: taka mala drobnost pri tvorbe automatickeho skriptu. Ak posles
prikaz FLUSH TABLES z konzoly pomocou prikazu mysql, tak po skonceni
tohto prikazu sa zamky *uvolnia* a snapshot sa vykona z read-write
databazy :-) Riesenim je poslat serveru naraz vsetky kroky (2., 3.,
4.) a pre tvorbu snapshotu pouzit mysql prikaz "system"




Další informace o konferenci Linux