MySQL differenciális backup / dump

Adatbázis: SQL, XML DB

Sziasztok!

Van egy (szerintem) nagyon jó feladatom számotokra. Adott 7 szerver, teljesen más-más adatbázisokkal. Valahol csak 2 DB van, van ahol 22. Van amelyik 10 MB, van ami 3 GB. Ki lett találva, hogy időspórolás és HW erőforrások megfelelő elosztása érdekében legyenek csak havonta teljes backup-ok, naponta viszont legyen differenciális backup. Na, én meg rábólintottam, hogy ez jó ötlet... csak épp nem tudtam, hogy a MySQL alapból nem tud ilyet és csak mókolt szkripteket találtam a Google segítségével.
A backup úgy készül jelenleg, hogy van egy Backup szerver aki X időközönként be SSH-zik a kliensekre, csinál egy SQL dumpot kompletten, csinál egy tar-gz fájlt a /var/www-ről majd ezt a 2 fájlt az rsnapshot szépen átmásolja a szerverre a megfelelő helyre. Ez addig szépen és jól ment míg el nem értük a gigás méreteket. :)

Kérdés: Ti hogyan csinálnátok minden adatbázisról különbözeti mentéseket? És, ha lehet nem növekvőt, hanem különbözetit. Szerintem az biztonságosabb, de cáfoljatok meg kérlek, ha nem. :)

A rendszerek amúgy CentOS 6-7 alapúak.

Mi Percona-zunk (néhol Percona XtraDB Cluster is), de backupra a jó öres mysqldump megy --single-transaction opcióval. SSD van alatta, megy rá egy targz és 1-2-4 óránként (ügyfél függő) van teljes dump. Megy. Mondjuk nem videokat streamelünk DB-ből, max 100-500Mb a targz-zett dump.

( andrej_ v | 2015. 11. 21., szo – 11:39 )

Ha biztonságos és gyors hálón eléri a backup gép az éleset, akkor inkább egy külön sql-re dedikált SQL juzert csinálnék és a backup gép tömörítene.

( sj | 2015. 11. 21., szo – 12:15 )

Ki lett találva, hogy időspórolás és HW erőforrások megfelelő elosztása érdekében legyenek csak havonta teljes backup-ok, naponta viszont legyen differenciális backup.

nyugtass meg, hogy ez csak vicc akart lenni...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Megnéztem a backup scripjeinket és eszembe jutott még valami:
Vannak nagy, felesleges tábláink: Activity vagy LogActivity, benne minden oldallátogatás. Ezek jók valamire, de nagyok ahhoz, hogy túl fontosak legyenek. Néha a DB fele ez.

Ezeket az óránkénti mentésből kihagyjuk, csak a napi nagy mentésben vannak benne. Már a felét megspóroltuk a méretnek...

mysqldump --skip-table=XXX

Érdekes, teoretikus kérdés. A mi álláspontunk erről:
- A tábla adatai fontosak.
- Nem csak az utolsó 6 hónap, hanem az utolsó 5 év is.
- A tábla adatai annyira fontosak, hogy az operatív 25GB mellett ez megér +25GB-ot (kb. 250GB SSD egy VPS-ben $30/hó)
- Az óránkénti mentést jelentősen gyorsítja ha ezeket kihagyjuk.
- Ha havaria van (ne legyen, mentés emiatt van, soha ne legyen rá szükség), akkor max az utolsó napi logból hiányozhat adat a restore után.

A zárójeled egy másik gondolatot indított el: akár csinálhatnánk azt is (köszi az ötletet!), hogy egy data-pump a különböző szerverek logjait folyamatosan pakolja egy dedikált LOG-gépre. Annak a mentése pedig az operatív adatoktól független lehet. Jó lenne SQL alapon logolni, mert könnyebb lekérdezni, de talán lehetne nosql is (mongo), ha a különböző szerverek különböző adatokat raknak el.

adott kornyezetben az is mukodhet, hogy egy slave-re replikalod az adatokat, majd amikor eljon a mentes ideje, akkor suspendeled a replikaciot, kiflush-olsz mindent (valahogy), aztan elteszed a mysql db konyvtarakat.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Nem teljesen erre gondoltam, de örülök, ha gondolatébresztő volt a kommentem. Ha nem túl sűrűn vannak lekérdezve az Activity{Log} táblák, akkor meg lehetne csinálni, hogy a "régi" rekordokat, amik kvázi statikusak, egy külön DB-ben (DW) tárolni, amiről nem kell óránkénti, csak napi mentés készüljön. Minden nap végén egy karbantartó folyamat legutna, ami a "régi" rekordokat áttolnná a DW adatbázisba. Aki pedig lekérdezéseket akar futtatni, az megteheti a DW-n, annak tudatában, hogy csak az előző napig vannak benne adatok.

( freeoli v | 2015. 11. 21., szo – 13:38 )

http://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html

binlog segítségével lehet valami hasonlót elvégezni.

Vagy. LVM/FS szintű snapshottal történő mókolgatás.

De őszintén hagyd a fenébe, az egész ötlet beteg ahogy van. Ha csak nem akarsz mysql db-ben több jártasságot szerezni akkor ne foglalkozz vele. Ha helyet akartok spórolni akkor kell egy compress+dedup fs a tömörítetten dumpok tárolására azt csókolom. A 2Gb meg kerek 20 mp egy GB hálón.

