Sziasztok!
Van egy Win 10 rendszerekből álló egyenrangú (tehát domain vezérlőt nem tartalmazó) hálózat. Megoldható-e ilyen esetben az, hogy egy géphez több gépnevet rendelünk hozzá?
A kérdés háttere:
Van egy több firebird adatbázist használó rendszerünk, amik két dedikált Win10-es gépen elosztva üzemelnek. Nevezzük őket Server1 és Server2-nek. A napokban a Server2 kiesett, így az adatbázisokat át kellett pakolni a Server1-re, de ebből következően az összes hivatkozást is javítani kellett, hogy ami eddig a Server2-re hivatkozott, az ezentúl Server1-re menjen.
Ugyanez igaznak kellene lennie a gépek névfeloldására is. Azt meg tudom csinálni, hogy egy gép két IP címen csücsüljön, de arra nem találtam módot, hogy a gépnévvel is ugyanezt tegye.
Ötlet?
Gábor
Ui: Természetesen meg tudom oldani, hogy ahol eddig gépnév volt, oda IP címet teszek, működni fog, csak szebb a gépnévvel hivatkozni...
Update:
Azt hiszem, ezt a kérdést most lezárnám, mert a válaszok elmentek egészen más irányba, mint amiről a kérdésem szólt volna.
Hozzászólások
Az lmhosts -ba torteno beirast nem probaltad?
És mi lenne ha Server2 IPCímét hozzárendelnéd Server1-hez így nem kell semmit átírogatni?
https://www.racksrv.com/knowledgebase/view/29/binding-multiple-ips-to-o…
Jah, így keveset kell configolni. De azért DNS nélkül egy workgroupban eltart egy ideig, míg a kliensek ezt észreveszik. Továbbá ez így automata sem igazán tud lenni. Ilyenekre tud jó lenni valami loadbalance....
"Ilyenekre tud jó lenni valami loadbalance...." - Ha nem DB-szerver van mögötte, akkor persze... De DB-szervernél azért nem triviális az, hogy átbillenjen az egyik node-ról a másikra teljesen automatikusan, adatvesztés nélkül...
DB -nél azért kell replikáció - adatszinkronizáció , FB nem tudom, hogy tud-e olyat?
For Whites Only meeting room!
Ezért írtam, hogy nem eszik olyan forrón...
Ha jol olvasom a dokumentaciot, akkor tud, de:
Ez a hivatalos dokumentacioban van. https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref40/…
Ez a 4.0-s doksi, a kérdezőnél 2.5 van, ami egyébként 2019 júniusa óta EOL. Nagyon-nagyon-nagyon nem mindegy... Egyébként a 2.5 -> 3.0 is kifejezetten jelentős ugrást jelent - tény, hogy az alkalmazás/DB oldalon is lenne vele munka, de megéri - és nem csak azért, mert a 2.5 közel három és fél éve end of life státuszban van, hanem teljesítmény okán is.
Folyamatban van a 4.0-ra átállás, de nagyon nem egyszerű dolog. A gondot az okozza alapvetően, hogy a 4.0 nem támogatja az UDF-eket, viszont a rendszerünk használja egyrészt az FB2.5-ben jelen levő néhány UDF függvényeit, valamin azon kívül az rfunc UDF-et.
Rá lehet a 4.0-át is kényszeríteni az UDF használatára, a 3 használt UDF-ből 2-őt hajlandó is használni (fbudf, rfunc), de az ib_udf-et nem hajlandó megenni. Naná, hogy a legtöbb függvényhivatkozás erre mutat...
Szóval az átállást alaposan elő kell készíteni: minden ib_udf-es hivatkozást ki kell váltanom (nem egyszerű, rfunc ugyan lefedi a használt függvények listáját, de paraméterezésük különbözik), utána át tudom pakolni az adatbázisokat 4.0 alá, majd szépen lehet elkezdeni kigyomlálni az udf hivatkozásokat.
Mindezt úgy, hogy mindig el vagyok látva munkával bőségesen, így csak lopott pillanataim vannak ennek kivitelezésére.
Gábor
Ennek kapcsán bennem csak az merül fel, hogy az ilyen "miként lehet egy gépnek több nevet adni" kérdések miatt vagy munkával ellátva? Nem bántásként írom, csak ha sok a hasonló kutyulmány (nincs DNS), akkor nem csoda, ha sok a lapátolni való és esetleg nem marad idő az érdemi munkára.
Nem, ez tévedés. Ez csak egy dolog miatt merült fel: a két gép közül az egyik kiesett (nem tervezetten...) és meg kellett oldani az átállást. Ez sok év óta az első ilyen eset, a kérdésem pedig csak azért szólt, hogy ha legközelebb is előfordul ilyen, hogy tudnám az átállást zökkenőmentessé tenni.
Alapvetően programozó vagyok, nem üzemeltető, de gyakorlatilag egyedül vagyok, így az üzemeltetési feladatok egy minimális része is rajtam van. Ebbe a részébe viszont véletlenül se menjünk bele, mert felesleges.
Hát, ha annyi elegendő, hogy a klienst átirányítja a server2-ről server1-re, akkor feltételezem, a DB-k szinkronban vannak....
Az eredeti kérdés az volt, hogy ezt hogyan ugorja meg a host fájl írkálása nélkül....
Értő olvasás :)
Mint írtam, ezt meg tudom oldani.
nem biztos, hogy értem mit akarsz, de a
C:\Windows\System32\drivers\etc\hosts
fájlba felvehetőek név - cím párok, hogy milyen nevet milyen címre oldjon fel maga.
Hasonló lehet mint a már emlegetet lmhost de ez simán domain név - ip cím fajta feloldást ad.
Ha nem a gépekre kell, akkor talán hasonlót érdelmesebb routeren is megadhatsz, internet nélkül is.
A hosts fájlok írogatását el akarom kerülni. A két szervert a gépek eddig is látták: A Server1 nevet felismerték x.x.x.1-es IP-nek, a Server2-t pedig x.x.x.2-es IP-nek. Azt szeretném megoldani, hogy a kliens gépek csesztetése nélkül továbbra is felismerjék ugyanezt a párosítást akkor is, ha közben az x.x.x.2 IP másik géphez kerül. Természetesen úgy, hogy ha közben új kliens gép kerül a hálózatra, az is megtalálja ugyanezt!
Gábor
van bármi helyi router vagy okosabb fajta switch, amin fel lehet vinni lokális név-ip párokat vagy csak fix ipvel futnak egy hálózatban minden nélkül?
Nem jellemző...
DNS szerveren DNS1 = IP DNS2 = CNAME DNS1
Másik megoldás, terheléselosztás, failsafe módban.
Így hirtelen.
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
A routereken szokott lenni statikus hoszt felvételi opció. Felveszel egy dbsrv hosztnevet, és arra az IP-re állítod ahova szükséges. Ha van pl. Mikrotik router, akkor roppant egyszerű.
Nem tudom milyen csoda program lehet ez, de az Ui:-ra hivatkozva.. nem érdekes a "szépség" ilyen esetben.
WinSzoc és bűntársaival eleget szoptunk mi is, ott is IP alapon van a megosztott DB (sic) betallózva nem gépnévvel. Teljesen mind1. A lényeg hogy minél gyorsabban át tudj kapcsolni egy másik szerverre.
Oké, hogy nagy hagyománya meg szép hosszú története van a Firebird-nek, de azzól még kifejezetten fertelmes egy jószág...
Én nemhogy Windows-ra, de más rendszerre sem tudok olyan megoldást, ahol több neve lehet egy gépnek önmagában (a gépen) konfigurálva...
Persze konténeres meg virtualizálós megoldással lehetséges ezt elérni, de az már igazából nem egy gép a szó ilyen értelmében.
A legegyszerűbb DNS-be felvenni több névvel ugyan azt az IP-t vagy egy A rekord név-cím pár, majd több CNAME mellé. Ha nincs helyi DNS-re lehetőség (miért nincs?), akkor marad a több IP cím egy gépre (és címmel hivatkozva) vagy minden gépen a hosts állomány irogatása...
Ami a fenti problemara nem megoldas, ugyanis utkozest fog okozni, mert o nem csak azt szeretne, hogy egy gepnek tobb neve legyen, hanem konkretan ugyanazokat a neveket szeretne hasznalni (Server1, Server2). Ha ehhez hozzadobod mondjuk a dynamic DNS nev beallitasokat is, onnantol pillanatok alatt olyan utkozesek es kaosz lesz a halozatban, hogy orom lesz nezni. Arrol nem is beszelve, hogy mindezt kezzel allitgasd be, majd amikor esetleg visszajon a Server1, akkor megfelelo sorrendben irogasd vissza, hogy ne alljon fejre minden (Server2-on ott van a server1, addig nem lehet halora kotni server1-et, amig a 2 fogja a nevet. de hogyan teszteled le, hogy tenyleg jo az 1, ha nem tudod bekotni, amig nincs a konfigja leszedve 2-rol? es mi van azzal az idovel, amig 1 bootol/halozatot konfol, de 2-n mar nincs ott a kamu resz?)
A fenti problemara a megoldas egy loadbalancer lenne igazabol, ami elfedi, hogy valojaban 2 gep van mogotte.
Nem, félreértettél. Pontosan az volt a kérdésem, hogy egy géphez több nevet rendelni. Természetesen a hálózatban egy név csak egyszer szerepelne, hisz ha a Server2 kiesik, akkor az a név már nem lesz a hálózatban.
de jol ertettelek. amig doglott a server2, annak atveszi a nevet a server1. itt ugye kvazi nincs tul nagy gond, server2 eltunt a halozatrol, felveszi server1 melle, es megy. akkor van gond, amikor vissza akarod rakni server2-t a halozatra. Ezt megint csak nem lehet kieses nelkul megtenni, mert server1-rol le kell takaritani a + nevet. ha ezt nem teszed meg, akkor amint radugod server2-t a halozatra, 2x fog szerepelni, mert server1 is hirdetne magat mint 2.
Egyebkent allitolag NT serveren meg lehetett hekkelni a netbios nevet, hogy ez egyreszt mit befolyasol, masreszt win10-en is mukodik-e, azt max probaval lehet megoldani.
https://www.techsupportforum.com/threads/multiple-host-names-for-a-comp…
Milyen módon tartod szinkronban a két szerveren a lofutyi.IB fájlokat? Mert nem csak annyi az átállás, hogy az egyik insert/update az egyik szerverre ment, a következő select meg a másikról kérdez, és megdöbben azon, hogy az előbb commit-tal lezárt módosítás nincs ott...
Szóval szerintem a sima tcp loadbalancer vagy DNS-alapú átállással csak óvatosan...
ez nem domain probléma, DNS probléma !
DNS szerver (szolgáltatás) végzi a név feloldást - tegyél egy openwrt vagy bármilyen linuxot , abban lesz DHCP, tűzfal és olyan DNS-t csinálsz amit akarsz.
For Whites Only meeting room!
több sebből is vérzik a dolog:
- Win 10 rendszerekből álló egyenrangú hálózat
Ez nem hálózat csak egy kupac gép egymás mellett...
- windows 10 vs SERVER :)
Nem, az nem server...
- "Azt meg tudom csinálni, hogy egy gép két IP címen csücsüljön"
Ez is csak valami gányolás, nem megoldás. biztosan rossz irány.
- a hostname !=DNS name.
hostname csak egy lehet egyszerre. pont. (ha sűrűn cserélgeted, az sem túl jó ötlet, lehet még reboot is kell hozzá :)
DNS-ben megy annyi nevet rendelsz egy IP-hez, amennyit csak akarsz.
Persze ahhoz kell egy DNS szerver, ami meg már feltételez egy hierarcikus hálózatot, ami nem csak egy kupac desktop.
ez olyan, mint annó amikor a nyomtatók is egy-egy desktopon lógtak, és a többiek egymás gépén keresztül nyomtatgattak... meg mindenki megosztotta a saját mappáit. KÁOSZ. no privacy, no security. Nem mellesleg igen jó recepet a teljes körű adatvesztésre.
szerencsére ilyennel legutóbb 10+ éve találkozam.
zrubi.hu
DSN-hez miért kéne bármiféle hierarchiának lennie a hálózatban? A saját otthoni alhálózatomon is van egy DNS szerver, mégsem ő az, aki routeolja a forgalmat a világ felé, vagy szolgál ki bizonyos szolgáltatásokat. Csak egy gép a többi között, amit a többiek használnak.
Egy hálózatnak önmagában miért kéne bármiféle hierarchiának lennie?
A hálózatban az egyes gépek elláthatnak szerepköröket, attól még nem fontosabb az egyik gép a másiknál. Lehet az egyik a DNS, a másik a mailer, a harmadik a syslog, a negyedik a DB, az ötödik az webserver stb. Egyik sem fontosabb a másiknál, nincs köztük hierarchia.
hát... hol is kezdjem? :)
kezdjük talán a default gateway-nél. ;)
Ilyen mindenhol KELL - hacsak nem egy lan partin vagyunk internet elérés nélkül.
Tehát ő a helyi hálózati szegmens főnöke. router. ő dönti el ki hová mehet. A kliens ez alá van rendelve minden esetben.
A DNS pl maga is egy hierarchikus szolgáltatás, ahol 1 master és opcionálisan több slave is lehet a szolgáltatás része.
De a kliensek mindenképpen egy DNS szolgáltatás alá vannak rendelve. Hiszen ők kizárólag kérdeznek, a szerver meg válaszol - amit csak akar...
A kliensek 100%-ban meg kell bízniuk a DNS szerverben, máshogy nem máködik a dolog.
DHCP szintén, jó esetben csak egy van, és ő mondja meg kinek mi az IP címe.
De még egy windows workgroup is hierarchikus, mert megszavazzár, hogy ki legyen a 'főnök'... és onnantól eszerint működnek.
Mi ez, ha nem hierarchia?
zrubi.hu
"A kliens ez alá van rendelve minden esetben."
Dehogy. Az, hogy egy hálózati szegmensben ki a default gateway, az egy dolog, ez semmiféle kliens-szerver viszont nem tételez fel. Például nekem is van két olyan gépem, amik bizonyos hálózatok esetén gateway-ei egymásnak. Semmi alá-fölérendeltségi viszony nincs ott a két gép között.
A DNS esetében az alá/fölérendeltség a zónákban van meg (a névtér az, ami hierarchikus), de a DNS szerverek között ez nem feltétlenül van meg (a 13 root DNS szerver is valójában 1500+ gép, anycast használatával működik). A DNS névtér viszont csak egy adatbázis, nem maga a hálózat. Nincs semmi alá/fölé rendeltség, a DNS szervert kérdezik gépek. De például beállíthatom a hálózatomat úgy is, hogy a saját hálózatomban lévő DNS szervert használja 1-2 gép, a többi meg pl. a Google DNS szerverét. Akkor most az én gépem, ami Google DNS-t használ, hierarchiában alá van rendelve a Google hálózatának? Dehogy. A hálózatomon lévő két gép, amelyik két eltérő DNS szervert használ rekurzív névfeloldásra, más hierarchiában vannak?
"DHCP szintén, jó esetben csak egy van, és ő mondja meg kinek mi az IP címe."
Dehogy. Eleve, egy DHCP szerver több hálózati szegmenst is kiszolgálhat, de egy hálózati szegmensen is lehet több DHCP szerver, a protkoll erre fel van készítve. Például ha van két szervered ugyanazon a szegmensen, és mindegyik a szegmensen belül egy nem átlapoló címtartományért felelnek, semmi gond nincs - mindegyik kliens kap a protokoll alapján egy címet majd attól a szervertől, amelyik által felajánlott konfigot elfogadja (DORA elv - Dicover, Offer, Request, Acknowledge).
úgy tűnik, ez nézőpont kérdése, mert szerintem ezek mind alá/fölé rendeltséget jelentenek.
Lehet mert én provacy és security szempontból (is) nézem, ahol elég komprommitálni a 'felsőbbrendű' szervereket, aminek hatására az alárendeltek egyből áldozattá vál(hat)nak.
Igaz ez egy router, DNS, vagy akárcsak egy DHCP szerver esetében is...
a DHCP esetén ezt egy rouge DHCP szerverrel könnyedé demonstárni is lehet, miszerint egyetlen rouge szerver minimum káoszt okoz egy hálózaton, de ügyesen használva bármelyik klienset eltérítheti akarata szerint.
miért? mert a többiek mind ennek vannak alárendelve - azaz erősen függnek tőle.
A példád is alátámasztja ezt, ha a google DNS kompromittálódik akkor 'csak' azok érintettek ebben akik ezt használják.
ugyan így a saját DNS szervered kerül idegen kéz alá, akkor csak az a kettő téríthető el azonnal ami ezt használta...
(és a most 'divatos' gugli féle secure DNS is ezt csinálja, kiveszi a kezedből a DNS feloldást, és egy harmadik félre bízza, mert szerinte az 'megbízhatóbb', mint amit the a kis hálózatodon beállítottál - közben meg csak mindent tudni akar rólad, és ezt a DNS feloldásaidon keszesztül meg is teszi ;)
De ezen biztosan nem fogunk összeveszni, ha te nem így látod/érted - am legyen. De a tényeken ez nem változtat ;)
szerintem.
zrubi.hu
Köszönöm szépen az eddigi hozzászólásokat!
Több hozzászólásra is reagálnék:
"Oké, hogy nagy hagyománya meg szép hosszú története van a Firebird-nek, de azzól még kifejezetten fertelmes egy jószág..."
Erre azt tudom mondani, hogy ízlések és pofonok. Tökéletesen ellátja a feladatát, sok gigás adatbázisainkat kezeli minden gond nélkül. Nekem kifejezetten tetszik. Lényegesen jobb szerintem, mint a MySql, de ez is csak egy egyéni vélemény, nem általánosítás.
"Milyen módon tartod szinkronban a két szerveren a lofutyi.IB fájlokat? "
Sehogyan. Ugyanis nem ugyanazok az adatbázisok. Az ügyviteli rendszerünk egyszerre több üzletágat kezel, minden üzletágnak saját adatbázisa van, ezek vannak elosztva.
"Ez nem hálózat csak egy kupac gép egymás mellett..."
Ok, lehet, hogy nem fogalmaztam túl szakmaian. Arra akartam csak utalni, hogy nincs domain controller a rendszerben, tehát a Win10-es gépek egyenrangúk. Természetesen van DHCP szerver, ezt a funkciót egy Linux szerver látja el, de annak csupán az a feladata, hogy IP címet osszon.
"- windows 10 vs SERVER :)"
Igen, tudom, hogy nem szerver oprendszer, de a jelenlegi funkciójában mégiscsak szerver feladatokat lát el abban az értelemben, hogy firebird adatbázisszervert futtat. És még mielőtt ezzel jönnétek, performancia oka van annak, hogy nem Linuxon fut az FB: sebességtesztjeink alapján a Win alatti FB nagyságrendekkel volt gyorsabb, mint ugyanaz Linux alatt. (Értsd: egy kalkulációs folyamatunk Linux alatt 10 percig fut, ugyanez Win alatt 1-2 perc alatt végez! A kiindulási adatok természetesen megegyeznek.)
"- "Azt meg tudom csinálni, hogy egy gép két IP címen csücsüljön" Ez is csak valami gányolás, nem megoldás. biztosan rossz irány."
Ez átmeneti megoldás arra, hogy ha az egyik firebird-ös gép kiesik, ne kelljen 1000 helyen átkonfigurálni az adatbázisok elérhetőségét. Nyilván rendbe lesz hozva a kiesett gép és vissza lesz állítva a rendszerbe, attól kezdve a dupla IP egy gépen megoldás meg fog szűnni, hisz nem az az üzemszerű működés.
"ez olyan, mint annó amikor a nyomtatók is egy-egy desktopon lógtak, és a többiek egymás gépén keresztül nyomtatgattak... meg mindenki megosztotta a saját mappáit. KÁOSZ. no privacy, no security. Nem mellesleg igen jó recepet a teljes körű adatvesztésre."
Az ilyeneket a hálózattól függetlenül mi is kerüljük. Nyomtatók mind hálózatosak, a munkák pedig minden esetben egy Linuxos file szerveren történnek. És van jogosultságkezelés, vannak mentéseink több helyre, van törlés elleni védelmünk, stb. Nyilván lehetne ennél nagyobb biztonságot is elérni, de ahhoz már annyival több pénz kellene, ami a cég számára nem éri meg.
Az pedig, hogy ilyen a hálózatunk, csupán anyagi okai vannak, ne is menjünk el abba az irányba, hogy mit kellene másként csinálni. Azzal főzünk, amink van....
Gábor
Arra a Linuxra tegyél fel egy DNS szolgáltatást és akkor előbbre vagy. Továbbá a Firebird Linuxon is futtatható lehet és még előbbre vagy + kicsit fazonosabb is a rendszer.
A DNS szolgáltatást meglátom.
A második részre a válaszom: értő olvasás: "És még mielőtt ezzel jönnétek, performancia oka van annak, hogy nem Linuxon fut az FB: sebességtesztjeink alapján a Win alatti FB nagyságrendekkel volt gyorsabb, mint ugyanaz Linux alatt. (Értsd: egy kalkulációs folyamatunk Linux alatt 10 percig fut, ugyanez Win alatt 1-2 perc alatt végez! A kiindulási adatok természetesen megegyeznek.)"
Értem én, hogy pénzbe kerül (és sosincs semmire pénz), de akkor fejlesszetek a Linuxon. Nekem teljesen mindegy, de ez az infrastruktúra ilyen módon meglehetősen zavaros, ami zavaros az előbb utóbb visszaüt valahol és akkor akár több pénzbe is kerül, mint 2db SSD és/vagy valamennyi RAM a Linuxba. Lásd most ez az ügy is, hogy miként lehet két nevet adni a gépnek.
És gondolom a hardver is ugyan az volt alatta ;)
vagy a szokásos összehasonlítás, amikor a Linux alatt 10+ éves, másra már nem használható vas döcög, a windows alatt meg a tegnap kiadott legújabb proci + SSD? :)
zrubi.hu
:D
Tök jó, amikor amatőrnek nézik az embert.
A tesztek ugyanazon a gépen történtek, ugyanabból az adatbázismentésekből, egyetlen változás volt: más-más winyón volt a két rendszer, de még ezek is közel hasononló teljesítményűek voltak. És nem egyszer futó teszt volt, hanem több teszt összesítő eredményéből jött le ez az eredmény.
Persze, ha tudtok ötletet adni arra, hogy mi okozza ezt a sebességkülönbséget, szívesen várom a javaslatokat.
Mindkét rendszerben 64 bites FB 2.5 volt telepítve. Mindkét rendszerben ugyanabból a mentésből visszatöltött adatbázisok voltak. A gép semmilyen más feladatot nem látott el.
A Windows rendszeren akkor produkált 10 perces futási időket, amikor le volt tiltva az írási gyorsítótárazás az eszközön. Ebben az esetben hasonló futási időket produkált a teszt. Ha ez engedélyezve van, akkor ez leesik 1-2 perc között időre. Ebből arra a következtetésre jutottam, hogy a Linuxon ez alapvetően tiltva van. De hogy ezt ott hogy lehet megvalósítani, senki sem tudta eddig megmondani nekem.
Gábor
"Tök jó, amikor amatőrnek nézik az embert." vs "akkor produkált 10 perces futási időket, amikor le volt tiltva az írási gyorsítótárazás az eszközön"
És ennek mi köze egymáshoz? Vagy fejtsd ki, vagy ne is szólalj meg. Ez a hozzászólás így semmit sem ér.
Minden lényegeset tartalmazott a hozzászólásom. Legalább utána olvashatnál az írási gyorsítótárazásnak, ha már kikérted magadnak a hardverrel kapcsolatos megjegyzést.
Ezt már megtettem. Tudom, mit jelent, mik az előnyei, mik a hátrányai. Tudom, Windowson hogy lehet beállítani. De ugyanezt Linuxon nem tudom. Mi köze ennek az egésznek ahhoz, hogy amatőrnek néznek-e?
Ez egyet mutat: nem ismerem a Linuxot olyan szinten, hogy egy ilyet be tudjak állítani. De olyan szinten nem vagyok amatőr, hogy tudjam, akkor releváns egy sebesség-összehasonlítás, ha közel azonos teljesítmény és hasonló környezetben zajlik.
Ha egyik rendszeren be van kapcsolva, a másikon nincs, akkor az kb olyan, mintha hardver különbség lenne a kettő között, kb hdd vs ssd.
Produktív adatbázis (szerver) alatt én biztosan nem kapcsolnám be. Ha nagyobb teljesítmény kell, akkor megfelelő RAID vezérlőt kell venni és/vagy SSD-t (leírtak alapján írást kellene gyorsítani).
Lentebb írtam, hogy nálunk két nagyságrendnyit gyorsult async módban — először természetesen én is SSD-t tettem alá, de nem gyorsított rajta számottevően.
Több nagyobb, párhuzamosan futó insert/update közben húzd ki a konnektorból a gépet. De előtte azért legyen konzisztens mentésed...
Tudom jól, hogy mivel jár az async mód, pont ezért van két óránként mentés, jó nagy szünetmentes és generátor is :-)
Annak idején megbeszéltem az érintett kollégákkal (csak egy pár ember használja ezt a rendszert, és ők sem túl sokat), abban egyeztünk meg, hogy a sebességért cserébe bevállalják, hogy esetleg vissza kell állni a két órával korábbi állapotra.
Én ezt tutira nem merném bevállalni, főleg ha PC jellegű a gép, amin fut, mert túl nagy a RAM függőség. Az is kérdés, hogy a 2 óránkénti mentés mennyire elegendő, nem marad-e 1-1 blokk tovább is kiíratlanul.
Ha SSD nem gyorsított számottevően, akkor esetleg más probléma is van/lehet, illetve kérdés, hogy a Te esetedben írás vagy olvasás a szűk keresztmetszet.
A kernel mindenképpen kiírja diszkre a 30 másodpercnél régebben a pufferekben levő adatokat (/proc/sys/vm/dirty_expire_centisecs). Én úgy értelemezem, hogy a Firebird async módban a program által kiadott commit parancsra egyszerűen csak nem hívja meg az fsync()-et.
A mentés gbak-kal történik, az biztos konzisztens lesz.
Ez mondjuk igaz, de a gbak remélhetőleg olyan fájlrendszerre ment, ahol minden rögtön lemezre megy :-)
Mindenesetre én megnézném, hogy mi a szűk keresztmetszet és nem lehet-e "normál" módon gyorsítani.
+1
A backup szerver egy másik épületben van + redundáns táp + redundáns hálózat + szünetmentes + generátor :-)
Nem ér annyit.
Mindenképpen olvasd el a doksit, hogy ez mivel jár, mielőtt bekapcsolod!
Nálunk egy külsős cég rendszere használ firebird-öt, ott ez egy adott műveletet 15-20 percről ugyanannyi másodpercre gyorsított :-) Napközben két óránként van adatbázis mentés, így ha bármi miatt elszállna a szerver anélkül, hogy kiírná diszkre az adatokat, legrosszabb esetben is csak két órai munka veszne el. Eddig még nem volt rá példa :-)
Én csak viccnek szánatm...
de végül csak kijött belőle, hgy egyik esetben az adatbázsod csak a memóriába írkált a másik meg a diszkre...
zrubi.hu
A 2.5-ös FB-t iszonyatosan gyorsan el kéne felejteni, ott kezdődik a dolog. Aztán az is kérdés, hogy Linux alatt milyen fs-en voltak a fájlok, milyen kernelverzió (mert sajnos volt néhány fs+verzió kombináció, ami nagyon sz@r volt a 2.5-ös FB alá).
Az írás cache szép dolog - általában. Azért a forced write környékén nézelődj a FB doksikban... Persze ha nem gond egy áramszünetnél az adatvesztés/sérült DB, akkor lelked rajta - én azért óvatos lennék...
erre nekem hirtelen az jutott eszembe, hogy a csinálj alternatív konfigot és egy szkript meg cserélgesse - ha szükséges
igen, egyszer át kell mindent írni - de amikor újra elő áll a helyzet, csak előveszed az alternatív konfigot és azzal indítod el..
For Whites Only meeting room!
A Firebird képes clusterben működni? Úgy,hogy a kieső node szépen visszamászik, ha újrarúgtad, mintha mi sem történt volna? Ja, hogy nem, mert a kliensnek egy fájlhoz ad hozzáférést - ahhoz, amit a kliens kér, és a firebird proceszz rendelkezik rá megfelelő jogokkal.
"Sehogyan. Ugyanis nem ugyanazok az adatbázisok. Az ügyviteli rendszerünk egyszerre több üzletágat kezel, minden üzletágnak saját adatbázisa van, ezek vannak elosztva." - Azaz ha az egyik pécé megkotlik, akkor addig azok az "üzletágak" nem dolgoznak, majd ha valami módon vissza lett húzva a DB (akarom mondani az uzletag123.IB fájl), akkor tudnak dolgozni. Mondjuk ha üzletileg nem kritikus az adatok léte, illetve az, hogy elérhetőek legyenek, hát jó, csináljátok, de egy komplett diszkdöglés okozta adatvezstésnél azért elő fog jönni, hogy valami "ütésállóbb" megoldás lehet, hogy jó lenne... (3rd pary megoldások vannak firebird folyamatos mentésére, illetve melegtartalék életben tartásához)
"egy kalkulációs folyamatunk Linux alatt 10 percig fut, ugyanez Win alatt 1-2 perc alatt végez!" - Akkor nem ismered a firebird-öt. Se. Linuxon is tud gyors lenni, csak vasat és megfelelő FS-t meg kernel/memória paraméterezést igényel.
"ne kelljen 1000 helyen átkonfigurálni az adatbázisok elérhetőségét" - Akkor mégis ott van két gépen minden DB, vagy nincs? Ha ott van, akkor goto 10: hogyan van megoldva a szinkron, ha nincs, akkor meg úgyis más DB-t kell megcímeznie a mancikánál futó motyónak... (Mert ugye nem azonosak a fájlnevek...?)
Szerencsétlen dolog. Mármint a firebird miatt. Az ugyanisa cliens hozzáférésekor nyitogatja az adatbázis file-okat. Teszemazt cliens1 kommunikál server1-el és hirtelen server1 meghal és server2 veszi át a szerepét. De sajnos a file nyitásokról lockolásokról bufferekről nincs tudomása. bámmm.
IMHO Jobb ha a firebird server egy failover clusteren megy és ott vándorol node-ról node-ra.
Nem DB shadow-ról van szó. Mindkét gépen KÜLÖNBÖZŐ adatbázisok vannak, így nem kell egymásról tudniuk. Az egyik gép leállása esetén nem automatikusan veszi át a másik a szerepét, azt kézzel kell megcsinálnom. De ezzel nincs is gondunk.
Mire a másik gépre visszapakolod valahonnan a valamikori állapotoú IB-ket, addigra scriptelve yool át lehet mókolni a dns-t is... Persze ilyenkor úgyis körbe kell kiabálni, hogy mindenki, aki épp a megdöglött gépen lévő DB-ben dolgozott, az lépjen ki az alkalmazásból... mert ugyebár az app totál más állapotot fog tudni a DB-ről, mint ami az életben maradt szerverre történő DB-visszaállítás után ott elérhető lesz...
Esetleg. (Elég régi és nem próbáltam)
https://www.itprotoday.com/compute-engines/how-can-i-define-multiple-ne…