Backup your Database in Git
Célszerű a kisebb adatbázisok backupjának verziózása, ha spórolni akarunk a hellyel
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
vbence:
WebM alapú élő közvetítés
Hojtsy Gábor:
2004 - egy év a web körül I.
gerzson:
assert() - mesél a forráskód
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
Sajnos nem jött be. Egy éve
Lehet, hogy sokat kérek, de
Mármint egyetlen dump mennyi
Nem, annyi dump, ami most
Rendben, megpróbálom egy-két
Okés, köszi!
Erről mindenki mást ír,
Percona XtraBackup
Kell neked 1 évre visszamenőleg napi szintű backup?
Illetve ha törölsz gitből egy commitot akkor csökken a mérete a repónak? (sose néztem)
Percona XtraBackup -ot
Nem ismerem, de jó lenne adatbázis-agnosztikus megoldást találni.
Nem feltétlen, de szép lenne.
Megnézhetem ezt is, miben gondolkodsz?
átgondoltam: nem szóltam.
(azon a vonalon gondolkoztam hogy lehet törölni fájlt a git repóból komplett history-stúl (ezt csináltam már tök jól működik), rebase-el commitokat törölni elvileg (ezt sose csináltam), illetve azon a vonalon gondolkoztam hogy talán az utolsó 1 hónap history-ját valahogy ki lehetne menteni egy új repóba - bár az utóbbit nem tudom hogy lehet-e.)
Mondjuk egy olyan megoldás el tudok képzelni:
- a repóba hónap szinten mented a dump-ot. dump_2016_01.sql, és januárba erre mennek a dumpok, majd új hónapban új fájlt kezdesz a repóban.
- ilyenkor viszont már lehet törölni a 3 hónapnál régebbi fájlokat a repoból history-túl
(de nem tudom hogy csökken-e ilyenkor a repó tényleges mérete)
Hát szerintem valahogy
- 16-01-01
- 15-01-01
...
- monthly (16)
- 16-02-01
- 16-01-01
- daily (16-02)
- 16-02-14
- 16-02-13
- 16-02-12
...
- 16-02-01
- archive daily (16-01)
- 16-01-31
- 16-01-30
- 16-01-29
...
- 16-01-01
- archive daily (15-12)
- 15-12-31
- 15-12-30
- 15-12-29
...
- 15-12-01
...
- archive monthly (15)
- 15-12
- 15-11
- 15-10
...
- 15-01
- archive monthly (14)
- 14-12
- 14-11
- 14-10
...
- 14-01
...
Mondjuk csinálhatjuk azt, hogy visszamenőleg 3 hónap napi mentéseit, illetve 1 év havi mentéseit tartjuk meg. Így nagyjából állandó 3x31 + ~15 (napi) + 12 + ~6 (havi) + ~5 (éves) = 131+/-20 a commit szám. Talán ha még jobban átgondoljuk, hogy melyik ág melyikből ágazzon le, pl a napi a havi commit-ból, a havi az éves commit-ból, stb., akkor még további helyet lehet spórolni, mert nem duplázza az adatot. Én legalábbis valahogy így csinálnám, ha tényleg irreálisan sok helyet foglal egy branch-en verziózva az összes napi mentés.
Elméletileg zip-be tömörítve is el lehet érni ugyanazt, mint gittel, hogy csak az új adat foglaljon helyet. Szóval branch-ek helyett pl egymásba rakott zip fájlokkal is meg lehetne oldani a kérdést, viszont szerintem az sérülékenyebb lenne, mint gittel csinálni. Ha neadjisten valami hiba kerül a fájlba, akkor kevés az esély rá, hogy bármit vissza tudunk nyerni a backup-okból.
A zipek egymásba ágyazása
Szerintem ezt nehéz így
Kipróbáltam nem dumpon, hanem
- a.) A két mappa együtt nyersen 183MB.
- b.) A két mappa együtt tömörítve 80.4MB.
- c.) Az egyik mappa zip-je és a másik nyerse betömörítve 72.6MB.
Az megint egy érdekes kérdés, hogy vajon miért kisebb a c.), mint a b.) holott én egyforma eredményt vártam, te meg pont a fordítottját.
A nagy mappa egyedül 100MB. Nem hiszem, hogy a Git ezen sokat javítana, bár én sem tudom, hogy belül milyen varázslatokat használ, meg ez a teszt sem a legjobb, mert az alap kérdésben sok kicsi napi szintű változásról volt szó, nem egy nagyról. Most nekem nincs megfelelő teszt adatom, hogy jobban megnézzem, megvárom, hogy Ádám mire jut vele a dumpjaival.
Nem teljesen azonos azzal
Igaz igy nem lehet 3 honappal ezelotti szerdai allapotot reprezentalni, de a tapasztalat az hogy sose volt ra szukseg.
Reméljük soha nem is lesz.
Ezeknel a szolgaltatasoknal
Termeszetesen komolyabb megoldasokat is hasznalunk, de ott komolyabb is az igeny es azokert komolyabban is hajlandok csengetni az ugyfelek ;)
Sorrend
Tuti, hogy minden rekord új sorba kerül? Ha jól emlékszem defaultban egy ideje egyetlen sorba kerül egy tábla, ami diff-ben a teljes sor két verzióját jelenti.
A dump --skip-extended-insert
--skip-extended-insertflaggel készül, egy rekord egy sor. Ránézve két commit közt a diffre, a változások a szükségeseknek tűnnek, a sorrend rendben kell legyen.Tény, hogy hosszú a diff, mert sok rekord változik, de feltételezem, hogy a Git hatékonyan tárolja.
Időközben a repó elérte a 16
git gc --autohívást. Ma egy kézzel indítottgit gc --aggressive2 óra 42 percen át futott, a memóriahasználata 73 gigabájton tetőzött, és 117 megabájtra csökkentette a tároló méretét.Kifejtenéd? :-)
Melyik részt? :)
Hát miért ennyivel jobb az
Közben valószínűnek tűnik,
--autocsak egy küszöb fölött indítja el a folyamatot, és agc.autoilletvegc.autopacklimitalapértelmezett értéke ehhez a felhasználáshoz túl magasnak tűnik.Ezen túl azonban az
--aggressiveazért is ér el szignifikánsan jobb eredményt, mert az összes delta láncot eldobja, és újakat számol helyettük, ami azt jelenti, hogy bármely objektumhoz alapul vehet bármely más objektumot, olyat is, amelyik az objektum létrejöttekor még nem létezett.Ezek szerint az agresszív
Miben van neked 80GB RAM-od? :D
Ezek szerint az agresszív
Így van, de konfigurálható a láncok hossza, hogy hány objektumot vegyen figyelembe az optimális delta keresésekor, illetve a memóriahasználat (mint utólag kiderült), ezek nyilván befolyásolják, hogy mennyi időt vesz igénybe.
A limitet természetesen le lehet venni, és ez tűnik a célszerű megoldásnak. Ilyenkor inkrementális a folyamat, a meglévő deltákat érintetlen hagyja, így természetesen az elvi hatékonysága sosem lesz olyan, mint az agresszívnak, de a gyakorlatban elég jónak kell lennie, Linus legalábbis csak akkor javasolja az aggresszív módot, ha tudjuk, hogy a korábbi delták rosszak, mondjuk mert egy gyorsimport eredményei.
A 120 gigabájtos, 20 magos szerverben, amire azután vittem fel, hogy harmadszor fogyott el alatta a memória a kisebb gépeken :)
Brute force. :D
Mennyire szükséges mindez?
Néha hiányérzetem van, hogy egyáltalán nem foglalkozom az adatbázis és a verziókezelés témakörével. Még évekkel ezelőtt úgy döntöttem, hogy vagy akkor veszem elő ezt az egészet, ha kijön valami olyan tool, ami garantáltan problémamentes megoldást biztosít, vagy ha olyan szívásba ütközöm, ami annyira fájdalmas, hogy mégiscsak jó lesz egy félmegoldás.
Viszont érdekelne, hogy akik ezzel éles projekten foglalkoznak, náluk mi a motiváció? Nálunk az adatbázis módosítások 99%-a új oszlop, illetve új tábla hozzáadása. Legfeljebb a maradék 1% a nem használt oszlopok kukázása és az oszlopok típusának módosítása, ezek lennének a problémás adatbázis műveletek. Másik oldalról nem nagyon emlékszem, hogy mikor kellett éles környezetben visszaállni egy régebbi verzióra. Olyan meg még egyszer sem fordult elő, hogy pont akkor kellett visszaállni, amikor olyan adatbázis módosítás történt, amellyel a régi adatbázis felépítés nem működött volna. Igaz, kis cég, kevés fejlesztővel. Emiatt kérdezem, hogy másoknál ez valódi probléma?
Tartalom
Itt már tárgyaltunk erről:
elvileg annyi előnye van
Jólvan, lehet kicsit
Kizárt dolognak tartom, hogy
Tudsz ellene elvi érvet
Egy tetszőleges napi
Milyen jellegűek ezek adatok, ahol számít, hogy mondjuk tavaly március ötödikén mik kerültek be az adatbázisba? Miért nem elég a - mondjuk - fél évvel korábbi adatokról egy havi mentés?
Egy tetszőleges napi
Teszteléshez általában a legújabbat használom, de úgy emlékszem fordult elő, hogy valamivel régebbit vettem elő, és nem tűnt vészesnek.
Az adatok jellege nem indokolja jobban, mint bármely más adaté, de az előnyeit szerintem te is belátod annak, ha (adott felbontás mellett) tetszőleges állapota látható az adatbázisnak.
Szerintem az adatok
Ellenérv: adatbázist saját
Ezen felül: verziókezelő mihez kezd bináris adatokkal?
adatbázist saját eszközeivel
Az adatbázist a saját eszköze macerálja, a
mysqldump, csak a dumpok vannak egyszerű fájlok helyett Gitben tárolva.A Git fel szokta ismerni, és átlatszatlanul kezeli.
Magyarán tárolja a teljes
Szerintem ez csak egy felesleges plusz réteg. De te tudod.
Én csak az adatbázist módosító szkripteket tárolnám gitben.
Mysqldump szövegfájlt készít? Keverem az oracle exporttal?
Mysqldump szövegfájlt
Igen, SQL-t ír fájlba.
WHERE
Aztán így dumpolsz (bash):
mysqldump (...) --where='DATE(modositas_datuma) = ${TEGNAP}' | bzip2 > dump_${TEGNAP}.bz2
Működik, szóval ilyen
Ugye a git alapvetően nem diffeket tárol, hanem minden objektum egy CAS-ban él. Ha túl sok (ugye ezt nekünk kell konfigurálni, hogy mi a túl sok) ilyen objektum van, akkor ezeket egy packba pakolja, ami már ténylegesen egy tömörített valaminek fogható föl (nem igazán ástam bele magam, de nekem az jött le, hogy ezek többé-kevésbé tömörített diffek). Persze ezekből is túl sok lesz egy idő után, szóval újra kell őket csomagolni (amihez megint valamilyen git varázslás kell).
A mysqldump és a szöveges
mysqldumpés a szöveges formátum szerintem eléggé iparági sztenderd, legalábbis ott, ahol az adatmennyiség nem kíván mást.A Git működéséről én is nagyjából ennyit tudok, és egyetértek vele hogy mágia.
Örülök, hogy előkerült, a
Én személy szerint azzal sem voltam tisztában, hogy ilyesmi létezik. Full backup + Git helyett mindenképp megéri ezt használni, ha támogatja az adatbázis. Amihez nekem kell az pgsql és neo4j és mindkettő támogatja.