Szerintem a konzisztencia - backupról van szó - irreleváns, ha tranzakciós DB-t mentesz.
Ugyanis, ha vissza kell állnod, mindenképpen veszíteni fogsz adatot. 5-6 perc ide/oda nem mindegy?
Egy InnoDB simán visszaáll a legutolsó konzisztens állapotra, ha a visszaállított fájlszintű "backup" nem konzisztens.
Nam hiszem, hogy nagyon sok olyan db van, ami megharagszik, ha MyISAM-ról InnoDB-re megy át.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Az _sem_, nem, hogy a többi :-P Normális esetben tud a DB olyat, hogy a lezárt tranzakciók adatait kitolja a diszkre, és amíg nem szólunk neki, addig a logba írja csak az időközben lezáródó tranzakciók okozta változásokat - hogy az adatfájl konzisztens maradjon, míg elmásoljuk/snapshot-ot csinálunk, stb.

FS szinten konzisztens lesz, de egy MyISAM táblánál vagy bárminél amiben nincs tranzakció naplózás ez egyáltalán nem biztos, hogy adatbázis szinten is értékelhető. Egy postgres vagy innodb jó eséllyel visszaáll, de az igazi mindíg a saját natív mentőeszközt használni. Sokmindent mentek LVM snapshot alapon, de adatbázisokat mindíg dumpolgatok, ahogy a nagykönyvben van.

:) Hát és még mennyi legacy cucc fut vagy mennyi olyan van, ahol a db sémában fixen myisam van beégetve... Természetesen bármilyen változás óriási sikítás hogy jajjmindenelromlik és "már megint" minek kell "mindent" megváltoztatni. Olyan apróságok, hogy amit használnak régen nem supportált, elavult stb. az falra hányt borsó.

Ennél van durvább is: alkalmazásban használják az "ls" parancsot egy rakat kapcsolóval paraméterezve - aminek a kimenete a dátum/idő mezőkben nem azonos a friss ls által produkálttal. (Amit használnak, az a fileutils-ból a 4.1, miközben a coreutils-ból az 5.97 az aktuális). Lecserélni, kódot módosítani nem lehet - a régi, 32 bites "ls" binárist kell felmásolni minden érintett gépre, és a PATH-t úgy beállítani az alkalmazás alá, hogy ez a f0s hamarabb legyen, mint a "gyári" ls...
Pedig a --time-style használatával megoldás is lett volna a problémára, de nem, mert a fejlesztő így adta át a kódot és kész...

Lehet megérné írni egy patch-et a coreutils-hoz, hogy a benne lévő kurrens ls paraméter nélkül adja meg a kimenetnek a szükséges time-style-t...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ha már szóba jött...
Mik azok a feature-ök, amik nem engedik meg, hogy egy generálisan régi, MyISAM-os db-t áttegyen a jóember InnoDB alá?
Mellékesen jegyezném meg, hogy lehet szídni a MyISAM-ot, de alacsony táblaszám és relatíve kis méretű táblák mellett erőforrástakarékosabb.
--
PtY - www.onlinedemo.hu, www.westeros.hu

Akkor kifejtem. :) Arról volt, hogy LVM snapshot alapú mentés jön és az nem biztos, hogy az FS szintű db mentést rendesen konzisztensen viszi. Erre jött a válasz, hogy a innodb elviseli, mert megfelelően kezeli a helyzetet. Nekem még elég sok MyISAM formátumú DB-hez van szerencsém, amikkel különösebben nem akarok foglalkozni és hiába passzírozom át őket InnoDB-re mondjuk most, ha a juzer magának létrehozza újra a tábláit bármiért az eredeti sémája szerint, akkor megint MyISAM lesz. Legalábbis ahol fixen bekerült az ENGINE=MyISAM a tábladefiníció.

Na ne basz, erről szól a Write-ahead log, hogy de, legyen már konzisztens. MSSQL konkrétan úgy backupol, hogy VSS-el csinál egy snapshotot az adatbázis fájlról...

http://www.postgresql.org/docs/9.1/static/wal-intro.html

http://dev.mysql.com/doc/refman/5.7/en/binary-log.html

https://technet.microsoft.com/en-us/library/ms186259%28v=sql.105%29.aspx

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Jó, aki tökön akarja szúrni magát, az tegye. Ettől függetlenül a snapshoting egy életképes megoldás, amennyiben nem retard módon van felépítve a DB.

(Mondjuk halkan jegyzem meg, hogy a MySQL-el az utolsó tapasztalatom az volt, hogy még azt sem képes ellenőrizni, hogy elfogyott-e a lemezhely alóla és csini hibaüzenet helyett inkább összeomlott és lehetett mysql repair tablet nyomni, míg a PostgreSQL ilyenkor rollbackelte az utolsó tranzakciót, kiírt egy hibaüzit a logba - külön köteten volt - és nem egy összeomlással zárta a napot.*)

((*Azt most ne feszegessük, hogy miért fogyott el a lemezhely. Csak. Balesetek előfordulnak.))

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

LVM/FS snapshottal konzisztens lesz (pont úgy fog kinézni, mintha a gép megállt volna a snapshot pillanatában, és nyomtál egy rebootot - ebből egy rendes tranzakcionális adatbázisnak fel kell állnia). Csak annyi a feladat, hogy a _teljes_ adatbázisra egyszerre készüljön a snapshot. Ez ugye nem triviális, ha nem egy fájlrendszeren/volume-on lakik az egész.

Viszont snapshot nélkül (tehát ha csak szimplán elkezded a fájlokat/diszket a futó, módosuló adatbázis alól kimásolni) jó esélyed van arra, hogy korrupt legyen a mentés, és ezen az innodb sem segít.

