Sziasztok,
migráltam egy hőmérséklet mérő-megjelenítő-elemző rendszert raspberry pi-re. A hőmérséklet értékeket egy sh script kérdezi le, illetve menti el egy postgres adatbáziba. A történet nagyon szépen működik, viszont volt a napokban egy áramszünet, ami után a postgres nem indult el.A logba ez állt:
LOG: invalid magic number 0000 in log file 0, segment 0, offset 2
Az adatbázist csak egy pg_dropcluster, pg_createcluster utasítás után tudom elindítani, de ez természetesen magával ránt minden rá vonatkozó beállítást, táblát és adatot. Sajnos volt már ez előtt is áramszünet, ami nem tett kárt, ezért arra tudok gondolni, hogy épp az insert scriptek futása közben érhette utol, esetleg valami disk cache lehet.
Van ötletek, hogy tudnám a továbbiakban ezt megelőzni? postgres, vagy valami debian beállítás segíthetne?
Tudom, UPS lesz a vége, de valami kevésbé drasztikus megoldás létezik?
Köszönöm a válaszokat,
- 5749 megtekintés
Hozzászólások
Csinálj mentést a teljes adatbázis könyvtárról, aztán szerintem próbálkozz pg_resetxlog paranccsal.
- A hozzászóláshoz be kell jelentkezni
Jelenleg óránként csinálok egy dumpot, hogy ne legyen olyan fájdalmas egy esetleges összeomlás megint, de ez nem megoldás.
- A hozzászóláshoz be kell jelentkezni
A pg_resetxlog arra lett volna jó, hogy resetelte volna a write ahead logot (WAL) és akkor tudtad volna egy ki- és bedump után tovább használni az adatbázist a mentett adatokkal.
A még nem teljesen mentett tranzakciók a WAL fájlban vannak, amíg nem mentődnek az adattáblákba. Ennek az az értelme, hogy pl. áramszünet esetén is megmaradjon a mentett adatok integritása. Ilyen esetekben a WAL sérülhet, tehát helyre kell állítani.
Ha fontos, hogy a tranzakciók azonnal kiíródjanak, nem jó ha esetleg pár száz milliszekundumig a memóriában várakoznak, akkor synchronous_commit kapcsolót kell bekapcsolnod. Esetleg wal_sync_method kapcsolóval is próbálkozhatsz, de ezeknek utána kell olvasni. A PostgreSQL-nek teljesen érthető, áttekinthető doksija van.
Amúgy ha egy sima logfájlba írsz szöveges adatokat, az se kerül ki a diszkre, amíg az oprendszer úgy nem dönt, vagy nem hívsz egy fsync-et.
- A hozzászóláshoz be kell jelentkezni
pontosan ez kell nekem :)
köszönöm
- A hozzászóláshoz be kell jelentkezni
A postgres egy rpi-n szerintem elég örült dolog volt, főként hogy áramszünet érheti. Erre a célra inkább valami persistent db-t (sqlite, berkeley db) célszerűbb.
Ezeket erre találták ki, a postgres-t nem:)
// Happy debugging, suckers
#define true (rand() > 10)
- A hozzászóláshoz be kell jelentkezni
Valami szünetmentes megoldás kellene. Ezzel a problémával én is találkoztam már.
A rpi sem szeretni, ha elmegy alóla a delej. :)
Szerintem más megoldást nem nagyon fogsz találni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
vagy sqlite esetleg
- A hozzászóláshoz be kell jelentkezni
Van ötletek, hogy tudnám a továbbiakban ezt megelőzni?
Igen, van: roppant egyszerű.
A rendszert bontsd 3 műveletre:
- A mért adatok mentése.
- Az adatok betöltése.
- Az adatok megjelenítése.
Ebből az ismételhetetlen, ezért kulcsfontosságú az adatok mentése, amelyet a lehető legegyszerübben kell megoldani. Pl. text formátumban. Ha az adatok garantáltan diszken/memóriakártyán stb. vannak, akkor jöhet az áramszünet. Ennek előnyei:
- 2-3 nagyságrenddel gyorsabb.
- 10x kevesebb helyet igényel.
- Hiba esetén könnyen javítható.
- A rendszer további elemei tetszőlegesen választhatók és cserélhetők.
- A második művelettől tetszés szerint ismételhető.
- A hozzászóláshoz be kell jelentkezni
Én mostanság csináltam egy ilyesféle UPS-szerűséget, bár nem kifejezetten a Pi-hez. :)
Jelen állapotában a Pi + billentyűzet és pár alap dolog egy kisebb mobiltelefon aksival, alaprendszerrel, üresjáratban olyan másfél órát megy róla - tápról tölteni is tud.
Az a baj, hogy váratlan leállás esetén könnyen összeszedhető fájlrendszersérülés - ha nem csak olvashatóként használja az ember...
- A hozzászóláshoz be kell jelentkezni