Kezdőlap › Fórumok › Vegyes gondok › MySql slave szerver erőforrásigénye?
- This topic has 7 hozzászólás, 2 résztvevő, and was last updated 10 years, 3 months telt el by pike.killer.
- SzerzőBejegyzés
- 2014-01-07-08:39 #1890711
Szeretnék egy webes alkalmazáshoz majdnem valósidejű mentést készíteni, hogy hiba esetén minél több adatom megmaradjon.A terv az, hogy az adatábzist replikálom a mentés szerverre, valamint lsyncd-vel az alkalmazás fájlredszerét is átmásolom a mentés szerverre.Csak azt nem tudom előre megtippelni, egy ilyen mentés szervernek milyen erőforrásigénye lehet? Az rsync-kel még csak-csak van tapasztalatom, de, hogy egy folyamatosan változó adatbázis replikálása a slave oldalon milyen erőforrásokat emészthet fel valós környezetben, arról fogalmam sincs.Van valakinek tapasztalata, tippje ezzel kapcsolatban?Az alkalmazás folyamatos adatbázis insertek mellett SCSI lemezzel 1-2 XEON processzort foglal le átlagosan.Esélyes, hogy egy atom processzoros SSD-s szerver zökkenőmentesen elvigye a mentést?
2014-01-12-09:24 #2207677Rakd a rendszert LVM-re es a menteskor csinalsz egy lvm snapshot-ot es arrol csinalsz mentes/dumpot.
2014-01-13-07:51 #2207678Köszi, de sajnos ez egy élesen futó rendszer, igen macerás lenne új alapra telepíteni.Másrész, ha jól tudom, mysql adatbázist nem lehet fájlszinten menteni, csak mysqldumppal, vagy replikálással.
2014-01-13-11:54 #2207679Szerintem meg nem.Csak a mostaniból kell LVM-et csinálni, persze lesz állás idő.Nem azt írtam, hogy a file szinten mentsd, hanem azt hogy csinálsz egy snapshot-ot és azon indítod el a mysql-t és onnan dump-olod ki az adatbázist.
2014-01-13-13:17 #2207680Hát, akkor én vagyok bizonyára eltévedve, de nálam a fájl szint azt jelenti, hogy a tárolt állomány. Teljesen mindegy, hogy a fájl rsync-kel másolom, vagy a teljes fájlrendszer image-ét másolom. A lényeg, hogy – tudtommal – a mysql nem garantálja, hogy konzisztens adatokat tárol mindig a fájlokban munka közben. Emiatt lehet ugyan, hogy néha sikerül így is adatbázis menteni, de nem garantált, hogy az így mentett adatbázis felállítva az eredetivel egyenértékű lesz.Gyanítom, a különbség csak írási művelet közben jelentkezik. Ha írás közben csinálsz lemezképet, akkor egy fél állapot lesz az adatbázisban. Nálam pedig szinte folyamatos az írás.Továbbá a lemezkép készítése gyanítom, elég sok erőforrást elvisz a replikáláshoz képes. Nem lehet vele folyamatosan, max pár perces lemaradású másolat adatbázist fenntartani.
2014-01-13-16:42 #2207681Mentés folyamat:- flush tables with read lock- snapshot készítés- unlock tables;- snapshot muont - mysql dump- snapshot deletHol lesz itt nem konzisztens adatbázis? ( Lehet neked van igazad .. 🙂 )
2014-01-13-19:55 #2207682Az irási inkonzisztencia megelőzésére tényleg jó módszer a táblák lezárása.Sajnos, az én esetemben, a folyamatos írás miatt ez nem lenne célszerű.Ráadásul azt is nehezen tudom elképzelni, hogy ezt a folyamatot 5 percenként ismételgessem.Azt hiszem, nálam a replikálás célszerűbb út, bár máshol, lehet, ez a jobb megoldás.
2014-01-14-09:41 #2207683Az első hsz-ben ez volt :”valósidejű mentést” Számomra nem arra utalt amit utolsó hsz-ben írtál: "olyamatot 5 percenként ismételgessem"Így tényleg a master-slave megoldás járható.
- SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz