https://dev.mysql.com/doc/mysq...backup/8.0/en/mysqlbackup.html
https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/

nema jednostavnije resenje od mysqlbackup
full: https://dev.mysql.com/doc/mysq...p/8.0/en/mysqlbackup.full.html
differential/incremental: https://dev.mysql.com/doc/mysq...n/mysqlbackup.incremental.html

jeste, mysqlbackup je deo enterprise alata, ali ako nisi enterprise korisnik, koji ce ti komplikovan i brz i ... bekap :D ...

ali ako bas neces da platis subscription i oces dzaba onda
https://www.percona.com/softwa...ql-database/percona-xtrabackup

Al si brz :)

nisam enterprise korisnik, i treba mi nesto dzaba :D

Za sada mi zanimljivo deluje ovaj percona alat.

Moze da stavi i na zfs data set, uradi snapshot, bekapuje, uradi sledeci snapshot, pa uradi inkrementalni bekap i tako dalje. Mozda ovo moze i da ne obara bazu ;)

Koliko je velika baza?

moze bilo koji lvm ili bilo sta sto ume da napravi snapshot ali cemu kad
postoje alati koji to rade kako treba

btw pretpostavljam da znas da sve oracle aplikacije (ukljucujuci mysql
enterprise server, mysql enterprise monitor, mysql enterprise backup...)
mozes da skines sa edelivery bez ikakvih limita za potrebe probanja i
testiranja i ucenja, oracle ne koristi nikakve "zastite" osim mocnih
advokata koji te na1234 ako te uvate da koristis u produkciji bez licence :)

To su oni advokati sto su na kraju odrali Google.... Da, "osim" advokata. :D

Sve zavisi od velicine baze i koliko je komercijalan poduhvat, ali Percona toolkit je za sasvim dobar, posebno ako ti je Oracle MySQL skup. Ako baza nije velika i dump moze da bude solidno resenje.... (sa dovoljno malom bazom sve je solidno resenje ;) ).

to sam nedavno saznao, ali nisam još koristio, jer za sada u okruženju u kojem se krećem ne verujem da će se koristiti nešto što nije free :).

Šte se tiče zfs to bi restore bio samo u tom momentu kada je snapshot urađen. Verovatno bih mogao i Veeam agent koji je free da iskoristim za sličnu stvar, ali time se gubi mogućnost restore u tačno nekom određenom trenutku između dva snapshota.

Dr.Sima, nemam za sada neku određenu bazu, više me interesovao način na koji se to pravilno radi. Do sada sam običan mysqldump radio svaki dan, jer je to bilo pedesetak malih baza od kojekakvih WP i sličnih sajtova, a nije bilo potrebe za više od jednog backup-a dnevno, pa nije ni bilo problema sa prostorom.

Pa da, ali zar to nije isto kao kad radis sa mysqldump?
Snimanje bekapa je briz. snapshot je trenutan a bekapujes samo razliku izmedju dva snapshota.
To mozes da snimas bekap po ceo dan zato sto su te razlike male.

Da, ali binlog mu je mnogo bolja opcija, jer moze da radi point-in-time. Takodje, jeste InnoDB atomic i sve, ali ako hoce konzistentan backup, i nece da radi repair svaki put, on mora da uradi:

- Lock
- Flush tables
- Snapshot
- Unlock

Nije atomicno bas... :) OK, traje par sekundi, ali opet. Innobacupex ce da uradi isto rsync, pa onda log replay offline - bez da radi to na zivoj bazi, da flushne sve otvoreno. Ako je baza velika uvek ima dosta toga u memoriji i nije bas uvek zgodno flushnuti sve.

Dump je samo prost. Ako je baza jako mala, ond moze dump. Da, onda moze i snapshot, ali sto bi radio snapshot kad ima mali i brz dump....

Pa tako nekako i funkcionise, ko nece (ne moze) da se ispruzi za enterprise, gura repliku + dump&binlogs.
Mnogo lepse okruzenje je galera cluster + mysqlbackup.

Inkrementalni bekapi nemaju mnogo smisla sa malim bazama.
Na "gigabajtima" je ok opcija particionisanja velikih tabela po npr. datumu i inkrementalnog bekapovanja samo "aktivnih" particija.

@Branimir

Jasno mi je šta govoriš, ali ja otvorih temu da vidim šta postoji bolje od mysqldump :)

Kod ovog sa bin logovima koliko sam shvatio prednost nije samo u inkrementu i čuvanju prostora, nego što restore može da se odradi u nekom određenom kritičnom momentu.
Pored toga koliko videh iz samih tih bin logova mogu da se izbace problematični upiti, pre nego što se uradi restore.
Sa treće strane opet što se tiče same sigurnosti, ukoliko restore pođe po zlu, verujem da je lakše "popraviti" te dumpove i logove i izvući ono što je korisno, nego iz tih snapshotova.

Ali kao što rekoh, ovo je možda samo moje naivno razmišljanje, zato otvorih temu :).

Znas kako restore ne moze na zfs-u da podje po zlu. Imas kopiju particije nad kojom mozes da radis scrub na nedeljnom nivou i cesce. I samo opalis send u fajl pa onda recv i kreira ti tu particiju gde hoces.
A odatle mozes da dignes bazu bez problema. Ako ti treba vreme sacuvas snapshotove i ne brises ih te ih nazoves po vremenu kada je snimano. Stvar je da snapshotove cuvas i nad originalom i ako
ti nesto podje po zlu iz snapshota vratiti fajl ili uraditi rollback je breeze.

E sad faulty hardware uvek moze da zezne stvar zato treba ECC memorija za zfs.

Joj ne...

Prvo, imas percona backup. Koji radi skoro isto kao enterprise.

Drugo, replika ti sve jedno treba. Zapravo, treba ti mozda i vise nego backup. Ako imas bazu koju koristis backup je samo to - backup, ne failover. Ne HA.

Galera je sve samo ne lepse resenje. Ima smisla nekad, ali reci da je "lepse okruzenje", nije. Galera ima brdo svojih problema koje vuce.... Sinhrona replikacija, delay.... nije to bas za sve situacije.


Gigabajti nisu problem. Bazu od 2-3GB backupujes za par minuta, no frks. Problem su stotine GB i terabajti :)

Dakle XtraBackup dakle ne radi kao mysqldump, nego kopira fajlove direktno iz /var/lib/mysql/, što je pretpostavljam daleko brže kod velikih baza nego mysqldump koji je znao da mi potraje čak i kod baza od 2-3GB.

Nego ne mogu da pronađem u dokumentaciji... kako se brišu stari backupovi napravljeni sa innobackupex? Dovoljno obrisati kompletan folder sa svim fajlovima?
Buni me, jer sam okinuo full backup sa komandom

pa planirao da ispišem skriptu i obrisao taj ceo folder sa backupom, i kad okinem ponovo full backup sa istom komandom dobijem


Ne sećam se kako je bilo kod prvog puta, ali pretpostavljam da je lsn išao od 0 do 2238182?

Dok u xtrabackup_checkpoints piše da je from 0


Isto i u xtrabackup_info