Hasonló témájú kérdés már korábban is felmerült, mindíg az az első viszontkérdés, hogy mekkora várható adatmennyiség, milyen elosztásban (táblák, stb), ill a lekérdezés gyakorisága és összetettsége.
Mintha a PostgreSQL is fejlésztése is bizonytalanná vált, a MySQL körüli bonyodalom az jóval közismertebb. (Sun / Oracle)
A MySQL úgy működik, hogy az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe. Ezen felül a programnak, amit futtatsz, replikáció-kompatibilisnek kell lennie (nem lehet két NOW() egy queryben, etc etc). A szoftvernek ezen felül tudnia kell azt, hogy az olvasó queryket nem a masternek küldi.
Multimasterre majdnem ugyanez igaz annyi adalékkal, hogy egyesek szerint az még kevésbé stabil. Én használom gond nélkül. Az biztos, hogy monitoroznod kell a slave lagot és ha fölmegy, akkor cselekedni. A rendszeres backup melegen ajánlott.
Nem ismerem a PostGreSQL-t, de ha ezek kizáró tényezők, akkor a MySQL nem a Te célszoftvered.
az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe.
Hat, a mysql replikacio ennel azert egyszerubb. Nem kell semmit sem RO lockolnod, csak arra figyelni, hogy minden 'iras' a masteren tortenjen, es a replikacio szepen szetteriti a modositasokat a slave-ekre.
SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta
Ha innodb tablaid vannak, akkor ha xtrabackupot hasznalsz, ez nem kell. Ha az innobackupex-et --slave-info-val hivod, akkor a mentesedben benne lesz az a binlog pozicio, amire slave-et allitanod kell utana. A xtrabackup csak io szempontbol lehet intruziv a db-re nezve, ezt pedig tudod kezelni a beepitett io throttling-gal, vagy ionice-szal.
Valami olyasmiben gondolkoznék, ami elvan monitorozás nélkül is. Szóval ha kiesik az egyik, akkor közbeavatkozás nélkül mehessen napokig még amíg pótlom.
2 résztvevős megoldás lenne a lényeg, nincs kapacitás extra gépre.
Az ilyesmiért sajna fizetni szoktak :(
A Pg-t probáltuk sokszor szétesett, egy jó sqlserver de localon egy másik db elérése is kinszenvedés.
Ha 4GB bele férsz megnézhetett az mssql-t a 2005-től benne a replikáció esetleg linuxra sybase vagy oracle ingyenes verziója (ha tudja), lehet hogy rosszul láttom de ha már ilyen igényeid vannak az "magasabb" kategoria vagy leprogramozod aszerveren (linked server, trigger, log ship..)
választhatsz hogy fizetsz a kész technikáért vagy le programozod, "a db-d ill a tudásod méretétől függ" mindenkép "fizetsz" érte.
Jól követjeztettél 6 sör után írtam :DDD
A 2005 -től telepíthető és müködik is az ingyenesen is.
A többi nagy tesót ingyensét nem ismerem (ora, db2, sybase)
Ez ugy erdekelne. Miert nem lehet 2 now() egy query- ben? Illetve, mit jelent itt az etc, milyen kizaro okok vannak meg, mit jelent az a gyakorlatban, hogy replikacio- kompatibilis?
A MySQL doksiban azt olvastam bő egy éve, hogy a queryk bináris formában timestamppel együtt kerülnek a slavere. Mivel a query futása nem atomi, a két now kiértékelése más eredményt fog adni és ez a differencia a slaven nem lesz ugyanaz.
Ne vedd biztosra, inkább keress rá "replication safety" címszó alatt. (Sajnos telóról vagyok, nem tudom kikeresni.)
mert a két now kiértékelése közben eltelik némi idő, illetve a két gépen eltérhet a rendszeridő, így két, párhuzamosan beszúrt rekord a két gépen jelentősen eltérhet.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Eddigi tapasztalat:
- a postgrest nem lehet rendesen replikálni
- a mysql meg nem adatbáziskezelő:)
ezt nézegesd: http://ha-jdbc.sourceforge.net/ a végén vannak linkek, pgcluster, és különösen a belőle származtatott cybercluster felejtős. a sequoia-t kipróbálhatnád helyettem:)
A ha-jdbc-vel annyi a tapasztalatom, hogy amikor indult a thread, beírtam a guglinak a témát és kidobta:) most láttam először. Azért másoltam be, mert a végén ott van a lista általam korábban ismert cuccokról.
Amikor utoljára néztem (idén év elején) még nem volt 8.4-es postgres. Reménykedem benne, hogyha a pgcluster nem outsider projekt lesz, hanem rendesen integrálják végre a pgsql-be (a 8.4 egyik fő fejlesztési kérdése), akkor működni fog rendesen. A pgcluster egyébként jobban működött, mint a cybercluster, de az sem volt teljesen rendben.
Mi pont HA-JDBC-vel játsszunk, a következőket tudja. JDBC driver-rel elosztottan írsz n darab
adatbázist, ami elérhető. Ha egy node elszáll, és újra életre kell, akkor megírhatsz egy
merge-ert, ami szépen áthúzza az élő adatbázis(ok)ról az adatot az új node-ra.
Nekünk viszont egy másik esetben arra volt szükségünk, hogy minden adatbázisban ugyanaz legyen,
erre meg a java tranzakciós api nyújtott megoldást.
Tanulság: redundanciára érdemesebb előbb gondolni, és nem utólag behúzni, mert elég nagy
szívás :D
privát szubjektív magánvéleményem, hogy a java adatbáziskezelésétől sírhatnékom van. és vannak benne olyan eszközök (jpa?) amit mintha direkt úgy terveztek volna, hogy szivassa az adatbázisokat, pláne a clustereket.
érdekelne, hogy serialt meg now()-t meg ilyeneket hogy írsz elosztottan ha-jdbc-vel?
ehhez kellene minőségi jdbc driver is... ami pl. pont postgres esetén nem nagyon van meg. (pl. nem minden jdbc függvényt implementál, ettől telerakja a logot...)
Jaja, tényleg ott van, csak egy rendesebb adatbázistól úgy összefossa magát, mint az atom.
Márha a cyberclusterre gondoltál. A tárolt eljárások, a random, a serial, meg egy-két hasonló dologtól simán előfordul, hogy az adatbázis másolatai nem másolatok.
A doksiban leírnak minden szépet és jót, aminek a fele is csak feltételekkel igaz. Tapasztalat.
A cyberclustert nem érdemes használni. Forrás: a cyberclustert gyártó cég vezetője. Kifizettünk egy éves supportot, és megkaptuk a jótanácsot.
Én Slony-val replikálok Postgres-t, az előző 3 év alatt mondjuk 4-5x volt olyan, hogy elvesztette a szinkront. Ilyenkor egy újraszinkronizálás úgy 20-30 perc félmillió rekordra. MySQL-nél a master-slave megoldásnál (binlog) érdemes maradni, a master-master megoldást ugyan használjuk, de nem jó eddig vele a tapasztalat, néha nagyon sokáig (értsd: akár órás időtartam) eltérő volt a két gép tartalma.
Igen, Slony-I tényleg megér egy próbát, ha a triggerek miatti limitálás neked nem gond, akkor ez egy elég kiforrott és hivatalosan támogatott - minden külsős megoldás baja az, hogy bizonytalan mértékben késik a támogatás, tehát ős-postgresql-t kell használj esetleg miatta és fél élet munkája felreszelgetni - a frissítésről meg ne is beszéljünk.
Nekem sajnos slony-I nem volt elég és akkor jött az, amit írtam alább.
Azt ajanlanam amelyikhez ertesz vagy amelyikhez van penzed supportot megfizetni, egyik esetben sem pedig azt amelyiket meg akarod tanulni :)
- Oracle draga es brutalis kepessegei vannak, valoszinuleg oda ahova eleg mysql vagy postgress, felesleges.
- mysql problemas lehet a jovoben a sun+oracle+mysql dolog miatt, fene tudja mi lesz (ertem itt ha vallalatot akarsz ra epiteni)
- postgress-t kicsitsem ismerem.
Talan mysql-t javasolnam, mivel konyen tanulhato, konnyeden kapsz hozza supportot akar itt is. Vannak eleg komoly kiegeszitesek hozza (mmm HA-nak vagy epp infobright engine olap es dataminingra ).
Gyakorlatilag ha tudod mit nem szabad (pl ahogy emlitettek elottem a 2 now() 1 queryben) akkor gond nelkul fog szolgalni teged. Errol van egy jo kis leiras itt xaprb. Ott van meg mysql-hez a maatkit, ha inkonzisztencia vagy performance elemzes gondok merulnek fel.
Csak rajtad all, mindenki azt ajanlja amihez a sajat szive kozelebb huzza imho.
MySQL -el ahogy mar irtak a "tukrozest" 2 fele kep tudod megoldani:
master-slave: Ezesetben csak az egyik irhato (master) es a slave-en minden adat meglesz. "Akarmennyi" slave-ed lehet.
master-master: ezesetben mind2 irhato viszont erosen experimental, hogy konzisztens maradj.
Az ilyen kérdések mindig megindítanak végtelen hitvitákat, nekem X szar, nekem meg Y fagyott és nincs, aki igazságot tegyen.
Ezért ebben nem tudok neked úgysem okosat mondani, mindig lesz rá ellenvélemény, leszólás, hülyevagyöcsém, stb.
Ha a postgresql mellett döntesz, akkor egy kis segítség:
Egy évvel ezelőtt szenvedtem postgresql + pgcluster bereszelésével, akkor született egy kis javítócsomag, amivel ürrepülő vizsga nélkül fel lehet telepíteni az egész motyót és még működik is:
FreeBSD 6.3 amd64: http://zl.hu/upload/pgcluster/pgclusterz_20080916_0.tgz
FreeBSD 7.0 kiegészítések: http://pgcluster.zl.hu/
Ezekben benne van pár napnyi munka (igazából csak "reszelés" és kísérletezés, debuggolás, tehát semmi nagy durranás kód).
Ez a megoldás ment 6 hónapot, ezalatt produkált összesen egy "befagyást" egy halálra triggerezett rendszerben, tehát akár stabil is lehet egy egyszerűbb szituációban.
akkor módosítom a kérdést:
van valakinek működő 2 gépes klasztere pgsql v mysql alapokon, ami ha elszáll az egyik, akkor rögtön használható lesz a másik(lehet master-slave, de a slave ne legyen read only master kieséskor)?
Ha hajlandó vagy úgy megírni az alkalmazást, hogy tekintettel legyen arra, hogy mit nem tud a cluster szoftver, akkor pgclusterrel lehet eredményt elérni.
mysql-hez minek drbd? Siman elmegy a master-slave is, nalunk cegnel jo par eve mukodik a 4.1-es igy. Ha kiesne a master, a slave rogton hasznalhato lenne, csak lustak vagyunk ra script-et irni.
Mar tobben irtak ezt a now() dolgot. Mi tortenik akkor, ha a slave eltunik egy orara egy master slave felallasban, es mondjuk az eltunese felenel jon egy query, ami leirja, hogy update valami set datum = now(). Mi tortenik, ha 30 perc mulva felebred a slave? Mit fog kapni a mastertol, es mit kezd vele, illetve O mit ir le? Mondjuk 12.00- kor tunt el, 12.30- kor jott a query, es 13.00- kor kelt fel.
en ugy tudom, hogy nincs semmi baj a now()-val, binlogba mar a master oraja szerinti ertek kerul behelyettesitesre.
szoval a now() replication safe, de a sysdate-rol tudom hogy nem az. http://dev.mysql.com/doc/refman/5.1/en/replication-features-functions.h…
Unlike NOW(), the SYSDATE() function is not replication-safe because it is not affected by SET TIMESTAMP statements in the binary log and is nondeterministic if statement-based logging is used. This is not a problem if row-based logging is used. Another option is to start the server with the --sysdate-is-now option to cause SYSDATE() to be an alias for NOW().
ettol fuggetlenul meg van egy csomo dolog, amire figyelni kell:
pl. ha olyan modosito query-t futtatsz, ami limitet hasznal, akkor feltetlenul legyen valami kulcs szerint rendezve a query, mert a default rendezes az nem replication safe.
postgresnél azt sem mindig veszi észre a pgcluster meg a cybercluster, hogy tárolt procedúra van a selectben, ami esetleg update-t vagy insertet is végrehajthat,
azt sem mindig veszi észre, hogy a now()-t meg a random()-ot nem ártana egy clustertagon végrehajtani és behelyettesíteni az eredményét, meg voltak még ilyen szívásaim...
Ha "row-based logging"-ot hasznal csak az emeber akkor annak mi a hatranya ?
Gondolom nagyobb az adat forgalom a mastar-slave kozott. drdb -tol az altalaban kisebb -e ?
szerk:
Ha a ket szerver idozonaja ugyanaz, es mixed modot hasznal az ember, akkor milyen hatranyal kell szembeneznie ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
A row es statement based replikacio kozti alapveto kulonbseget azzal erzekeltetnem, hogy mondjuk update-elsz egy tablat.
legyen a parancs update mytable set some_column = NULL where id < 100;
A statement based ahogy a neve is sugalja, ezt a statementet kuldi le a slave-re. 1 sor, 1 query viszont feltetelezi hogy eggyeznek a tablaid.
A row based eseten, az osszes sorra ahol a fenti update matchelt, bekerul 1db query a binlogba es pl ugy fog kinezni hogy
update mytable set some_column = NULL where id = 1
update mytable set some_column = NULL where id = 2
update mytable set some_column = NULL where id = 3
etc..
A teljesseg igenye nelkul csak az erzekeltetes kedveert.
Elvileg a mixed ilyen esetekben automatikusan atvalt row based-re.
A row based alapvetoen azert gond, mert sokkal tobb dolga lesz a single-thread replikacionak.
DRBD teljesen mas szinten mukodik. Block device szinten replikalja egy adott particio torteneseit es effektiv nem erdekli hogy milyen alkalmazas fut felette.
A hagyomanyos dbms-ekkel szopni fogsz. Egyszeruen mindegyiket egy gepes mukodesre terveztek, a replikacio vagy akar alapszintu cluster-es feature-ok csak utolag lettek belehackelve (BTW, ez az oracle-re is igaz!).
Ha tenyleg fontos a kozel linearis skalazodas, az elosztottsag, akkor nezd meg a hadoop/hbase-t. Nem SQL ugyan, de nem is feltetlen baj. Ellenben masszivan elosztott mukodesre terveztek. Ha mond valamit a bigtable szo, akkor tudod, mi ez.
Hozzászólások
Valami tapasztalat? :)
Szervusz !
Hasonló témájú kérdés már korábban is felmerült, mindíg az az első viszontkérdés, hogy mekkora várható adatmennyiség, milyen elosztásban (táblák, stb), ill a lekérdezés gyakorisága és összetettsége.
Mintha a PostgreSQL is fejlésztése is bizonytalanná vált, a MySQL körüli bonyodalom az jóval közismertebb. (Sun / Oracle)
Te melyiked ismered jobban?
CSZ
2-3Gb, 60-90 tábla, 20k sor átlagosan
MySql-t használok, de PG-re elég sok jót hallottam, gondoltam rákérdezek :)
ezt egy textfile elviszi.. :)
ha csinálsz benne 7-9 táblás joint ;)
2-3G-s text fájlban gyorsan lehet keresni :)
--
http://laszlo.co.hu/
eleg mindent csak 1x megkeresni, aztan mar tudod...
SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta
Belegondoltam, milyen lenne már videokártyán futó sql szervert faragni... adatkockákat rakni rá, managgáknak adatbányászkodni....
A MySQL úgy működik, hogy az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe. Ezen felül a programnak, amit futtatsz, replikáció-kompatibilisnek kell lennie (nem lehet két NOW() egy queryben, etc etc). A szoftvernek ezen felül tudnia kell azt, hogy az olvasó queryket nem a masternek küldi.
Multimasterre majdnem ugyanez igaz annyi adalékkal, hogy egyesek szerint az még kevésbé stabil. Én használom gond nélkül. Az biztos, hogy monitoroznod kell a slave lagot és ha fölmegy, akkor cselekedni. A rendszeres backup melegen ajánlott.
Nem ismerem a PostGreSQL-t, de ha ezek kizáró tényezők, akkor a MySQL nem a Te célszoftvered.
az egész master adatbázist read onlyra kell lockolnod (vagy LVM snapshotot készítened), ezután jöhet a dump és a master adatok mentése, amit be kell tápolni a slavebe.
Hat, a mysql replikacio ennel azert egyszerubb. Nem kell semmit sem RO lockolnod, csak arra figyelni, hogy minden 'iras' a masteren tortenjen, es a replikacio szepen szetteriti a modositasokat a slave-ekre.
SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta
Sajnos a replika építésnél kell az, hogy addig ne írjon bele senki.
5.1-től asszem elég a binlogot másolni.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Fantasztikus. Talán egyszer eljutnak oda is, hogy protokol szinten meg tudják oldani és nem kell kézzel szórakozni.
Ha innodb tablaid vannak, akkor ha xtrabackupot hasznalsz, ez nem kell. Ha az innobackupex-et --slave-info-val hivod, akkor a mentesedben benne lesz az a binlog pozicio, amire slave-et allitanod kell utana. A xtrabackup csak io szempontbol lehet intruziv a db-re nezve, ezt pedig tudod kezelni a beepitett io throttling-gal, vagy ionice-szal.
Valami olyasmiben gondolkoznék, ami elvan monitorozás nélkül is. Szóval ha kiesik az egyik, akkor közbeavatkozás nélkül mehessen napokig még amíg pótlom.
2 résztvevős megoldás lenne a lényeg, nincs kapacitás extra gépre.
Az ilyesmiért sajna fizetni szoktak :(
A Pg-t probáltuk sokszor szétesett, egy jó sqlserver de localon egy másik db elérése is kinszenvedés.
Ha 4GB bele férsz megnézhetett az mssql-t a 2005-től benne a replikáció esetleg linuxra sybase vagy oracle ingyenes verziója (ha tudja), lehet hogy rosszul láttom de ha már ilyen igényeid vannak az "magasabb" kategoria vagy leprogramozod aszerveren (linked server, trigger, log ship..)
választhatsz hogy fizetsz a kész technikáért vagy le programozod, "a db-d ill a tudásod méretétől függ" mindenkép "fizetsz" érte.
ms sql tudja, most azon van, de máshol is kellene telepíteni, ahol nem lenne keret a licenszre :(
Ő az ingyenes, express verziót javasolta (a 4G korlátból következtettem ki).
_Szerintem_ a korlátozott verziók nem tudják ezt. Oracle XE sem.
G
Jól követjeztettél 6 sör után írtam :DDD
A 2005 -től telepíthető és müködik is az ingyenesen is.
A többi nagy tesót ingyensét nem ismerem (ora, db2, sybase)
Ez ugy erdekelne. Miert nem lehet 2 now() egy query- ben? Illetve, mit jelent itt az etc, milyen kizaro okok vannak meg, mit jelent az a gyakorlatban, hogy replikacio- kompatibilis?
Koszi.
A MySQL doksiban azt olvastam bő egy éve, hogy a queryk bináris formában timestamppel együtt kerülnek a slavere. Mivel a query futása nem atomi, a két now kiértékelése más eredményt fog adni és ez a differencia a slaven nem lesz ugyanaz.
Ne vedd biztosra, inkább keress rá "replication safety" címszó alatt. (Sajnos telóról vagyok, nem tudom kikeresni.)
Huh, ez igy erdekes. Ez bug, vagy feature? :- ). Ha bug, nem akarjak megfixalni? A legujabb (dev) verzioban is igy van?
mert a két now kiértékelése közben eltelik némi idő, illetve a két gépen eltérhet a rendszeridő, így két, párhuzamosan beszúrt rekord a két gépen jelentősen eltérhet.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
postgres replikációknál meg a random függvény lesz túl random...
Szerintem a NOW() nem jelent problémát. A SYSDATE() már igen.
Eddigi tapasztalat:
- a postgrest nem lehet rendesen replikálni
- a mysql meg nem adatbáziskezelő:)
ezt nézegesd: http://ha-jdbc.sourceforge.net/ a végén vannak linkek, pgcluster, és különösen a belőle származtatott cybercluster felejtős. a sequoia-t kipróbálhatnád helyettem:)
Van vagy 6 replikációs program Postgre-hez.. elég kicsi az esélye annak amit írtál:
> a postgrest nem lehet rendesen replikálni
A HA-jdbc-vel mik a tapasztalataid?
A postgreshez a slony-t nézd meg, még nem próbáltam.
http://slony1.projects.postgresql.org/slony1-1.2.6/doc/adminguide/slony…
Ezt találtam, elég korrekt leírásnak tűnik:
http://www.postgresql.org/docs/8.4/interactive/high-availability.html
A ha-jdbc-vel annyi a tapasztalatom, hogy amikor indult a thread, beírtam a guglinak a témát és kidobta:) most láttam először. Azért másoltam be, mert a végén ott van a lista általam korábban ismert cuccokról.
Amikor utoljára néztem (idén év elején) még nem volt 8.4-es postgres. Reménykedem benne, hogyha a pgcluster nem outsider projekt lesz, hanem rendesen integrálják végre a pgsql-be (a 8.4 egyik fő fejlesztési kérdése), akkor működni fog rendesen. A pgcluster egyébként jobban működött, mint a cybercluster, de az sem volt teljesen rendben.
Mi pont HA-JDBC-vel játsszunk, a következőket tudja. JDBC driver-rel elosztottan írsz n darab
adatbázist, ami elérhető. Ha egy node elszáll, és újra életre kell, akkor megírhatsz egy
merge-ert, ami szépen áthúzza az élő adatbázis(ok)ról az adatot az új node-ra.
Nekünk viszont egy másik esetben arra volt szükségünk, hogy minden adatbázisban ugyanaz legyen,
erre meg a java tranzakciós api nyújtott megoldást.
Tanulság: redundanciára érdemesebb előbb gondolni, és nem utólag behúzni, mert elég nagy
szívás :D
privát szubjektív magánvéleményem, hogy a java adatbáziskezelésétől sírhatnékom van. és vannak benne olyan eszközök (jpa?) amit mintha direkt úgy terveztek volna, hogy szivassa az adatbázisokat, pláne a clustereket.
érdekelne, hogy serialt meg now()-t meg ilyeneket hogy írsz elosztottan ha-jdbc-vel?
Pedig elég korrekt a java adatbázis kezelése (jdbc). A jpa más szinten dolgozik..
ehhez kellene minőségi jdbc driver is... ami pl. pont postgres esetén nem nagyon van meg. (pl. nem minden jdbc függvényt implementál, ettől telerakja a logot...)
rossz helyre ment bocs
- postgrest lehet rendesen, csak google a barátod.
- az oracle, na AZ nem adatbáziskezelő. az egy kalap fos, kib@szott drágáért.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
ez mar megint ilyen log a levegobe dolog, konkretumok nelkul. enis tudok bofogni...
szoktál is :)
mert nincs kedvem kisregenyt irni altalaban :) ellenben mindig alatudom tamasztani a velemenyem.
postgresql.at ott van neked kello szinkronizacios szolucio postgreshez. nem ilyen elbaszott trigger-alapu, mint a slony meg tarsai.
mysql replikacioval lattam mar vicces dolgokat. query-based, na (random(), now(), stb)
Jaja, tényleg ott van, csak egy rendesebb adatbázistól úgy összefossa magát, mint az atom.
Márha a cyberclusterre gondoltál. A tárolt eljárások, a random, a serial, meg egy-két hasonló dologtól simán előfordul, hogy az adatbázis másolatai nem másolatok.
A doksiban leírnak minden szépet és jót, aminek a fele is csak feltételekkel igaz. Tapasztalat.
A cyberclustert nem érdemes használni. Forrás: a cyberclustert gyártó cég vezetője. Kifizettünk egy éves supportot, és megkaptuk a jótanácsot.
na, akkor tobbet tudsz rola, mint en :)
en csak nezegettem, itt-ott masoknak utananeztem, es nem mondtak komolyabb gondot. de akkor mostmar nem fogom ajanlgatni csak ugy mindenkinek :)
Én Slony-val replikálok Postgres-t, az előző 3 év alatt mondjuk 4-5x volt olyan, hogy elvesztette a szinkront. Ilyenkor egy újraszinkronizálás úgy 20-30 perc félmillió rekordra. MySQL-nél a master-slave megoldásnál (binlog) érdemes maradni, a master-master megoldást ugyan használjuk, de nem jó eddig vele a tapasztalat, néha nagyon sokáig (értsd: akár órás időtartam) eltérő volt a két gép tartalma.
Igen, Slony-I tényleg megér egy próbát, ha a triggerek miatti limitálás neked nem gond, akkor ez egy elég kiforrott és hivatalosan támogatott - minden külsős megoldás baja az, hogy bizonytalan mértékben késik a támogatás, tehát ős-postgresql-t kell használj esetleg miatta és fél élet munkája felreszelgetni - a frissítésről meg ne is beszéljünk.
Nekem sajnos slony-I nem volt elég és akkor jött az, amit írtam alább.
Azt ajanlanam amelyikhez ertesz vagy amelyikhez van penzed supportot megfizetni, egyik esetben sem pedig azt amelyiket meg akarod tanulni :)
- Oracle draga es brutalis kepessegei vannak, valoszinuleg oda ahova eleg mysql vagy postgress, felesleges.
- mysql problemas lehet a jovoben a sun+oracle+mysql dolog miatt, fene tudja mi lesz (ertem itt ha vallalatot akarsz ra epiteni)
- postgress-t kicsitsem ismerem.
Talan mysql-t javasolnam, mivel konyen tanulhato, konnyeden kapsz hozza supportot akar itt is. Vannak eleg komoly kiegeszitesek hozza (mmm HA-nak vagy epp infobright engine olap es dataminingra ).
Gyakorlatilag ha tudod mit nem szabad (pl ahogy emlitettek elottem a 2 now() 1 queryben) akkor gond nelkul fog szolgalni teged. Errol van egy jo kis leiras itt xaprb. Ott van meg mysql-hez a maatkit, ha inkonzisztencia vagy performance elemzes gondok merulnek fel.
Csak rajtad all, mindenki azt ajanlja amihez a sajat szive kozelebb huzza imho.
MySQL -el ahogy mar irtak a "tukrozest" 2 fele kep tudod megoldani:
master-slave: Ezesetben csak az egyik irhato (master) es a slave-en minden adat meglesz. "Akarmennyi" slave-ed lehet.
master-master: ezesetben mind2 irhato viszont erosen experimental, hogy konzisztens maradj.
drk
Oracle drága? $10000/processzor/év neked csak drága?
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
FYI: Egy negymagos CPU az 2 CPU nak szamait.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
Az ilyen kérdések mindig megindítanak végtelen hitvitákat, nekem X szar, nekem meg Y fagyott és nincs, aki igazságot tegyen.
Ezért ebben nem tudok neked úgysem okosat mondani, mindig lesz rá ellenvélemény, leszólás, hülyevagyöcsém, stb.
Ha a postgresql mellett döntesz, akkor egy kis segítség:
Egy évvel ezelőtt szenvedtem postgresql + pgcluster bereszelésével, akkor született egy kis javítócsomag, amivel ürrepülő vizsga nélkül fel lehet telepíteni az egész motyót és még működik is:
FreeBSD 6.3 amd64:
http://zl.hu/upload/pgcluster/pgclusterz_20080916_0.tgz
FreeBSD 7.0 kiegészítések: http://pgcluster.zl.hu/
Ezekben benne van pár napnyi munka (igazából csak "reszelés" és kísérletezés, debuggolás, tehát semmi nagy durranás kód).
Ez a megoldás ment 6 hónapot, ezalatt produkált összesen egy "befagyást" egy halálra triggerezett rendszerben, tehát akár stabil is lehet egy egyszerűbb szituációban.
akkor módosítom a kérdést:
van valakinek működő 2 gépes klasztere pgsql v mysql alapokon, ami ha elszáll az egyik, akkor rögtön használható lesz a másik(lehet master-slave, de a slave ne legyen read only master kieséskor)?
Igen, egy hozzászólással feljebb a postgresql + pgcluster ilyen. (bár én pont egy pglb-vel használtam lustaságból, de lehet kettővel is)
Mysql-hez pedig drbd+heartbeat+mysql alapokon nyugszik ez a megoldas. Rengeteg a HOWTO neten.
drk
Ha hajlandó vagy úgy megírni az alkalmazást, hogy tekintettel legyen arra, hogy mit nem tud a cluster szoftver, akkor pgclusterrel lehet eredményt elérni.
Köszönöm mindenki segítségét!
Akkor megpróbálom a két konfigot:
pgsql + pgcluster
vs
mysql drbd
mysql-hez minek drbd? Siman elmegy a master-slave is, nalunk cegnel jo par eve mukodik a 4.1-es igy. Ha kiesne a master, a slave rogton hasznalhato lenne, csak lustak vagyunk ra script-et irni.
Ha Java, akkor HA-JDBC neked ezt megoldja. Ha nem, háááát... gondold át :D
sub
+1
Szerelem reggel, szerelem délben szerelem este... most már működhetne az a k..va szerver!
Nem állítom, hogy a konkrét feladatra ez kell, de eszembe jutott, és hasznos lehet még valakinek a Skype által használt megoldás.
Mar tobben irtak ezt a now() dolgot. Mi tortenik akkor, ha a slave eltunik egy orara egy master slave felallasban, es mondjuk az eltunese felenel jon egy query, ami leirja, hogy update valami set datum = now(). Mi tortenik, ha 30 perc mulva felebred a slave? Mit fog kapni a mastertol, es mit kezd vele, illetve O mit ir le? Mondjuk 12.00- kor tunt el, 12.30- kor jott a query, es 13.00- kor kelt fel.
Koszi.
en ugy tudom, hogy nincs semmi baj a now()-val, binlogba mar a master oraja szerinti ertek kerul behelyettesitesre.
szoval a now() replication safe, de a sysdate-rol tudom hogy nem az.
http://dev.mysql.com/doc/refman/5.1/en/replication-features-functions.h…
Unlike NOW(), the SYSDATE() function is not replication-safe because it is not affected by SET TIMESTAMP statements in the binary log and is nondeterministic if statement-based logging is used. This is not a problem if row-based logging is used. Another option is to start the server with the --sysdate-is-now option to cause SYSDATE() to be an alias for NOW().
ettol fuggetlenul meg van egy csomo dolog, amire figyelni kell:
pl. ha olyan modosito query-t futtatsz, ami limitet hasznal, akkor feltetlenul legyen valami kulcs szerint rendezve a query, mert a default rendezes az nem replication safe.
Tyrael
postgresnél azt sem mindig veszi észre a pgcluster meg a cybercluster, hogy tárolt procedúra van a selectben, ami esetleg update-t vagy insertet is végrehajthat,
azt sem mindig veszi észre, hogy a now()-t meg a random()-ot nem ártana egy clustertagon végrehajtani és behelyettesíteni az eredményét, meg voltak még ilyen szívásaim...
ohlol.
sajnos ugy erzem ez az egesz klaszterezzunk dbt tema nagyon, khm, szivas.
jöhetnek konkrét érvek is, ezt hiányoltad korábban tőlem, úgyhogy most nálad a labda.
Ha "row-based logging"-ot hasznal csak az emeber akkor annak mi a hatranya ?
Gondolom nagyobb az adat forgalom a mastar-slave kozott. drdb -tol az altalaban kisebb -e ?
szerk:
Ha a ket szerver idozonaja ugyanaz, es mixed modot hasznal az ember, akkor milyen hatranyal kell szembeneznie ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
A row es statement based replikacio kozti alapveto kulonbseget azzal erzekeltetnem, hogy mondjuk update-elsz egy tablat.
legyen a parancs update mytable set some_column = NULL where id < 100;
A statement based ahogy a neve is sugalja, ezt a statementet kuldi le a slave-re. 1 sor, 1 query viszont feltetelezi hogy eggyeznek a tablaid.
A row based eseten, az osszes sorra ahol a fenti update matchelt, bekerul 1db query a binlogba es pl ugy fog kinezni hogy
update mytable set some_column = NULL where id = 1
update mytable set some_column = NULL where id = 2
update mytable set some_column = NULL where id = 3
etc..
A teljesseg igenye nelkul csak az erzekeltetes kedveert.
Elvileg a mixed ilyen esetekben automatikusan atvalt row based-re.
A row based alapvetoen azert gond, mert sokkal tobb dolga lesz a single-thread replikacionak.
DRBD teljesen mas szinten mukodik. Block device szinten replikalja egy adott particio torteneseit es effektiv nem erdekli hogy milyen alkalmazas fut felette.
drk
A hagyomanyos dbms-ekkel szopni fogsz. Egyszeruen mindegyiket egy gepes mukodesre terveztek, a replikacio vagy akar alapszintu cluster-es feature-ok csak utolag lettek belehackelve (BTW, ez az oracle-re is igaz!).
Ha tenyleg fontos a kozel linearis skalazodas, az elosztottsag, akkor nezd meg a hadoop/hbase-t. Nem SQL ugyan, de nem is feltetlen baj. Ellenben masszivan elosztott mukodesre terveztek. Ha mond valamit a bigtable szo, akkor tudod, mi ez.