Inkább régebbi tapasztalás volt ez, amikor még nem volt divat boldog-boldogtalan alkalmazás alá külső rdbms-t rakni. Ha az alkalmazás fájlokban tartja a cuccait, és nem tisztán adatbázislibet használ erre (pl. libdb.so, libgdbm.so), akkor ott nagyon gyorsan felmerülnek a kétségek (régi HP NNM, 46020, hogy a két "kedvencemet" emlegessem).

Azt mondjuk sosem mertem megnézni, hogy ha random Linux alatt pl. package telepítés/frissítés közben nyomok egy resetet, akkor mi történik. Nem tartom kizártnak, hogy esetleg ilyenkor lehet elővenni a backupot/install médiát, mert menthetetlen lesz a cucc.

> Inkább régebbi tapasztalás volt ez, amikor még nem volt divat boldog-boldogtalan alkalmazás alá külső rdbms-t rakni.

OK, de ez ne legyen mar a felsoroltak mellett:)
Amugy igy erzesre az sem szabadna, hogy inkonzisztens legyen. Napi backuprol van szo, sorban az utolso commmitok elveszhetnek, csak legyen konzisztens.

> Azt mondjuk sosem mertem megnézni, hogy ha random Linux alatt pl. package telepítés/frissítés közben nyomok egy resetet, akkor mi történik. Nem tartom kizártnak, hogy esetleg ilyenkor lehet elővenni a backupot/install médiát, mert menthetetlen lesz a cucc.

Szerintem meg annak sem kene problemaznia.

Nade épp ez az: default beállításokkal a fájlrendszerek nem garantálják az I/O műveletek sorrendiségét egymáshoz képest (sem egyik fájl-másik fájl, sem egyik fájl-másik fájl/könyvtár metaadata vonatkozásban, de talán még talán a fájl és az ő saját metaadata vonatkozásban sem). Értsd: létrehozol egy fájlt, meg belemódosítasz egy másikba, és lehet, hogy az első fájl elveszik, a második módosítás meg megmarad. Ez minden, csak nem konzisztencia.

Épp ezért raknak az RDBMS-ekbe naplózást, aminek hatására:
- Nem lesz meg minden adat, ami kiküldtél a HDD-re (!!!)
- De konzisztens marad az adat (egyben kiküldött (egy tranzakció) adatok egyszerre fognak kiíródni vagy elveszni)

Ha a naplófájl sync-kel kerül kiírásra (mysql beállítás, hogy mennyire legyen "sync": OS vagy disk szinten), akkor a fentiek elégségesek, gyakorlatban mindegy egy visszaállításnál, hogy az utolsó 30mp megvan-e vagy nincs. Ha a sync nem okés (nincs sync vagy SSD-nél kiment a sync, de az áram elkóborolt...), akkor a naplózó DB sem lesz jó. De általában az is javítható, max találsz egy létező számlát, aminek nincsenek meg a tételei (vagy fordítva, foreign key failed). De ez olyan ritkán fordul elő, hogy inkább kifizeted a szoftveres munkáját, mint hogy földbe ásd a szervert RAID-10-zel, külön aggregátorral.

Mindig a mérlegelés dönti el, hogy mi éri meg...

Nem teljesen ertem.
Szerverekrol van szo. Amennyibe ez erdekes, akkor az alkalmazasnak meg kell gyozodnie, hogy jol csinalja.
Amenyiben az FS nem hazudik szandekosan (javits ki, de ilyen nincs default beallitasnal), akkor minden jonak kell lennie.

De ha megis, ne hasznalj default beallitast.

Te nem keszited fel a szerveredet varatlan leallasokra? Ha van UPS, ha nincs, en nem szoktam ra szamitani.
De bevallom, mindig tovirol hegyire nem szoktam utana jarni. Remelem, nem lesz belole gond.

Ha nem bugos az FS, a driver, a firmware es a tobbi es azt teszi, amit mondanak neki, akkor nem lehet problema.
Ezek kozul azert jellemzoen szokott lenni gebasz en megsem talalkozom surun ilyennel.

De megegyszer, azt nem mondanam, hogy 100%-ig mindig minden esetben megbizom bennuk. De ahol ez gond es szamit, ott mar ugyis meg kell oldani tisztessegesen (= pl. dump).

Amennyibe ez erdekes, akkor az alkalmazasnak meg kell gyozodnie, hogy jol csinalja.
Amenyiben az FS nem hazudik szandekosan (javits ki, de ilyen nincs default beallitasnal), akkor minden jonak kell lennie.

Az alkalmazás nem teszi. Feltételez olyan dolgokat az írója, amiket a FS alatta nem garantál default beállításokkal, de mondjuk egy hard reset/crash pillanatáig nem is derül ki, akkor is csak attól függően, hogy éppen mennyire tekert az alkalmazás (ha éppen üresen ketyegett, akkor megintcsak nem történik semmi), illetve mekkora volt a mázlifaktor. Nyilván aki RBDMS-t fejleszt, az azért nagyjából tisztában van ezekkel a fogalmakkal, de aki mondjuk egy telkó eszközhöz ír felügyeleti szoftvert, az esetleg teljesen clueless lehet a témában.

Akkor megoscsak az sw-ben van a hiba.
Azaz szarbol nem lehet varat epiteni es sysadmin level szintjen lehet mwgoldani workaroundolva.

Amugy konkretan mit feltetelez?

Megjegyzem, a dba srac nalunk epp a multkor mondta, emc storage, snapshot, es nem ment a recovery, Oracle-vel.

De ezt en nem akarom elhinni.

Ott jott elo a tema, h mire jo a zfs snapshot, mire nem.

Orákulumul meg valahogy úgy hangzik, hogy alter database begin backup/end backup - bár marha rég volt, amikor ilyennel is foglalkoztam :-) A lényeg, hogy szólni köll az adatbázisnak, hogy próbáljon jó képet vágni a snapshothoz, és a diszken igyekezzen konzisztens állapotot létrehozni :)

Nem fog. Se jó képet vágni, se konzisztens állapotot létrehozni. Mármint abban az értelemben, hogy ha visszatöltöd a db fáljlokat és az instance ráindul, akkor a szívéhez kap, és sértődötten közli, hogy physical recovery needed. Asszem (10+ éve volt :D). A begin backup annyit csinál, hogy mint állat elkezdni írni a redo log fájlt (is), abba is elhelyezve mindent, amit amúgy a db-be írna. A db fájlok mentés közben meg is fognak változni. Az eleje még a 131231-es SCN-en van, de a vége már mondjuk 131235-ön (+4). Ezért az alter database end backup után (utána célszerű :D) le kell menteni a redo log fájlokat is. Ebből fogja majd helyrepofozni a csálé blokkokat.

Persze lehet futtatni a db-t archivelog módban is, akkor lehet tekergetni ide-oda az időben. Ezt pl. tudja mysql is (nekem már mentette meg az életemet, hogy a delete from elé el tudtam tekerni mentésből).

Remélem jól emlékszem, ha nem, akkor majd egy dba kijavít. A lényeg, hogy a lementett db marhára inkonzisztens (mert mentés közben írható és íródik is), de javítható. Annó kifejezetten féltem (rettegtem) ettől a megoldástól, de 10+ helyreállításból egyszer se volt gond belőle.

Persze, így teljes - nem véletlen, hogy külön tanfolyás volt mentés és helyreállítás témában Oracle-höz... Az archivelog mód számomra alap. A fájlok önmagukban nem lesznek 100%-ban konzisztensek, de a teljes fájlkészlet, ha betartja az ember a mentési eljárás lépéseit, akkor konzisztens állapotra hozható.
A lényeg annyi, hogy ha az RDBMS nem tud arról, hogy mentik a fájlokat, akár snapshot-tal egyszerre, akár úgy, hogy raid-tükörből kihúzzák az egyik diszket (ilyen ötlet is jött szembe, de arról gyorsan lebeszéltük a delikvenst), akkor egyáltalán nem garantálható, hogy a diszken olyan állapot lesz, amiből értelmes ráfordítással élő, működő adatbázis rittyenthető.

Ööö.... az alter system switch logfile (flush logs) annak számít hogy tud róla? :D Utána kéne olvasni, de kb. az rémlik, hogy amíg van egy kiinduló állapot - "full mentés" - a db-ből, addig elég a logfile-okat menteni - "inkrementális mentés" -, mert helyreállítható a cucc. Nem kell bűvészkedni snapshottal, read lockkal, ésatöbbi.

A checkpoint kényszerítése az egyik része a dolognak. A "ha van full backup, akkor csak a logokat kell rápakolni" jól hangzik, de... Kellően bőséges archivelog bedolgozása azért kellően hosszú ideig is tarthat (a mennyiség alapján azért becsülhető idő alatt). Úgyhogy "néha" azért kell full backup - az alter database begin backup egyébként emlékeim szerint pont egy kikényszerített logváltással indít - de nekem is utána kéne olvasnom.

Melyik igen? Nem azt írtam, hogy kötelezően maga alá rondít mindegyik és minden ilyen esetben, de messze nem lehet garantálni azt, hogy elfogadható időn belül konzisztens állapot lesz a snapshot-ból. Márpedig menteni azért ment az emberek értelmesebbik része, hogy a mentésből könnyebb legyen újraépíteni a rendszert, mint a romokat helyrevakarni.

Azt írtam, hogy nem minden esetben éli túl. Ez azt jelenti, hogy lehetséges olyan állapot, aminél elvéve a tápot bizony értelmes időn belül nem fogod tudni a romokból feléleszteni a rendszert. Elméletileg lehet, hogy nincs ilyen, de a gyakorlat sajnos mást mond. A mentésnek meg illendően úgy kell elkészülnie, hogy ilyen probléma ne lehessen vele.
A shutdown abort az a lemezen rendet hagy maga után - az agyonvágott tranzakciókkal együtt; ez utóbbiak csak a logikai konzisztenciát törik meg - azt meg az induláskor szépen ki lehet gereblyézni.

A shutdown abort pontosan egy kill -9. Egészen biztosan nem küld ki már több I/O-t a szoftver.
Amennyiben ez különbözik a tápelvételtől, akkor valahol valaki valamit hibásan csinál = nem tartja be az ígért garanciákat, vagy olyat próbál kihasználni, amit nem ígértek meg neki. Ezt én simán bugnak nevezném.

Akkor megoscsak az sw-ben van a hiba.

Hát kb. innen indultunk :D

Amugy konkretan mit feltetelez?

Pl. hogy ha két fájlt módosít, adott sorrendben, vagy egy fájlt módosít, egy másikra meg FS műveletet végez (create, rename, stb.), akkor ezen műveletek végrehajtási sorrendjével ellentétes sorrend nem fordulhat elő a diszk I/O szintjén. Azaz feltételezi, hogy nem állhat elő olyan állapot, hogy a második műveletet a diszk végrehajtja, az első meg elveszik. Pl. létrehozunk egy fájlt (mondjuk egy upload form kapott egy fájlt), majd miután kiírtuk és lezártuk a fájlt, beírjuk egy másik (text) fájl végére a nevét. Ha a text fájlban ott a sor, de a fájl "eltűnt", akkor hasra esik a sw.

