Commit a data bezpecne na disku?
Petr Novotny
Petr.Novotny na antek.cz
Pondělí Březen 27 14:39:49 CEST 2000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 27 Mar 00, at 14:33, Karel Zak wrote:
> Todle se, ale vetsinou neresi na urovni SQL. Pokud moc a moc chcete
> bezpecnost tak:
> - sahnete do kapsi pro nekolik milionu
> - koupite nejaky high available cluster
> - nasadite na raid pole
> - provozujete na robusni SQL s logy,
> - verite jen te DB a jejimu commitu a snazite se vynechat co
> nejvice OS v ceste SQL->disk - tedy raw device.
> - vedle toho stoji zdvojena UPS, zdvojeny technik oveseny
> certifikaty a zdvojena linka na support :-)
Tohle mam na SMTP i bez milionovych investic. K tomu celemu
staci jen jedno: Potvrdim, ze se o data staram, pouze pote, co se
fsync() uspesne vrati. Zvlada to i 486SX.
> IMHO SQL vam zajisti konzistenci databaze. Tedy spadle-li server a
> nekde na ceste jsou data, tak je dano ze tato data neohrozi ostatni
> data drive do DB ulozena. Todle by melo stacit.
A znovu: Mam zaruku, ze provedena operace je opravdu
provedena? Nebo to bude jako bych nahral tyden stary backup?
Pokud nema klient v nejakem okamziku jistotu, ze
data_jsou_v_databazi_dej_se_co_dej, nelze bezpecne prenaset
data. Pokud to klient nema ani jak zjistit (protoze, jak mi tu
naznacujete, ani COMMIT nestaci), pak je mi takova databaze
silne naprd. A nahanet osm chybejicich fsync() volani pomoci
milionove investice do hot-swap clusteru mi prijde rada, no,
zvlastni. Nemate nahodou procenta z prodeje? :-) :-)
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2 -- QDPGP 2.60
Comment: http://community.wow.net/grt/qdpgp.html
iQA/AwUBON9IhVMwP8g7qbw/EQLWnQCgzuyua/cDDPOO/+4oNwpBLHn0GOoAoK2t
RUF+68zfH8QrU4jTgN5CISD7
=dfb/
-----END PGP SIGNATURE-----
--
Petr Novotny, ANTEK CS
Petr.Novotny na antek.cz
http://www.antek.cz
PGP key ID: 0x3BA9BC3F
-- Don't you know there ain't no devil there's just God when he's drunk.
[Tom Waits]
Další informace o konferenci Databases