Üdv,
Olyan problémám lennem hogy Hyper-V-ben futtatott CentOS 7-en szeretném a MariaDB datadir-t egy cifs mount-ra rakni, viszont SELinux ezzel nem ért egyet, ezt egy custom policy-val bár megtudom oldani, de a mysql.sock-ot sem preferálja a rendszer cifs-en. Próbáltam my.cnf-ben átrakni mysql.sock-ot /tmp/mysql.sock-ra viszont mariadb restart után semmi errort nem dobott, se audit, se mariadb, viszont a fájl sem jött létre. Az egész lényege az lenne, hogy az egész datadir szinkronizálva legyen OneDrive-ra, így laptopról is elérhető lenne. Kérdésem az lenne, hogy van-e esetleg ennél jobb ötlet hordozhatóságra (végső esetben beállítok egy replicationt egy szerver géppel, csak jobb szeretném, ha minden egy helyen elérhető lenne cloudban), anélkül, hogy bármit manuálisan kéne mókolni minden változtatás után. Ha nincs, akkor esetleg van-e ötlet arra, hogy miért nem jön létre a socket fájl? Neten találtam, hogy a client-nél megadott socketet is át kell állítani, viszont ott nincs is megadva socket.
Előre is köszi :)
Hozzászólások
Klasszikus esete a F#>&-al történő csalánirtásra.
Csak mariadb jó? Vannak hordozhatóbb adatbázis kezelők is amiknél ez nem probléma.
Ha csak ez akkor mindenképpen a saját replikációs megoldását használd, ez a cifs-onedrive-datadir trió hátborzongató.
nem feltétlen csak mariadb jó, valójában én már nem is használom csak max ha kénytelen vagyok. hordozhatóság szempontjából amúgy melyik adatbázisok jobbak? saját dolgaimhoz pgsql-t használok jelenleg
Laptop-hoz miért nem írsz egy script-et, ami egy dump-ot csinál és lehúz SSH-n, majd betol neked a local db-be ha lefuttatod?
gondoltam rá, de akkor már replication kényelmesebb
pl SQLite. A lényeg, hogy "régi" módon a kódod az általa támogatott adatbázis fájlokat közvetlenül kezelje, szerver nélkül, így könnyebben tarthatod szinkronban de még az egyidejű használat is lehetséges lehet.
+1. Ha az ember egyutt tud elni a korlataival, akkor kivalo
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
Surgosen felejtsd el az otletet. A MySQL (es a MariaDB is) olyan, hogy nincs garancia a diszken tarolt adatok frissessegere es/vagy konzisztenciajara. A onedrive-s szinkronizalassal egy olyan fajlcsoportot szinkronizalnal, aminel komoly esely van arra, hogy hasznalni egyaltalan nem tudod, vagy outdated adatok lesznek benne.
Ket lehetoseged van:
- SSH-n keresztul atforwardolod magadnak a MySQL portot, es igy tudod hasznalni (ha nagyon muszaj)
- Napi rendszeresseggel keszitesz backupot, es amikor kell, az elozo napi backupot eloveszed.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:
Egyszerre a két gép nem lenne használva és a mysql szerver sem fut, a diszken mindig a legfrisebb változat lenne, de maradok replicationnél, vagy esetleg marad a kézi szinkron azokban a ritka esetekben amikor tényleg használom is
Még ha csak egyetlen gép használja is az adatfájlokat, akkor sem megfelelő a fájlszintű mentés, ha közben fut a MariaDB. Ha le van állítva, akkor készíthetsz róla fájlszintű másolatot, azt pedig már szinkronizálhatod felfele, mert az konzisztens lesz.
További lehetséges megoldás a megfelelően felparaméterezett mysqldumppal készített DB mentés létrehozása, aminek a kimenete például egyetlen .sql fájl, aminek a neve például tartalmazhatja a készítés időpontját is. Ez a fájl már szinkronizálható.
vagy hasznalhatsz xtrabackup / innobackupex -et, ami file szinten ment gyakorlatilag, es megis megy online adatbazissal
Nem a fajlszinten van a lenyeg. A lenyeg ott van, hogy az xtrabackup/innobackupex/mysqlhotcopy mind-mind flusholik es lockoljak a teljes szervert a masolas idejere ("FLUSH TABLES WITH READ LOCK") ezzel biztositva a fajlszintu konzisztenciat. A dropbox/icloud/skydrive erre keptelen, az mindig csak inkonzisztens fajlokat fog szinkronolni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:
btsync ?
nem is rossz ötlet.
:)
Jó eséllyel nem lesz konzisztens a DB, ha csak fájlszintű másolatot készítesz róla, miközben fut a MariaDB. Így tehát mindegy, milyen szoftverrel szikronizálsz.
Orosz rulettre még nem gondoltál? Esetleg dupla adag érlelt lóspermával?
ROTFL :-D
Ez nem teljesen igaz, mert jatszatsz az innodb_flush_log_at_trx_commit valtozo ertekevel, de teny, hogy akkor kinyirod a performanciat.
Meg sem emlitve azt a korulmenyt, hogy ez csak innodb tablak eseten segitseg, cserebe pl. a mysql adatbazis tablai nagyon nem ebben vannak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:
Ez nem teljesen igaz, mert jatszatsz az innodb_flush_log_at_trx_commit valtozo ertekevel, de teny, hogy akkor kinyirod a performanciat.
Igen, sajt- és másféle reszelővel is lehet, csak a dolog élvezeti értéke lesz vészesen alacsony :-P
Sikerült valami?
A szambára nem fogsz socketet pakolni, az egyszer biztos - olyat az a fájlrendszer nem tud. A /tmp vagy ram-ba kerül, vagy reboot során takarításra kerül - hagyományosan a reboot-ot túlélő átmeneti vackok a /var/tmp alá kerülnek, de a mariadb socket fájlja az ide sem való - /var/lib/mariadb/ könyvtár pédául teljesen jó neki.
A cifs sok dologra jó, de például i/o intenzív feladatokra (RDBMS alá) nem. És akkor sem, ha a konzisztencia (fájlok szintjén) kifejezetten követelmény (pl. RDBMS esetén). Felejtsd el a cifs-et erre a célra - a kiesés, illetve az elveszthető időszak alapján csinálj backup-ot (dump), utána meg ha szükséges, a tranzakciós logokat rakd el valahova (az már másolható cifs-re, ha nincs túl sok belőle), és ezeket is mentsd.