Hát van async io (POSIX aio), O_DIRECT-tel kiegészítve az már elég a fájl tartalmára vonatkozóan, illetve a több fájl egymás közti konzisztenciájához, így a performanciával sem lesz gond. A fájl metaadatokat illetően viszont szerintem nincs API erre, tehát az marad a lutri, vagy a sync() az egész gépre...

Más fájlrendszerek alatt sem tudni ilyen feature-ről vajon? Hamar hirtelen belegondolva egy olyat tudnék elképzelni kernel oldalról, hogy a folyamat által nyitott file descriptor-okra adhatna jelzést egy flag-gel, hogy ezek kiíródtak fájl és meta adatokkal együtt sikeresen.

Bár ugye még ott van ezen felül a gyorsító memória pufferek kérdése, melyek lehetnek lemezen, illetve raid kártyákon vagy egyéb vezérlőkben. Az lenne a jó, ha a backend disk vagy tároló tudna visszajelezni, hogy az adatok sikeresen eltárolódtak.

Mindenesetre nagyon érdekes a kérdéskör.

Azt mondjuk sosem mertem megnézni, hogy ha random Linux alatt pl. package telepítés/frissítés közben nyomok egy resetet, akkor mi történik.

Abból adódhatnak problémák :) A napokban abba szaladtam bele, hogy CentOS-en megszakadt a frissítés (már a cleanupnál, tehát a csomagból jövő fájlok a helyükön), utána bootkor kernel panic. Korábbi kernel elindít, akkor láttam, hogy a kernel ott van a helyén, a grub már meg is találta, hogy ott van a kernel és úgy gondolta, hogy akkor initram is biztos van - csak persze nem volt... (dracut oszt öröm és bódogság)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( dotnetlinux | 2015. 11. 22., v – 09:24 )

Amíg egy DVD 4.7GB és 299Ft, addig nem szempont a HW spórolás...

Profi megoldás ott kezdődik, hogy enterprise hdd, azok közül is valami 15krpm SAS lemez, amiből mondjuk egy 600 gigás olyan 120-150k HUF+Áfa
(Ha brand storage van ráadásul, akkor oda ilyen lemezek brand változatai jók csak, az árcédula meg 2-2,5x szorzóval értendő.)
Ezek is RAID10-ban, bár backup esetében kiegyezek RAID5-6 vagy azzal ekvivalens megoldással (RAIDZ1-2 pl.).

Tehát nem jól szemléltetted, mert consumer wd green és tsai lemezeket (amik kb analóg kategória az általad említett olcsó optikai adathordozóval) akár backup-szerverbe is rakni, nem a PROFI megoldás, hanem a GÁNY megoldás.
Esetled ha háromszor annyit raksz belőlük, és csoportonként 3 lemezt RAID1-ba teszel, a csoportok fölé meg kihúzol egy RAID6-ot, akkor esetleg. :) (persze ez csak vicc volt, de remélem átjön a probléma...)

Ne dobd ki, de új beszerzés esetén értelmelten, mert árban a flash drive-okkal vannak egy szinten, de teljesítményben messze elmaradnak. És ezt nem én mondom, hanem pl Larry Ellison (ha kell, kikeresem a keynote részletet), vagy éppen a HP:

https://www.linkedin.com/pulse/20140721193344-18391615-have-we-hit-a-fl…

"Mester?"

A stílus maga az ember.

Nekik eladó a motyó :-) A karos diszk már bőven behozta a belefeccölt fejlesztési erőforrásokat, az új, "picit" drágább ssd még nem.
Egyébként van abban valami, hogy új beszerzés esetén tényleg el lehet azon gondolkodni, hogy karos diszkből raid 10 jellegű tárolás, vagy ssd-ből mondjuk raid5/raid6. Azokat a régi alapvetéseket, hogy ami gyors/nagy iops-ot nyújt az a raid10, ami meg f0s lassú az a raid5, meg a raid6, azt ssd-nél szerintem el lehet felejteni.

Ahol elsőre az SSD-ből összerakott raid-tömb felépítéséből adódó sebességbeli különbség a probléma, ott sem biztos, hogy költség oldalról az n+1 helyett 2n darab ssd a jó megoldás - láttam én olyat, hogy az alkalmazás hangolásával, itt-ott jelentősebb átírásával, addig nem használt technológiák bevezetéséven a "sebességben kinőttük" hardvert tovább tudták használni. Kiszámolták, hogy a storage átalakítása többe kerülne, mint a szoftver részleges újragondolása.

Nem azt mondom, hogy nincs olyan workload, ahol számít, hogy milyen elven áll össze a logikai diszk a fizikai meghajtókból, csak azt, hogy SSD-k esetén nem a tömb nyers I/O-teljesítménye az, ami csúcsra járatva a storage-ot elsőként fog elfogyni. Szerintem...

Azokat a régi alapvetéseket, hogy ami gyors/nagy iops-ot nyújt az a raid10, ami meg f0s lassú az a raid5, meg a raid6, azt ssd-nél szerintem el lehet felejteni.

en ezzel a mondattal nem ertettem egyet, kicsit eltavolodtunk tole, ami nem baj, csak mondom.

persze, en is lattam mar nem optimalisan megirt alkalmazast, ahogy nem optimalis adattarolast is es minel nagyobb a storage, annal olcsobb a fejlesztesi oldalon modositani. a komoly adattarolas amugy sem a RAID-rol szolt sosem.

mellesleg nemreg atment a kezeim kozt egy marketinganyag, amiben SAS SSD-kbol allo Ceph clusterben NVMe SSD-ken voltak a journalok es annak is volt megadva maximalis teljesitmenye, szoval barmit ki lehet koppantani a jelek szerint:)

Hát, mostmegnéztem azért, hogy ez tényleg így van-e:

-15krpm 600GB LFF SAS disk 120ezer Ft körül van.
-Intel SSD DC S3500 600GB pedal 230-240ezer Ft körül.

Azért egy nem egy szint, azt SSD kb. a duplája.

Nálunk van egy 8x15k rpm-es SAS zfs RAID10 tömb, 10g iSCSI-n csatlakozik egy vmware host-hoz. Van rajta kb. 18 virtuális gép, amiből kb. 10 az ilyen VDI megoldás, egy fileserver, meg kisebb szerverek (adatbázis, firewall, proxy, stb.stb.).
Egyáltalán nem lassú semmi se, nem tudom, miért lenne jobb kb. 1.000.000 Ft-tal többért SSD-t venni a 8 darab 15k rpm SAS helyére.
Ha tennék is bele SSD-t, akkor azt is max. ZIL LOG-nak tudnám elképzelni, esetleg ARC cache-nak, de talán az is pénzkidobás, mert sok RAM van a zfs gépben.

Összegezve árban rohadtul nincsenek egy szinten, teljesítményben papíron persze, hogy sokkall jobb az SSD, gyakorlati hasznosításban nálunk, és még biztos sok helyen, nem hoz annyi plusszt, hogy a teljesítménybeli fölény marginális legyen.

Árban a duplája, lehet. (Bár erre még visszatérek.)

Csak az intel SSD-re az intel ezt írja:
Random 4KB Reads: Up to 75,000 IOPS
Random 4KB Writes: Up to 11,500 IOPS
A 15k-s vinyóból mennyit is tud random IOPS-ben? Párszázat?

Mert van olyan workload, amikor az számít, a helyigény pedig nem olyan nagy. Iyen esetben veszel mondjuk 2 db 600-as SSD-t mirror-ban, és ez simán úgy teljesít, mint 10-20, vagy akár 50-100 15k-s vinyó. Ez utóbbiból persze nem kell 600-as, simán elég a jóval kisebb is, de még úgy is sokkal drágább lesz.

És vissza az árra. Ha nem 600-as SSD-t veszel, hanem 300-ast és azt rakod raid0-ba, akkor 2x82k-ból megúszod (bruttó kisker ár), ami már alig drágább a vinyó 120-ánál. Mondjuk ez SATA és nem SAS, de még így is sokkal jobb.
De terás samu 850 pro-t is látok árlistában bruttó 140 alatt, ez pedig minden paraméterben jobb lesz a vinyónál, Ft/GB arányban is.

Ahogy elnézem, jelenleg kettő dolognak van értelme:
1) olcsó 2-3-4+ Tb-s SATA diskeknek, ha tárhely kell.
2) SSD-nek.

Ha sebesség kell, kiröhögik az SSD-k a 15k-s SAS diskeket, ha tárhely, akkor meg az ára miatt. Profi-e vagy sem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nincs mindenhol igény a »PROFI« megoldásra. Nekünk pl. 6x3T WD Red van egy gépben raidz2-ben, backupra. Működik nincs vele baj. Ha kihullik egy disk, akkor meg gyakorlatilag végtelen mennyiségben áll a polcon úgy is. (Igaz, megvan az az előnyünk, hogy egy nagyker vagyunk.) Igényeket kielégíti ez is _bőven_.

DVD-t meg hagyjuk, archiválásra se igazán használnám, túl sok macera, Ft/Gb-ben is piszok drága.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( KaTT | 2015. 11. 23., h – 16:13 )

Szia!

Ha kész az inkrementális MySQL mentés megoldásod, akkor ha használod és kipróbálod, leírhatnád a tapasztalataidat a visszaállításról, és hogy miként működik az inkrementális mentés alapvetően és hogy mennyire vállt be.
Olvastam erről a binlog-os megoldásról, de nem találkoztam még ilyennel a gyakorlatban.
Nekem nem tűnik jó ötletnek.

Esetleg javaslom mint alternatíva átgondolni az aszinkron MySQL replikálást a backup gépre.

Vagy ha nem fontos a folyamatos működés, leállítod a MySQL-t, majd rsync a backup gépre, majd ha kész, elindítani a MySQL-t.
Ezt az utóbbit csak retro fun megoldásként javaslom :)

Én a teljes dump-ot javaslom, vagy amit már többen javasoltak, hogy a backup gépről lépjen be az SQL kliens, az úgy a leggyorsabb, ha elég gyors a net a gépek között.

Sakk-matt,
KaTT :)

Backuphoz? Haha, egyik géppel rendszeresen volt abból problémánk, hogy a PostgreSQL nekiállt backupolni éjjel úgy ~40-45 Gb-nyi adatbázist és időnként komolyan veszélyeztette a backup az oldal működését, akkora IO-t generált a diskeken. 4x10 vagy 15kRPM SATA disk ftw.

Öröm volt migrálni a DB-t arról a gépről egy újra, amiben végre volt külön SSD storage az adatbázisnak. (Sajnos az oldal még onnan fut, de az nemigazán csinál nagy IO-t, max a static tartalom, de az a DB-hez képest lóf...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Négy tengely komolyabb terheléshez marhára kevés, pláne, ha duplán használod (olvasol és írsz is rajta egyszerre nagy mennyiségben). Sajnos a legtöbben csak az elérhető hely méretére szokták kalkulálni a diszkeket, ami otthon/kkv szektorban elmegy, de nagyobb terhelés esetén iops-ra köll lőni - inkább sok kisebb diszkkel, mint kevés naggyal. (A méret adja a helyet, a tengely meg az io-teljesítményt...)

( bertalanimre | 2015. 11. 26., cs – 13:26 )

Na sziasztok!

Elnézést kérek, hogy csak dobtam ide egy topicot aztán ide se bagóztam, de annyira belemerültem a probléma megoldásába, hogy csak oda koncentráltam. :) Vegyük sorra akkor, hogy Miért, Mit, Hogyan.

Miért:
- A VPS-ek csak minimális webkiszolgálók, nem rendelkeznek nagy erőforrásokkal. Egy 1GB-os SQL import is képes megfektetni, akárcsak az dump. Ilyen "erőforrás igényes" folyamatokat pedig nem engedhetünk meg napi szinten mert a honlapnak működnie kell. Volt már, hogy dump alatt a honlap nem volt elérhető. (Na ilyen már nem lesz több)
- Mint mondtam, a honlapnak 0-24, 7/7 mennie kell. Ne arra "fecsérelje az erejét a gép, hogy nekem dumpoljon
- A backup szerver itt van lokálisan, a VPS meg messze valahol. Az adatok közvetlen SSH útján jönnek-mennek (scp, rsync, rsnapshot, stb). Nem szoktunk olyan webes megoldásokat alkalmazni mint phpMyAdmin vagy cPanel, ismét azért, hogy ezzel se kelljen foglalkoznia a VPS-nek. Egyszerű legyen a szerver, minél kevesebb funkcióval.

Mit:
- MySQL dumpok kellenek a honlapról arra az esetre (jaj, nehogy ilyen történjen akármelyikünkkel), ha a honlap kompromittálódik vagy sérül. Ilyenkor a legfontosabb ami kell: /var/www mappa, valamint az sqldump. (meg persze opcionálisan a /etc/nginx mappa mindenestül, hogy ezzel is kevesebb idő menjen el, sőt a /etc/php.ini és /etc/php-fpm.conf)
- Az SQL adatbázisról legyen elég a komplett mentés hetente vagy havonta. Viszont legyen napi mentés, hogy bármelyik időpillanatra vissza lehessen állni.

Hogyan: (most jön a lényeg,hogy oldottam meg)
- A legelső hozzászólás blackluck-tól (köszönöm utólag is) pontosan az amire én is gondoltam. gyakorlatilag pontosan erre találták ki. Azonban gondjaim adódtak a használatával. Lehet járatlanságom miatt, de egyszerűen nem tudtam visszaállítani adatokat a teszt rendszeren, hiába voltak meg a backup-ok. Valamiért minden helyreállítás után azt az üzenetet kaptam, hogy sikeres volt, de mégse jött vissza mondjuk egy droppolt tábla.
- További kutatás után találtam egy remek Python "alkalmazást" ami az XtraBackup-ot felhasználva felhasználóbaráttá teszi a használatot. A lényege, hogy a mentéseket ő maga elintézi, neked csak user+pass kombót, a mentés helyét és a teljes mentés helyét kell egyszer megadni a konfigurációjába. Onnantól ő a megadott mappába lementi az inkrementális mentéseket a megjelölt mappában lévő teljes backup alapján. Kellett kicsit turkálnom a kódban, ugyanis két hibába futottam bele.
- Az első hiba a futtatás volt. A srác aki a script-et csinálta, debianon tesztelte csak és ennek megfelelően hardcode-olta a service újraindítás metódusát. Megkerestem a megfelelő fájlt, átírtam benne a MariaDB szerver indítását, leállítását vezérlő sort és átírtam.
-- command = ['/etc/init.d/' + service_name, action]
++ command=['systemctl' + action, service_name]
Innentől már futottak a mentések.
- Cron-ba beállítottam magamnak a teszt rendszeren egy óránkénti mentést és néha-néha felmegyek a teszt környezetbe, kitörlök egy táblát, hozzáadok egy új usert, felveszek új táblát, vagy épp új adatbázist, stb
- A második hiba az első visszaállításnál jelentkezett. Ugyanis lefutott a visszaállító script, azonban leállt a MySQL szerver és nem tudtam sehogy se újraindítani. Szó szerint sehogy, se safe módban, se reboot után. Szóval kilőttem a script-el valahogy véglegesen. :) Na, majdnem feladtam, mikor rájöttem, hogy a /var/log/mariadb/mariadb.log hibaüzenet szerint a programban megadott "innodb_log_file_size" különbözött a valóstól. Hála az égnek mivel kiírta a valós méretet is, Crtl+C, Ctrl+V-vel meg is oldottam.

Szóval így csináltam meg az inkrementális backup-ot a mysql adatbázisomról. Kicsit nyakatekert, de ha már valaki leírja, hogy mit kell csinálni akkor utána az egész beállítása maximum 5 perc, de legyen 10 mert lassan írok.... :)

Erről a megoldásról mi a véleményetek?

"További kutatás után találtam egy remek Python "alkalmazást" ami az XtraBackup-ot felhasználva felhasználóbaráttá teszi a használatot.": mentés idejére leállítja a szolgáltatást (mysqld)? Ez azért kritikus (nálunk), mert a mentés lehet gyors, de mikor lőjük ki 2-20 percre a DB-t?

Update: kipróbáltam, nem állítja le a szolgáltatást...

Update2: Játszottam vele 1 órát. Fullbackup tök gyors, incremental néha lassabb mint a full (összesen 4-5GB-ról beszélünk), pedig a delta fáljok kicsik, pár 100 sor ment be. Van benne database/table megadási lehetőség, azaz hogy mit mentsen csak le, de ibdata fájlt mindig menti, abban az összes db adatrészei benne vannak.

Jópofa, tetszik, de szerintem nálunk marad a mysqldump --skip-table | gzip | sshpass...

( asch v | 2016. 12. 21., sze – 15:09 )

1etemi tanulmányaim alapján (nem nagy kedvenceim az adatbázisok, és szerencsére nem nagyon dolgozok velük élesben) a transaction log mentésével lehet a legcélszerűbben differenciális backupot csinálni.

A tranzakció log előnye, hogy mindig konzisztens visszaállást tesz lehetővé, és egy tisztességes DB esetén úgyis jelen van, csak el kell streamelni a backup vasra is.

Ha fájlrendszer szinten backupolsz, az azért lehet inkonzisztens, mert az adatbázis csak annyit garantál, hogy a fájlrendszer bármely pillanatképéből konzisztensen vissza tud állni az addig kiírt legutolsó tranzakcióig. Viszont a fájlrendszer szintű backup nem garantálja, hogy pillanatképet tudsz menteni, ha közben párhuzamosan fut a DB is, mivel lehet, hogy a DB B,A sorrendben írja a fájlokat, a mentés meg A,B sorrendben készül. Máris kész a baj. (Ha van olyan fájlrendszer, ami konzisztens pillanatképet tud csinálni, az elvileg elég lehet, ehhez a részhez nem értek.)

Azok a differenciális backupok, amik nem eleve differenciálisan írt adatokon (pl log fájlok, vagy verziókezelő kommitok eleve differenciális formában adottak lehetnek) futnak, természetüknél fogva számításigényesek (pl egy rsync egy rakás hash-t végigszámol), és ha a tárolás nem direkt erre van kihegyezve, akkor előfordulhat, hogy egyáltalán nem hatékonyak. Például ha egy update véletlenszerűen teleszór egy nagy fájlt, akkor peches esetben a differenciális mentés akkora is lehet, mint az eredeti. A tranzakció log viszont természeténél fogva a műveletek számával skálázódik. A legtöbb esetben szerintem az lesz a tuti. (Ha relatíve kevés sor változik a táblában.)

Ha mindenképpen differenciális kell, de a hálózat gyors, akkor meg lehet próbálni teljes backupot csinálni (leállással vagy anélkül, ahogy a szerver támogatja), és a backup szerveren diffelni a tömörítetlen állományt amikor már ketyeghet tovább az adatbázis szerver. Ha szerencséd van, akkor talál néhány egyforma blokkot és tud tömöríteni.

Szerk: Thread necromancer lettem egy kicsit.

( thuglife | 2016. 12. 21., sze – 15:18 )

mysqldump > weekly
patch -o weekly.tmp < incremental-daily-0
mysqldump > daily && diff -ruN weekly.tmp daily > incremental-daily-1 && rm daily
rm weekly.tmp

Persze a patcheket folyamatosan ra kell tolni mielott elkeszulne az uj incremental.
Igy teljes sql dump lesz napra visszavezetheto allapotban.

A masik megoldas pedig egy git repo hasznalata. mysqldump && git commit.

( freeoli v | 2016. 12. 22., cs – 07:42 )

A klasszikus backup eszkozok is jok lehetnek. Amit hasznalok most az igy mukodik tomoren:

- Agent alapon helyi mysql felhasznaloval fs szinten konzisztens allapotba hozza a dbt.
- kernel modul segitsegevel fs snapshot szeruseget hiz letre.
- elengedi a mysql write lockot.
- letolti az fs snapshotot.
- deduplikalva es tomoritve tarolja es replikalja tobb telephelyre valamint szalagra.

A szervert egy boot cd segitsegevel helyre tudod allitani.
A mysql adatfajlokat sajnos csak file szinten tudja ertelmezni.
A backup letoltese a hatterben zajlik es nem okoz szolgaltatas kiesest. A write lock max 2 mp.
Ez egy fizetos megoldas.

( hory v | 2016. 12. 22., cs – 15:59 )

Siman jo oreg mysql-el megcsinalhato. Ha beallitod a replication opciot, az osszes irast dump-olja egy visszajatszhato file-ba a mysql. Ha 1G-t elerte, kezd uj file-t. Namost egy paranccsal is ki lehet kenyszeriteni az uj file-t, ha tehat pl. 5 percenkent kezdesz egy uj file-t, akkor a teljes dump + replication bekapcsolassal 5 perces pontossaggal barmilyen allapotot vissza lehet jatszani. Sot, a replication client-el jatszva szerintem meg azon belul is menni fog, csak engem sose erdekelt annyira.

( nikin v | 2016. 12. 23., p – 06:50 )

Egyes pont: Profile... Profile... Profile..
Mennyi idő a dump.
Mennyi idő a dump tömörítése? (mivel vagyon tömörítve?... ugye tömörítve van?)
Mennyi idő a site tar gézája? (miért pont tar géza?, van szebb jobb)
Mennyi idő az rsnapshot?

Mekkora a dump?
Mekkora a tömörített dump? (7zip simán ráfelezhet a gézára)
Mekkora a website géza?

Kettes pont: technikai kérdések:
Hogyan (nem van) biztosítva a db és a website mappa egymással való konzisztenciája?
Milyen gyakran változik a schema?
Milyen messzire akartok visszanyúlni tudni?
Milyen gyorsan kell tudni helyreállni tüzes menykő hullása esetén?
Hogyan (nem van) megoldva a backup off-site replikációja?

https://www.mcdruid.co.uk/content/comparison-of-compression-methods-for…

### ()__))____________)~~~ ########################
# "Do what you want, but do it right" # X220/Arch

( micsa v | 2016. 12. 23., p – 07:58 )

ott van az innobackupex/xtrabackup: le sem kell állítani a mysql szervert, inkrementális backupot is tud, nem csak perconaval működik.