Több MariaDB kiszolgáló egyetlen szerveren

Címkék

Nem gyakran, de azért rendszeresen visszatérő feladatunk egyetlen szerverre több MariaDB kiszolgáló telepítése. Ha esetleg szükséged lenne egy működőképes konfigurációra, ebben a leírásban találhatsz egyet.

Hozzászólások

troll on:
docker run --name mariadb-1 -p 3306:3306 -v /srv/db1:/var/lib/mysql -d mariadb
docker run --name mariadb-2 -p 3306:3307 -v /srv/db2:/var/lib/mysql -d mariadb
docker run --name mariadb-3 -p 3306:3308 -v /srv/db3:/var/lib/mysql -d mariadb
troll of

-
Big Data trendek 2016

Pl. mert nincsenek jó tapasztalatok a stabil működéssel kapcsolatban? Meg ha belgondolsz, a DB-szervernek minél közelebb célszerű lennie a tényleges storage-hoz, minél kevesebb absztrakciós layert célszerű berakni - a docker legalább egy plusz réteget mindenképp bevisz.
DB-szerverből ráadásul nem gyakori, hogy ilyen szinten kell szaporítani - de ha van ellenpéldád, szívesen veszem.

Hat a Docker 1000 felekeppen lehet konfiguralni, valoszinu, hogy megtalalnad a neked fontos beallitasokat. a -v vel odaaadod neki a storaget, ahogy van a gazda gepen, nem fogsz lasulast merni, es a docker retegelt fajlrendszerevel sem kell szamolnod (a kontenernek amugy is immutablenak illik lenni).
Amugy a Docker semmi varazslatot nem csinal, csak cgrouppokkal meg namespacekkel jatszik, te pedig a kapcsolokkal tudsz jatszani, hogy melyik eroforrast honnan vegye.
"docker legalább egy plusz réteget mindenképp bevisz" felhasznaloi szemszogbol tenyleg bevisz egy reteget, de az alkalmazasod docker nelkul is egy nevterbe fut, es amugy is a cgroupokon keresztul megy minden :) A kontenered egy kutyakozonseges pid lesz az oprendszernek.

Itt a Marcell nagyon szepen osszeszedi hogy is mukodnek a cgroupok meg nevterek.

-
Big Data trendek 2016

Ha az át akarja lépni, még mindig ott van a natív LXC. Szerintem még az is kezelhetőbb megoldás lenne. Jó leírás ez, de éles rendszeren nem vetném be, hanem konténert használnék.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

"DB-szerverből ráadásul nem gyakori, hogy ilyen szinten kell szaporítani" latod a kolleganak is ep perre volt szuksege, es ahelyett, hogy kontenerekbe zarta volna oket nekiallt buveszkedni. Nem is kell ehhez dockert hasznalni, egyszeruen kulon network namespacebe inditja a kulondozo mzsql szervereket, meg mas mas meghajtot csatol a kontenerhez. kb ennyi, meg a konfiguraciot sem kell bantani (nyilvan lehet fokozni/bonyolitani a dolgot, es a pontos igenyek ismerete nelkul en most csak mondtam valamit).

-
Big Data trendek 2016

Es ha a feladat forditott? Tehat redundans SQL legyen tobb hoston?
- docker swarm? (de akkor swarm-on belul kell lenni aki az SQL-t is hasznalja, kulonben IP cim valtozasnal nem talalja meg).
- tcp proxy docker swarm elott, es a swarm-ban az sql
- master/slave es az sql szerverek tudnak egymasrol? (mongodb-ben lehet ilyet).

Van meg par 5letem. De erdekelne, hogy ki hogyan csinalja.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Akkor pláne nem Docker, hanem Galera - a Docker-es "gyorsan lehet új node-dal növelni a teljesítményt" DB-szervernél pont nem játszik - a node-ok szinkronizációjának az időigénye nagyságrendekkel magasabb, mint amit a Docker-rel lehetne nyerni (deploy, start, minden egyben). A magas rendelkezésre állás miatti fürtözéssel, mint céllal a plusz réteg (annak is van egy meghibásodási val.sége) berakása szembe megy.

Galera dockerben :) Nem elvakult fanatista vagyok, de a docker az nem csak a gyors indulasrol szol, meg a szeparaciorol, hanem a docker egy alkalmazas csomagolasi technika. Szoval ha van egy kontener imaged, akkor 99.99%-os esellyel, reprodukalhato. Ha abban a kontener imageben Galera, MySQL, kiskacsa furdik van, akkor azt tetszoleges x86 architekturan elinditva ugyanugy fog mukodni. A storaget, meg halozatot stb ugyis odaadod a konternek, mert maga kontenert illik immutable kent kezelni. Tehat, ha nem dockerbe csomagolod, az alkalmazast, akkor valahogy mashogy kell az automatizmusrol gondoskodnod. Persze vannak megoldasok, Ansible, Puppet, stb, csak azok reprodukalhatosagi aranya nincs koszono viszonyban a dockerevel, hacsak Packerral vagy valami hasonloval nem sutod meg elore az imaget, amit futtatni akarsz.

-
Big Data trendek 2016

Forditva lenyegesen trukkosebb a dolog, es elore mondom nem csinaltam meg olyat.
- Igazabol swarmra is csak akkor van szukseg, ha van x geped a clusterben, amin egyeb kontenerek is futnak itt meg ott. A docker swarm nyujtotta overlay networkot nem ajanlanam ilyen celra, mert lassu (gyakorlatilag a layer 2-es network stacket csomagol be layer 4-be, es UDP kuldi tovabb), szoval ebben az esetben a halozat kialakitasara nagy gondot kell forditani. Persze, ha az rendben van, hogy egy gep csak egy db-t futtat, akkor --net=host, es az tiszta ugy. Amugy pont halozatrol, meg dockerrol tegnap hallgattam egy jo eloadast kollegamtol. Szoval a a swarmos halozat, hasznalhato belso kommunikaciora, de kulso kommunikaciora ott van a hagyomanyos docker bridge, szoval nem kell swarmon belul lennie mindenkinek, tetszoleges szamu network definialhato, meg routolhato. Lehet probalkozni Calico-val, ami layer 3-ra epulo virtualis halozati reteg.
- Ez is egy bonyolult kerdes, mert nagyon sok a lehetoseg, de ugy gondolom hogy aki kontenerizaciora adja a fejet, az nem ussza meg egy service discovery beuzemeleset, onnantol kezdve meg a sd-tol kell megkerdezni, hogy melyik szolgaltatas hol van
- szerintem ez db specifikus. Ahogy emlekszem mysql-nel egyszer beallitod a mstert, hogy keszitse a binary logot, es utanna a slaveket mar tetszolegesen gyarapithatod. Annyi a kontener specifikus megjegyzesem, hogy nyilvan az adat meg a logok nincsenek a kontenerben, szoval a van egy futo slaved, annak a storagerol keszitesz egy snapshotot ugy, hogy az adat meg a logok atomi lepeskent legyenek lementve. A snapshoto odamasolod az uj volumra, vagy ahol akarod tarolni, es odaadod az uj kontenernek. Azon mikor elindul a mysql, akkor a bin logokbol tudni fogja, hogy hany lepessel van elmaradva, es elmeletileg kesz is az uj replika. Azt azert tudni erdemes, hogy load balancer nelkul a master-slave csak a replikacios faktor novelesere jo, ha terheles elosztasra is szukseg van, akkor kell egy LB, ami az irasokat a masterre kuldi, de az olvasasokat elosztja a slavek kozott.

-
Big Data trendek 2016

Belelapoztam és több kérdésem van.
Miért nem a hivatalos tárolóban lévő MariaDB-t használod? Lehet nem a 10.1-es, "csak" a 10.0-ás kiadás, de legalább biztonsági támogatással. A 3rd party repository meg ki tudja mennyire karbantartott. Plusz lehet későbbiekben ütközni fog a hivatalos csomagokkal.
Indítást initscript-el végzed, systemd helyett. Van ennek valós oka?

1) A tárolót a MariaDB repository configuration tool ajánlotta fel. Biztosan nem azért, mert nem hivatalos.
2) Idézek a MariaDB oldalról: "MariaDB 10.1 is the current stable (GA) release of MariaDB." Biztosan van biztonsági támogatása is. Ütközni sem fog.
3) Momentán az initscriptes megoldás tűnt a legegyszerűbbnek, legalábbis nekem. Remélem ez nem gátol meg abban, hogy Te mást használj.

1) Hivatalos alatt nem azt értem hogy upstream készíti a csomagokat. Hanem hogy a Debian csapat naprakészen ismeri a csomagot, az milyen opciókkal van fordítva, milyen beállításokat tesz alapértelmezetté és milyen konfigurációs állományokat tartalmaz milyen elérési útvonalakon. Különben előfordulhat csomag ütközés. Akár kiadás frissítésekkor esetleg a Debian által szállított változatra akarna átállni akkor jön elő hogy olyan opciókkal lett fordítva / használva amit az új csomag nem támogat és amiatt nem tudsz frissíteni.
2) Ez megint az upstream vállalása, hogy ez a jelenlegi támogatott verzió és akár gyorsjavítást is ad ki hozzá. Viszont nem látom ebben azt, hogy ha lesz 10.2-es, akkor arra a régebbi kiadásokhoz (Jessie, Wheezy) is fog csomagot készíteni. Azok megragadhatnak 10.1-nél és ha régebbi változathoz nem backport-olják a biztonsági frissítést, akkor sérülékeny maradsz.
3) Engem nem akadályoz, max másokat akik szeretnék systemd-vel használni és ezt nem kapják meg.

off: borzasztóan utálom azokat a leírásokat (cikkeket, stb.), ahol 10 kis cafatra szednek egy nem is túl hosszú valamit, aztán lehet 10x klikkelni 3 mondatonként.

Láttam, azért gondoltam, hogy leírom, poénként :)

Tényleg inkább ott a jellemző ez a setup, értem én, hogy te szereted, lelked rajta. A végtelenítettet én sem szeretem (főleg amikor dinamikusan jön még-még-még), de ez a három bekezdésenként kattogtatás se szimpi, imho ez elférne egy hosszabb oldalra. De ezen meg nyilván az én lelkem, de mondjuk ahhoz nincs köze, hogy egyébként van-e bármi közöm a mariadbhez, vagy nem :) Pusztán ízlés kérdése.

Hatalmas +1 erre.
Amugy eleg sokan vannak ilyenek, englishrussia-n pl. regisztraltak megtekinthetik egyben is a cikket. De van valami elektronikai oldal, ami szinten igy mukodik (nem jut eszembe a neve, joreszt emiatt nem latogatom gyakran).
Gondolom a felhasznalok idegesiteserol szol, hogy vagy lapozz egy csomot, vagy fizess/regisztralj!

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Minőségi írás. Folytasd mert nagyon nagy igény van oktatási célból hasonló anyagokra.

Az oktatási cél valóban elsődleges. Ez kiderül a többi blogbejegyzésemből (webszerver, levelezőszerver készítése) is. Vannak még feldolgozandó témáim (például Nagios, Munin), amelyet a profik nyilván lazán feltesznek és beállítanak, de aki először próbálja, az örül az egy oldalas részekre szétbontott felépítésnek is. Aki oktat, az tudja, miért van ez így. Aki meg unja, hát ne olvassa el. Szóval, köszönöm a bíztatást, folytatása következik. ;-)

Off: minden tiszteletem amiért energiát fektetsz az ilyen anyagok készítésébe. De tényleg, őszintén, no offense.
Amit írtam az csak a kivitelre vonatkozott (és nem is olvastam végig, pedig amúgy érdekelt volna, de ez most nem fontos).

Egy - szerintem konstruktív - javaslatom azért lenne: tudnál kitenni egy olyan linket, hogy "minden lépés egyben"? Ez ugyanis megoldaná a hozzám hasonló, 10x klikkelni nem szerető ****ok problémáját is. (Az instructables is hasonlóan működik, és szerintem nem véletlenül.)