Distribuovana databaza - projekt

[materik]

Mam spravit do skoly jeden projekt a potreboval by som par rad, comu sa vyhnut, na co mysliet a hlavne co nerobit opat, ak uz
to je niekde hotove

Ide o distribuovanu databazu pri ktorej mame osetrit padnutie spojenia. Mam dve identicke databazy, kde zapis do jednej
vyvola zapis dat do druhej a naopak. Obsah data ako taky nie je podstatny.
Takto by to malo vyzerat v idealnom pripade.

To pingovanie by sme tam mali namontovat a v pripade fail-u osetrit poziadavky na databazu.

Cize ked dojde k niecomu ako toto

musime zabezpecit, aby nedochadzalo k problemom s konzistentnostov dat.

Ja som zatial zanalyzoval niekolko moznosti a problemov:
- ak vypadne spojenie a dojde k zapisu do jednej databazy, zapisane data musim nalezite oznacit, pripadne niekde odsunut kopiu
ktora caka na obnovu spojenia a na nasledny zapis.
- rezerva klucov. Teda ak by nebolo spojenie a doslo by k zapisom na oboch stranach, aby sa po obnoveni spojenia nestrieskali duplicitne primarne kluce. Kvoli tomu ten ping: pingcheck() = fail => reserve keys. Zatial ma napadlo pridat ku klucu timestamp aby sa to dalo nasledovne upravit podla poradia?? (mozno zbytocnost)
- rezerva dat. Ak by doslo k nejakej manipulacii na oboch stranach pocas vypadku (napr. znizenie poctu tovaru alebo hoci co) tak aby som po obnove spojenia nezistil, ze na dvoch stranach doslo k objednavke a ja teraz nemam matros kery by som poslal, alebo nieco take. Tu ma napadla tiez len rezerva, ze pri vypadku spojenia obmedzit niektore manipulacie s datami.

Platforma je na mne, ja by som to primarne riesil v C# a s vyuzitim Visual Studia a nalezitych doplnkov. Databaza, najskor SQL.
Mate niekto nejake pripomienky, navrhy? S databazami som robil zatial dost lightovo, takze to je pre mna dost vela vyzva

[galen]

napadlo ma ...
co takto spravit major/minor spravanie,
kde minor si pamata posledny "ping" a vsetky transakcie po nom vykonane (add/remove/update) loguje do trans. logu (a samozrejme vykonava)

po obnove spojenia zaplikovat zmeny v trans. logu minorDB na majorDB a nasledne spravit mirror majorDB do minorDB
(ci uz kompletny, alebo iba na zaklade trans. logov, to uz je druha vec)

[materik]

no, tak ci som to dobre pochopil:
vsetky zmeny idu prvotne do minorDB, overi sa spojenie a ak je v poriadku, tak zapis do majorDB
ak nemam spojenie, vsetko do minorDB/log (tu som si nie celkom isty ci ta chapem), po obnove spojenia si porovnam logy
dostanem vysledky a nasledne robim commit do majorDB.

Inac, to vyzera byt dost elegantne riesenie

[galen]

no ehm ...

v dobe spojenia:
MajorDB funguje normalne, plus zasiela transakcie/info o nich do MinorDB
MinorDB ... by teoreticky nemala robit ziadne zaznamy, bez toho,a by ich prikazal MajorDB,
tzn akekolvek poziadavky na CRUD (create/remove/update/delete) najprv zasle MajorDB, a az ked ich ona sprocesuje/potvrdi, az potom (vzhladom na fungovanie MajorDB a potvrdzovanie transakcii) ich vykona aj MinorDB

v pripade rozpadu:
MajorDB a MinorDB funguju autonomne - kazda si robi co ma, a loguje vsetky transakcie

po obnoveni spojenia:
MinorDB spravi rollback (podla trans. logu) na stav pred rozpadom
MajorDB naposiela svoj trans. log MinorDB (ten ho zaplikuje - dostane sa na uroven MajorDB)
MinorDB naposiela transakcie z doby vypadku MajorDB, a nasledne zaplikuje jednotlive transakcie, ked ich vykona MajorDB

... treba sa este zamysliet nad uskaliami jednotlivych stavov, a mozno ich trosku dopilovat ... ale v principe by to malo fungovat
kedtak skus strycka gugla a tetu wiki, co ti povie o "database mirroring"

[pEpinko]

No neviem, mne to galenovo riesenie neprijde zrovna ako distribuovana databaza, ale mozno som to nepochopil, podla mna -

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

[materik]

no, ked som na to pozrel podrobnejsie a hlavne som si to nakreslil, tak mi to tiez az nejak extra nesedi

totiz, mne nejde o back-up ale o prepojenie dvoch rovnocennych databaz. Tie db ktore som hodil na obrazkoch
su rovnocenne, a moze sa stat, ze v rovnakom case sa zapisu na oboch uzloch rozne data. Ale predsa len ma z galenovho
navrhu par veci inspirovalo, ale musim si to este prebrat s cviciacim...

[galen]

no, databazy nidky nemozu byt rovnocenne,
pretoze ak nahodou dojde k handlovaniu tych istych dat v ten isty moment, tak dojde k nekonzistencii

predstav si sklad-skladove hospodarstvo:
mas na sklade 1 knihu
v kazdej DB v ten isty moment dojde poziadavka
-> predaj knihu (alebo vyskladni) zakaznikovi A (1. DB)
-> predaj knihu (alebo vyskladni) zakaznikovi B (2. DB)

otazka znie:
kto dostane knihu - zakaznik A, alebo zakaznik B?

[materik]

...

to mi je jasne, to som spominal uz aj v prvom prispevku. Ale tu ma zatial nenapadlo nejake schopne riesenie tohto problemu.
Ostatne veci si viem predstavit ako ich riesit. Zajtra sa snad dozviem viac ohladom zadania a poziadaviek.

[pEpinko]

no, databazy nidky nemozu byt rovnocenne,
pretoze ak nahodou dojde k handlovaniu tych istych dat v ten isty moment, tak dojde k nekonzistencii

predstav si sklad-skladove hospodarstvo:
mas na sklade 1 knihu
v kazdej DB v ten isty moment dojde poziadavka
-> predaj knihu (alebo vyskladni) zakaznikovi A (1. DB)
-> predaj knihu (alebo vyskladni) zakaznikovi B (2. DB)

otazka znie:
kto dostane knihu - zakaznik A, alebo zakaznik B?

Ale toto sa v distribuovanych databazach bezne riesi. Ked sa nejaka transakcia vykonava na jednom uzle, tak ak chce commit, tak sa musi poradit s ostatnymi uzlami, nato su tie vsetky dvoj-, troj- fazove commity.

[galen]

Ale toto sa v distribuovanych databazach bezne riesi. Ked sa nejaka transakcia vykonava na jednom uzle, tak ak chce commit, tak sa musi poradit s ostatnymi uzlami, nato su tie vsetky dvoj-, troj- fazove commity.

ano, isteze

ale nieje to na urovni, ze su si databazy rovnocenne, v dany moment jedna databaza podlieha autorizaciam ostatnych databaz, takze v pripade CRUD operacii sa sprava ako minor
to ze sa tak spravaju vsetky voci ostatnym, je druha vec ... v momente operacie je minoritna ta, ktora chce nieco menit

[Scorp]

a bavíte sa o čisto distribuovanej db...? Lebo tam moc replikáciu dát riešiť nemusíš a máš špatný návrh, alebo názov .))

[materik]

takto, mam to na hodine Pocitacove site a distribuovane systemy.
Mojim zadanim je spravit commit do dvoch databaz s tym, ze ak nemam spojenie, tak sa vsetky zmeny udeju po obnoveni spojenia.
Je tam viacero verzii, ja mam zabezpecit, ze hned ako budem mat spojenie, tak mam commitovat logovane zmeny. Pri inych zadaniach
to staci overit pri commitovani, ci su nejake zmeny v logu.

[Scorp]

možno to bude ale špatne, ja som moc v škole pozor nedával .)
môžeš robiť master/slave, jak popisoval galen, v praxi sa potom napr. zapisuje na mastera a ready idú zo slejvov, je to rýchle, všetci sú happy, no science

alebo urobíš masterom každého a potom musíš riešiť konflikty, buď vymyslíš science a ošéfuješ si to pred commitom, alebo to vezmeš na vidláka, veselo všetko commituješ a robíš nejaké light synchro podľa timestampov
tu sa ale môžeš oj*bať na tom, že ak do toho zapichneš nejaký pomalý stroj, bude brzdiť ostatné... čo by sa ti pri distribuovanej db nemalo stať .)