Ü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 :)
- 4151 megtekintés
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ó.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
gondoltam rá, de akkor már replication kényelmesebb
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+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)
- A hozzászóláshoz be kell jelentkezni
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:
()=()
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
vagy hasznalhatsz xtrabackup / innobackupex -et, ami file szinten ment gyakorlatilag, es megis megy online adatbazissal
- A hozzászóláshoz be kell jelentkezni
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:
()=()
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()
- A hozzászóláshoz be kell jelentkezni
btsync ?
- A hozzászóláshoz be kell jelentkezni
nem is rossz ötlet.
- A hozzászóláshoz be kell jelentkezni
:)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Orosz rulettre még nem gondoltál? Esetleg dupla adag érlelt lóspermával?
- A hozzászóláshoz be kell jelentkezni
ROTFL :-D
- A hozzászóláshoz be kell jelentkezni
Ez nem teljesen igaz, mert jatszatsz az innodb_flush_log_at_trx_commit valtozo ertekevel, de teny, hogy akkor kinyirod a performanciat.
- A hozzászóláshoz be kell jelentkezni
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:
()=()
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()
- A hozzászóláshoz be kell jelentkezni
Ez nem teljesen igaz, mert jatszatsz az innodb_flush_log_at_trx_commit valtozo ertekevel, de teny, hogy akkor kinyirod a performanciat.
- A hozzászóláshoz be kell jelentkezni
Igen, sajt- és másféle reszelővel is lehet, csak a dolog élvezeti értéke lesz vészesen alacsony :-P
- A hozzászóláshoz be kell jelentkezni
Sikerült valami?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni