Firebird távoli Shadow fájl használata

Firebird távoli Shadow fájl használata
2014-03-31T05:17:05+02:00
2014-04-05T02:40:34+02:00
2022-11-30T21:25:37+01:00
mandula
Az érdekelne, hogy használ valaki Firebird Shadow fájlokat?
Ezek aszinkron módon működnek?
Tehát lehet őket egyfajta one-way-synchron, azaz "folyamatos backup" -ra használni úgy, hogy NE fogja le a tranzakciókat, vagy ha a Shadow fájl egy lassú pendrájvon (vagy hálózati meghajtón) van, akkor lassulni fognak az Insert-ek ?

Naés honnan tudom, hogy mikor kell az eredetit törölnöm és ebből visszaállítanom?
Próbáltam Delphiben különböző ellenőrző ciklusokat írni, de nem egyszerű kideríteni, hogy csak valami csatlakozási hiba miatt, vagy VALÓBAN megsérült az adatbázis!
Köszönöm a válaszokat, fontos lenne pontosan tudni!
Mutasd a teljes hozzászólást!
Pont az a lényege, hogy nem aszinkron.

Az adatbázis állománnyal szinkronban(!) tartja a shadow állományt, de egy másik lemezen.

A tranzakcionalitás miatt be kell várniuk egymást, vagyis életveszélyes ha bizonytalan médiára teszi a shadow állományt az ember.
Ha jól emlékszem windowson nem is hagyja hálózati meghajtóra tenni, talán linuxon nfs-es drive-ra lehetséges.

Mindenesetre ha leakad az adatkapcsolat a shadow felé az adatbázis is megáll!

A RAID kiváltására alkalmas leginkább, annak logikája szerint gondolkodj. Egy sw raid-hez képest nem vesztesz semmi időt, de talán egy picit biztonságosabb (mármint mert nem fizikai szektorok, hanem logikai tranzakciókhoz tartozó lapok szinkronban tartása nagyobb konzisztencia szint).
Mutasd a teljes hozzászólást!

  • Szia!

    3.0-ás pendrive elég gyors szerintem, és amúgy én a te helyedben inkább úgy csinálnám, hogy 30percenként vagy pár óránként csinálnék szoftveresen egy egy backup-ot, nem szinkronizálnám folyamatosan, mert ugy egy rossz parancs onnan is törölhet mindent, és így ugyanakkora az esélye a backup sérülésére mint az adatbázisnak. Tehát backupok amiknek a neve egy-egy dátum :) nyilván az is fontos szempont, hogy milyen fontos információkat kell tárolni, és miért egy ilyen könnyen sérülő adatbázisban kell azt tárolni.

    David
    Mutasd a teljes hozzászólást!
  • Pont az a lényege, hogy nem aszinkron.

    Az adatbázis állománnyal szinkronban(!) tartja a shadow állományt, de egy másik lemezen.

    A tranzakcionalitás miatt be kell várniuk egymást, vagyis életveszélyes ha bizonytalan médiára teszi a shadow állományt az ember.
    Ha jól emlékszem windowson nem is hagyja hálózati meghajtóra tenni, talán linuxon nfs-es drive-ra lehetséges.

    Mindenesetre ha leakad az adatkapcsolat a shadow felé az adatbázis is megáll!

    A RAID kiváltására alkalmas leginkább, annak logikája szerint gondolkodj. Egy sw raid-hez képest nem vesztesz semmi időt, de talán egy picit biztonságosabb (mármint mert nem fizikai szektorok, hanem logikai tranzakciókhoz tartozó lapok szinkronban tartása nagyobb konzisztencia szint).
    Mutasd a teljes hozzászólást!
  • "miért egy ilyen könnyen sérülő adatbázisban kell azt tárolni"


    Ezt nem értem.
    Elmagyaráznád?

    Amennyire én tudom, korrekt hardveren, nincs adatvesztés, adatbázis összeomlás vagy ilyenek.

    Ahogy én tudom semmivel nem biztonságosabb vagy kockázatosabb akármelyik nagynevű adatbázis kezelőnél.

    De ha te tudsz valamit, oszd meg kérlek.
    Mutasd a teljes hozzászólást!
  • Kedves tuzvolte!
     Köszi a választ. ;)
    Úgy tudtam, a 3.0-ás pendrájvok csak a csatolófelület kompatibilitását jelentik, és semmi közük a beépített Flash RAM valódi írási sebességéhez. (Egy 2.0-as drive is képes elvileg 480MB-re, mégis a legtöbb csak max. 3-5Megával ír.)
    ... legalábbis ezen tesztek alapján.

    miért egy ilyen könnyen sérülő adatbázisban kell azt tárolni

    .. ezt én sem értem, miért írtad? Semmi baj az adatbázis motorral magával, csak hát áramszünetek azok vannak. Főleg vidéken, és a legtöbb embernek NEM telik szünetmentesre, de találkoztam már ócsányban vett akcióssal is, ami áramszünetkor azonnal kikapcsolt (1 hónaposan)!
    Tapasztalatom szerint olyan 100 alkalomból 1x valami gebasz szokott lenni a winyón.

    Ilyenkor a napi 1x-i "esti" mentés nem elég, mert senki sem emlékszik mondjuk délután 3-kor már, hogy mi volt az az 1000 tétel amiket felütöttek a nap folyamán.

    Amikor pedig félóránként volt beállítva, akkor szétterhelte a "szerver"-gépet és nem tudtak rajta normálisan tempósan dolgozni addig, amíg futott a 3-8 perces mentés. Úgyhogy 1 nap után kikapcsoltatták.
    Mutasd a teljes hozzászólást!
  • @emelhu

    Köszönöm szépen, erre voltam kíváncsi, és ettől tartottam.
    Kicsit reménykedtem benne, hogy van valami "kapcsoló", ami
    megjegyzi a "nem-shadow-zott" page-eket, és amikor van rá ideje, akkor megcsinálja.

    Elvégre nem kell a SELECT-ekre is használnia a Shadow-t, CSAK 1-1 véglegesen Commit-olt insert/update kerül bele. Nem?

    Sajnos elég nagy pörgés mellett használják a progit hálózatban, és kb. 150ms reakcióidő felett már erősen szidkozódnak az alkalmazottak, hogy LASSÚÚÚÚ. (Enter>enter>enter)

    Attól tartok, az egyetlen megoldás az ID alapján háttérben (külön Thread) történő folyamatos adatbázis-szinkronizáció lesz. (Ha egyszer elkészül)
    Mutasd a teljes hozzászólást!
  • "Elvégre nem kell a SELECT-ekre is használnia a Shadow-t, CSAK 1-1 véglegesen Commit-olt insert/update kerül bele. Nem?"


    Igen, az írási cache-t ágaztatja el többszörös írásra. [nem csak egy, akár több shadow adatbázis is lehet - ez a már kész megoldás jól jött az nbackup módszer megalkotásához - erről később]

    Mindenesetre olvastam egy esettanulmányt, ahol az OLTP szervert már nem tudták terhelni kemény lekérdezésekkel, ezért a shadow adatbázisokat (online, amíg a szerverhez volt kötve!) csatolták fel read-only adatbázisként és adtak ki rá nagy elemző lekérdezéseket.
    Arra nem emlékszem, hogy standard eszközöket használtak-e vagy valamilyen módosított szervert. De a téma érdekes.
    Mutasd a teljes hozzászólást!
  • "a "nem-shadow-zott" page-eket, és amikor van rá ideje, akkor megcsinálja."


    Ezt bizonyos mértékig megteszi az nbackup mentési stratégia.

    Ott tranzakció biztosan(!) csak a különbségeket mented.
    Érdemes utána nézni.
    Mutasd a teljes hozzászólást!
  • "csatolták fel read-only adatbázisként": mármint értsd, egy másik adatbáziskezelő motorhoz, gondolom nfs-en keresztül vagy valami spéci disk-tömbbel, ami képes erre.
    Mutasd a teljes hozzászólást!
  • Ezt bizonyos mértékig megteszi az nbackup mentési stratégia.

    Köszi a tippet!
    Igen, ez valóban jó alternatíva lenne, mert gondolom akár külső adathordozóra is képes menteni... csakhogy az én esetemben sajnos nem jó, mert megkövetelik, hogy a mentések kódolva legyenek. Ezért nem készíthetek az adatbázisról "sima" backupot, amit előtte nem encrypteltem és tömörítettem rögtön menet közben stream-ként.
    Ebben az esetben viszont nem hiszem, hogy az nbackup olyan egyszerűen használható, mint a gbak. (A GBAK-kal is marha nehéz volt megoldani.)
    De azért utánanézek...
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd