zalohy databazi & snapshoty
Radim Kolar
kolar.radim at gmail.com
Thu Nov 15 18:28:54 CET 2007
> urovni filesystemu - nikoliv na urivnich vyssich. Takova bezici databaze
> bude po takovem prekopirovanim ve stejnem stavu jako by byla kdybych
> pocitac v nahodnou chvili vypnul a pote zapnul.
pgsql a oracle jsou v klidu nebot maji 1. rollforward recovery, 2.
bugfree partial write recovery. U tech pokud maji data jen na jednom
fs lze s klidem pouzivat fs snapshoty (zfs, ffs), dokonce je to i u
prikladu pouziti snapshotu na zfs.
Pokud jsou data db pres vice FS tak nutno predem oznamit databazi
online backup a pak zazalohovat data libovolnym zalohovacim nastrojem
(tar, dump). Firebird2 ma svuj online backup program, ktery pracuje
trochu jinak nez oracle/pgsql. V manualech k db je tato metoda
podrobne popsana, jedna se o nejpouzivanejsi system zaloh velkych db.
mysql s myisam nema zadny recovery mechanismus, mysql s innodb ma jen
rollforward recovery, partial write recovery v mysql terminologii AKA
innodb double write ma v mysql4.1 a 5.0 bug, crashne to, pokud
transakce soucasne zvetsila db soubor a pri recovery je mensi nebot se
zmena velikosti nestacila do fs zapsat a zaznam ukazuje na
neexistujici blok. mysql 5.1 jsem netestoval. Pokud se narazi na
tenhle bug, mysql nenabehne.
U fs snapshotu by to ale mohlo i s mysql/innodb pracovat korektne,
protoze tam se mu velikost souboru diky snapshotu zmensovat nebude.
Podrobne jsem to ale netestoval. Ja osobne pouzivam snapshoty s
mysql/myisam nebot nemam v mysql zadna dulezita data. Naopak nizsi
spolehlivost tohoto reseni z nekolika duvodu vitam a tak mi nevadi, ze
pri kazde odbnove dat ze snapshotu se nejaka data ponici.
online backups ala Oracle v mysql jeste dlouho nebudou:
http://forge.mysql.com/wiki/OnlineBackup
takze pro spolehlive zalohy zbyva mysqldump --single-transaction
pripadne --lock-tables
zalohovani BerkeleyDB pomoci snapshotu je obecne problem. Pokud nemaji
vytvoren transakcni log, tak vetsinou dojde k nenavratnemu poskozeni
dat pokud byl soubor v dobe zalohy otevren pro zapis pokud aplikace
nedela po kazdem zapisu sync db (coz prakticka zadna nedela). Vetsinou
to nevadi, aplikace pouzivajici tuhle db s jeji nizsi spolehlivosti
pocitaji a nepouzivaji ji pro dulezita data, pouzivaji ji povetsinou
jako cache.
More information about the Users-l
mailing list