{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelimi i klastereve resiliente mbi baz\u00ebn e PostgreSQL dhe Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hyrje<\/h1>\n

<\/p>\n

Pak sa koh\u00eb m\u00eb par\u00eb m\u00eb \u00ebsht\u00eb dh\u00ebn\u00eb detyra p\u00ebr t\u00eb zhvilluar nj\u00eb grup klaster t\u00eb q\u00ebndruesh\u00ebm p\u00ebr PostgreSQL<\/a><\/noindex>, q\u00eb punon n\u00eb disa qendra t\u00eb t\u00eb dh\u00ebnave t\u00eb lidhura me fibra optike brenda nj\u00eb qyteti, dhe n\u00eb gjendje t\u00eb p\u00ebrballoj\u00eb d\u00ebshtimin (p.sh., \u00e7mendje t\u00eb energjis\u00eb) t\u00eb nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Si softuer q\u00eb p\u00ebrgjigjet p\u00ebr q\u00ebndrueshm\u00ebrin\u00eb, kam zgjedhur Pacemaker<\/a><\/noindex>, sepse kjo \u00ebsht\u00eb zgjidhja zyrtare nga RedHat p\u00ebr krijimin e grupeve klaster t\u00eb q\u00ebndrueshme. Ajo \u00ebsht\u00eb e mir\u00eb sepse RedHat ofron mb\u00ebshtetje p\u00ebr t\u00eb, dhe sepse kjo zgjidhje \u00ebsht\u00eb universale (modulare). Me ndihm\u00ebn e saj do t\u00eb jet\u00eb e mundur t\u00eb sigurohet q\u00ebndrueshm\u00ebria jo vet\u00ebm p\u00ebr PostgreSQL, por edhe p\u00ebr sh\u00ebrbime t\u00eb tjera, duke p\u00ebrdorur module standarde ose duke i krijuar ato p\u00ebr nevoja specifike.<\/p>\n

<\/p>\n

N\u00eb k\u00ebt\u00eb zgjidhje ka lindur nj\u00eb pyetje e arsyeshme: sa e q\u00ebndrueshme do t\u00eb jet\u00eb klasteri i q\u00ebndruesh\u00ebm? P\u00ebr ta shqyrtuar k\u00ebt\u00eb, kam zhvilluar nj\u00eb platform\u00eb testuese q\u00eb imiton d\u00ebshtime t\u00eb ndryshme n\u00eb nyjat e klasterit, pret rikthimin n\u00eb funksionim, rikthen nyj\u00ebn e d\u00ebshtuar dhe vazhdon testimin n\u00eb cik\u00ebl. Fillimisht ky projekt ishte quajtur hapgsql, por me kalimin e koh\u00ebs m\u00eb \u00ebsht\u00eb b\u00ebr\u00eb e m\u00ebrzitshme emri, n\u00eb t\u00eb cilin kishte vet\u00ebm nj\u00eb zanore. Prandaj, bazat e t\u00eb dh\u00ebnave t\u00eb q\u00ebndrueshme (dhe IP e peshkuar t\u00eb cilat i tregojn\u00eb ato) fillova t'i quaj krogan<\/strong> (karakter nga nj\u00eb loj\u00eb kompjuterike, ku t\u00eb gjith\u00eb organet e r\u00ebnd\u00ebsishme jan\u00eb t\u00eb dyfishuara), nd\u00ebrsa nyjat, klasteret dhe vet\u00eb projekti jan\u00eb quajtur tuchanka<\/strong> (planeti ku jetojn\u00eb krogan\u00ebt).<\/p>\n

<\/p>\n

Tani drejtuesit lejuan nd\u00ebrtimin e projektit p\u00ebr komunitetin open source n\u00ebn licenc\u00ebn MIT<\/a><\/noindex>. README do t\u00eb p\u00ebrkthhet n\u00eb anglisht s\u00eb shpejti (sepse pritet q\u00eb konsumator\u00ebt kryesor\u00eb t\u00eb jen\u00eb zhvilluesit e Pacemaker dhe PostgreSQL), dhe versioni i vjet\u00ebr n\u00eb rus t\u00eb README e kam vendosur ta organizoj (pjes\u00ebrisht) n\u00eb form\u00ebn e k\u00ebtij artikulli.<\/p>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/a><\/noindex><\/p>\n

Klaster\u00ebt krijohen n\u00eb virtualka VirtualBox<\/a><\/noindex>. N\u00eb total do t\u00eb krijohen 12 virtualka (n\u00eb total 36GiB), t\u00eb cilat do t\u00eb formojn\u00eb 4 grupe klaster t\u00eb q\u00ebndrueshme (versione t\u00eb ndryshme). Dy klaster\u00ebt e par\u00eb p\u00ebrb\u00ebhen nga dy servera PostgreSQL, t\u00eb cil\u00ebt vendosen n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave, dhe nj\u00eb server i p\u00ebrbashk\u00ebt witness<\/em> c quorum device<\/strong> (i vendosur n\u00eb nj\u00eb virtualke t\u00eb lir\u00eb n\u00eb qendr\u00ebn e tret\u00eb t\u00eb t\u00eb dh\u00ebnave), i cili zgjidh pasigurin\u00eb 50%\/50%<\/strong>, duke i dh\u00ebn\u00eb vot\u00ebn e tij nj\u00ebrit nga pal\u00ebt. Klasteri i tret\u00eb \u00ebsht\u00eb n\u00eb tre qendra t\u00eb t\u00eb dh\u00ebnave: nj\u00eb master, dy skllav\u00eb, pa quorum device<\/strong>. Klasteri i kat\u00ebrt p\u00ebrb\u00ebhet nga kat\u00ebr server\u00eb PostgreSQL, dy n\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave: nj\u00eb master dhe t\u00eb tjer\u00ebt replika, dhe gjithashtu p\u00ebrdor witness<\/em> c quorum device<\/strong>. Katri i kat\u00ebrt mbulon d\u00ebshtimin e dy server\u00ebve ose t\u00eb nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Ky zgjidhje mund t\u00eb zgjeroheshe n\u00eb nj\u00eb num\u00ebr m\u00eb t\u00eb madh replikash, n\u00ebse \u00ebsht\u00eb e nevojshme.<\/p>\n

<\/p>\n

Sh\u00ebrbimi i koh\u00ebs s\u00eb sakt\u00eb ntpd<\/a><\/noindex> gjithashtu \u00ebsht\u00eb konfigurue p\u00ebr q\u00ebndrueshm\u00ebri, por atje p\u00ebrdoren metoda e vet ntpd<\/code> (orphan mode<\/em>). Serveri i p\u00ebrgjithsh\u00ebm witness<\/em> luan rolin e serverit qendror NTP, duke shp\u00ebrndar\u00eb koh\u00ebn e tij p\u00ebr t\u00eb gjith\u00eb klaster\u00ebt, duke sinkronizuar k\u00ebshtu t\u00eb gjith\u00eb server\u00ebt mes tyre. N\u00ebse witness<\/em> d\u00ebshton ose \u00ebsht\u00eb i izoluar, at\u00ebher\u00eb nj\u00eb nga server\u00ebt e klasterit do t\u00eb filloj\u00eb t\u00eb shp\u00ebrndaj\u00eb koh\u00ebn e tij (brenda klasterit). Nj\u00eb HTTP proxy<\/strong> gjithashtu \u00ebsht\u00eb ngritur n\u00eb witness<\/em>, me ndihm\u00ebn e t\u00eb cil\u00ebs virtualkat e tjera kan\u00eb qasje n\u00eb depozit\u00eb Yum. N\u00eb realitet, sh\u00ebrbime t\u00eb tilla si koha e sakt\u00eb dhe proxy, me siguri do t\u00eb vendosen n\u00eb server\u00eb t\u00eb dedikuar, por n\u00eb sken\u00eb ato jan\u00eb vendosur n\u00eb witness<\/em> vet\u00ebm p\u00ebr kursimin e numrit t\u00eb virtualkave dhe hap\u00ebsir\u00ebs.<\/p>\n

<\/p>\n

Versionet<\/h1>\n

<\/p>\n

v0. Punon me CentOS 7 dhe PostgreSQL 11 n\u00eb VirtualBox 6.1.<\/p>\n

<\/p>\n

Struktura e klaster\u00ebve<\/h1>\n

<\/p>\n

T\u00eb gjitha klaster\u00ebt jan\u00eb t\u00eb destinuar p\u00ebr t'u vendosur n\u00eb disa qendra t\u00eb t\u00eb dh\u00ebnave, t\u00eb lidhura n\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb dhe duhet t\u00eb mb\u00ebshtesin d\u00ebshtimin ose izolimin rrjetor t\u00eb nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Prandaj nuk \u00ebsht\u00eb i mundur<\/strong> p\u00ebrdoret p\u00ebr t\u00eb mbrojtur nga split-brain<\/strong> teknologji standarde Pacemaker, e quajtur STONITH<\/em> (Shoq\u00ebrimi i Nj\u00eb Nj\u00ebsie Tjet\u00ebr n\u00eb Kok\u00eb) ose fencing<\/em>. Esenca e saj \u00ebsht\u00eb: n\u00ebse nyjet n\u00eb klaster fillojn\u00eb t\u00eb dyshojn\u00eb se ndonj\u00eb nyje ka ndodhur di\u00e7ka e \u00e7uditshme, nuk p\u00ebrgjigjet ose sillen n\u00eb m\u00ebnyr\u00eb jo korrekte, ato e \u00e7aktivizojn\u00eb at\u00eb p\u00ebrmes pajisjeve 't\u00eb jashtme', p\u00ebr shembull, kart\u00ebn kontrolluese IPMI ose UPS. Por kjo do t\u00eb funksionoj\u00eb vet\u00ebm n\u00eb rastet kur, n\u00eb rast d\u00ebshtimi t\u00eb vet\u00ebm t\u00eb serverit, IPMI ose UPS vazhdojn\u00eb t\u00eb funksionojn\u00eb. K\u00ebtu, gjithashtu parashikohet mbrojtja nga nj\u00eb d\u00ebshtim shum\u00eb m\u00eb katastrofik, kur d\u00ebshtojn\u00eb (p.sh. d\u00ebshtojn\u00eb n\u00eb energji) e gjith\u00eb qendra e t\u00eb dh\u00ebnave. N\u00eb rast t\u00eb nj\u00eb d\u00ebshtimi t\u00eb till\u00eb, t\u00eb gjitha stonith<\/em>- pajisjet (IPMI, UPS etj.) gjithashtu nuk do t\u00eb funksionojn\u00eb.<\/p>\n

<\/p>\n

N\u00eb vend t\u00eb k\u00ebsaj, sistemi bazohet n\u00eb iden\u00eb e kvorumit. T\u00eb gjitha nyjet kan\u00eb nj\u00eb z\u00eb, dhe mund t\u00eb punojn\u00eb vet\u00ebm ato q\u00eb shohin m\u00eb shum\u00eb se gjysm\u00eb n\u00eb t\u00eb gjitha nyjet. Ky num\u00ebr 'gjysm\u00eb+1' quhet kuorum<\/strong>. N\u00ebse nuk arrin t\u00eb arrihet kvorumi, at\u00ebher\u00eb nyja vendos se ndodhet n\u00eb izolim rrjetor dhe duhet t\u00eb \u00e7aktivizoj\u00eb burimet e saj, pra \u00ebsht\u00eb nj\u00eb mbrojtje nga split-brain<\/strong>. N\u00ebse softi q\u00eb p\u00ebrgjigjet p\u00ebr k\u00ebt\u00eb sjellje nuk funksionon, at\u00ebher\u00eb duhet t\u00eb aktivizohet watchdog, p\u00ebr shembull, n\u00eb baz\u00eb t\u00eb IPMI.<\/p>\n

<\/p>\n

N\u00ebse numri i nyjeve \u00ebsht\u00eb \u00e7ift (klaster n\u00eb dy data center), at\u00ebher\u00eb mund t\u00eb lind\u00eb nj\u00eb pasiguri e till\u00eb e quajtur. 50%\/50%<\/strong> (pes\u00ebdhjet\u00eb p\u00ebr pes\u00ebdhjet\u00eb<\/em>), kur izolimi rrjetor ndan klasterin pik\u00ebrisht n\u00eb mes. Prandaj, p\u00ebr num\u00ebr t\u00eb barabart\u00eb nyjesh, shtohet. quorum device<\/strong> \u2014 nj\u00eb demon i pad\u00ebshiruesh\u00ebm, i cili mund t\u00eb konceptohet n\u00eb makin\u00ebn virtuale m\u00eb t\u00eb lir\u00eb n\u00eb data center e tret\u00eb. Ai i jep vot\u00ebn nj\u00ebrit prej segmenteve (q\u00eb sheh) dhe k\u00ebshtu zgjidh pasigurin\u00eb 50%\/50%. Serveri ku do t\u00eb aktivizohet pajisja e quorum, un\u00eb e quajta. witness<\/em> (terminologji nga repmgr, m\u00eb p\u00eblqeu).<\/p>\n

<\/p>\n

Burimet mund t\u00eb l\u00ebvizin nga nj\u00eb vend n\u00eb tjetrin, p\u00ebr shembull, nga server\u00ebt e prishur n\u00eb ato t\u00eb rregullt, ose me urdh\u00ebr nga administratoret e sistemeve. Q\u00eb klient\u00ebt t\u00eb din\u00eb se ku ndodhen burimet q\u00eb u nevojiten (ku duhet t\u00eb lidhen?), p\u00ebrdoren. IP t\u00eb l\u00ebvizshme<\/em> (float IP<\/strong>). K\u00ebto jan\u00eb IP q\u00eb Pacemaker mund t'i l\u00ebviz\u00eb mes nyjeve (t\u00eb gjitha ndodhen n\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb). \u00c7dora nj\u00eb prej tyre simbolizon nj\u00eb burim (sh\u00ebrbim) dhe do t\u00eb jet\u00eb aty ku duhet t\u00eb lidheni p\u00ebr t\u00eb pasur qasje n\u00eb k\u00ebt\u00eb sh\u00ebrbim (n\u00eb rastin ton\u00eb, DB).<\/p>\n

<\/p>\n

Tuchanka1 (skema me ngjeshje)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Ideja ishte q\u00eb kishim shum\u00eb baza t\u00eb vogla t\u00eb dh\u00ebnash me ngarkes\u00eb t\u00eb ul\u00ebt, p\u00ebr t\u00eb cilat nuk \u00ebsht\u00eb e leverdishme t\u00eb mbash nj\u00eb server t\u00eb dedikuar slave n\u00eb modalitetin hot standby p\u00ebr transaksionet read only (nuk ka nevoj\u00eb p\u00ebr nj\u00eb shp\u00ebrdorim t\u00eb till\u00eb burimesh).<\/p>\n

<\/p>\n

N\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave ka nj\u00eb server. N\u00eb \u00e7do server ka dy instanca PostgreSQL (n\u00eb terminologjin\u00eb e PostgreSQL ato quhen klastere, por p\u00ebr t\u00eb shmangur konfuzionin do t'i quaj instanca (n\u00eb p\u00ebrputhje me DB t\u00eb tjera), nd\u00ebrsa klastere do t'i quaj vet\u00ebm klasteret Pacemaker). Nj\u00eb instanc\u00eb punon si master dhe vet\u00ebm ajo ofron sh\u00ebrbime (vet\u00ebm ajo ka IP flotante). Instanca tjet\u00ebr punon si skllave p\u00ebr qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave dhe do t\u00eb ofroj\u00eb sh\u00ebrbime vet\u00ebm n\u00ebse masteri bie. Duke qen\u00eb se p\u00ebr t\u00eb shumt\u00ebn e koh\u00ebs do t\u00eb ofrohet sh\u00ebrbim (do t\u00eb ekzekutohen k\u00ebrkesa) vet\u00ebm nga nj\u00eb instanc\u00eb nga dy (master), t\u00eb gjitha burimet e serverit optimizohen p\u00ebr master (kapaciteti dedikohet p\u00ebr kesh shared_buffers etj.), por gjithashtu kur \u00ebsht\u00eb e nevojshme, ka burime t\u00eb mjaftueshme edhe p\u00ebr instanc\u00ebn tjet\u00ebr (edhe n\u00ebse p\u00ebr nj\u00eb pun\u00eb jo optimale p\u00ebrmes keshit t\u00eb sistemit t\u00eb skedar\u00ebve) p\u00ebr rastin e d\u00ebshtimit t\u00eb nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave. Skllavi nuk ofron sh\u00ebrbime (nuk ekzekuton k\u00ebrkesa vet\u00ebm p\u00ebr lexim) gjat\u00eb funksionimit normal t\u00eb klasterit, p\u00ebr t\u00eb shmangur luft\u00ebn p\u00ebr burimet me masterin n\u00eb t\u00eb nj\u00ebjtin server.<\/p>\n

<\/p>\n

N\u00eb rastin e dy nyjave, q\u00ebndrueshm\u00ebria ndaj d\u00ebshtimeve \u00ebsht\u00eb e mundur vet\u00ebm me replikim asinkron, sepse n\u00eb rastin e replikimit sinkron, d\u00ebshtimi i skllavit do t\u00eb \u00e7onte n\u00eb ndalimin e masterit.<\/p>\n

<\/p>\n

D\u00ebshtimi i witness<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

D\u00ebshtimi i witness (quorum device<\/em>) do ta shqyrtoj vet\u00ebm p\u00ebr klasterin Tuchanka1, me t\u00eb gjitha t\u00eb tjer\u00ebt do t\u00eb jet\u00eb e nj\u00ebjta histori. N\u00eb rast d\u00ebshtimi t\u00eb witness, struktura e klasterit nuk do t\u00eb ndryshoj\u00eb, gjith\u00e7ka do t\u00eb vazhdoj\u00eb t\u00eb funksionoj\u00eb si\u00e7 ka punuar. Por kvorumi do t\u00eb b\u00ebhet 2 nga 3, dhe p\u00ebr k\u00ebt\u00eb arsye \u00e7do d\u00ebshtim tjet\u00ebr do t\u00eb b\u00ebhet fatal p\u00ebr klasterin. Sidoqoft\u00eb, do t\u00eb duhet t\u00eb riparoni urgjentisht.<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka1<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

D\u00ebshtimi i nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave p\u00ebr Tuchanka1. N\u00eb k\u00ebt\u00eb rast witness<\/em> i jep vot\u00ebn e tij nyj\u00ebs s\u00eb dyt\u00eb n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave. Atje, skllavi i dikursh\u00ebm shnd\u00ebrrohet n\u00eb master, si rezultat, t\u00eb dy master\u00ebt punojn\u00eb n\u00eb t\u00eb nj\u00ebjtin server dhe t\u00eb dy IP-t\u00eb e tyre flotante i drejtohen atyre.<\/p>\n

<\/p>\n

Tuchanka2 (klasike)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Schema klasike me dy nyja. N\u00eb nj\u00eb nyje punon masteri, n\u00eb t\u00eb tjer\u00ebn skllavi. T\u00eb dy mund t\u00eb ekzekutojn\u00eb k\u00ebrkesa (skllavi vet\u00ebm k\u00ebrkesa p\u00ebr lexim), ndaj t\u00eb dy i drejtohen IP flotante: krogan2 \u2014 p\u00ebr master, krogan2s1 \u2014 p\u00ebr skllavin. Do t\u00eb ket\u00eb q\u00ebndrueshm\u00ebri ndaj d\u00ebshtimeve p\u00ebr t\u00eb dy, masterin dhe skllavin.<\/p>\n

<\/p>\n

N\u00eb rastin e dy nyjave, q\u00ebndrueshm\u00ebria ndaj d\u00ebshtimeve \u00ebsht\u00eb e mundur vet\u00ebm me replikim asinkron, sepse n\u00eb rastin e replikimit sinkron, d\u00ebshtimi i skllavit do t\u00eb \u00e7onte n\u00eb ndalimin e masterit.<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka2<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

N\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave witness<\/em> votimi p\u00ebr t\u00eb dytin. N\u00eb qendr\u00ebn e vetme funksionale t\u00eb t\u00eb dh\u00ebnave do t\u00eb ngrihet masteri, dhe t\u00eb dy IP-t\u00eb fluturues do t\u00eb tregojn\u00eb n\u00eb t\u00eb: masteri dhe skllavi. Sigurisht, instance duhet t\u00eb jet\u00eb e konfiguruar n\u00eb nj\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb ket\u00eb burime t\u00eb mjaftueshme (p\u00ebr kufizimet n\u00ebn lidhje etj.) p\u00ebr t\u00eb pranuar n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb t\u00eb gjitha lidhjet dhe k\u00ebrkesat nga masteri dhe skllavi. Prandaj, gjat\u00eb funksionimit normal, ai duhet t\u00eb ket\u00eb nj\u00eb rezerv\u00eb t\u00eb mjaftueshme p\u00ebr kufizimet.<\/p>\n

<\/p>\n

Tuchanka4 (shum\u00eb skllev\u00ebr)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Kjo \u00ebsht\u00eb nj\u00eb tjet\u00ebr ekstrem. Ka Baza t\u00eb Dh\u00ebnash ku ka shum\u00eb k\u00ebrkesa read-only (rasisti tipik i nj\u00eb uebi me ngarkes\u00eb t\u00eb lart\u00eb). Tuchanka4 \u00ebsht\u00eb situata kur skllev\u00ebr mund t\u00eb jen\u00eb tre ose m\u00eb shum\u00eb p\u00ebr t\u00eb trajtuar k\u00ebto k\u00ebrkesa, por p\u00ebr t\u00eb mos pasur shum\u00eb. Kur ka nj\u00eb num\u00ebr shum\u00eb t\u00eb madh skllev\u00ebr, do t\u00eb duhet t\u00eb shpikni nj\u00eb sistem hierarkik replikimi. N\u00eb rastin minimal (n\u00eb figur\u00eb) n\u00eb secil\u00ebn prej dy qendrave t\u00eb t\u00eb dh\u00ebnave ndodhen nga dy server\u00eb, n\u00eb secilin prej t\u00eb cil\u00ebve ka nga nj\u00eb instance PostgreSQL.<\/p>\n

<\/p>\n

Nj\u00eb ve\u00e7ori tjet\u00ebr e k\u00ebsaj skeme \u00ebsht\u00eb se k\u00ebtu mund t\u00eb organizohet nj\u00eb replikim i nj\u00ebansh\u00ebm. Ai \u00ebsht\u00eb konfiguruar n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb replikoj\u00eb, sa m\u00eb shum\u00eb t\u00eb jet\u00eb e mundur, n\u00eb nj\u00eb qend\u00ebr t\u00eb dh\u00ebnash tjet\u00ebr, dhe jo n\u00eb nj\u00eb replik\u00eb n\u00eb t\u00eb nj\u00ebjt\u00ebn qend\u00ebr t\u00eb dh\u00ebnash si masteri. N\u00eb master dhe n\u00eb secilin skllav tregohet IP fluturuese. N\u00eb rastin ideal, mes skllev\u00ebrve do t\u00eb duhet t\u00eb b\u00ebhet balancimi i k\u00ebrkesave me ndonj\u00eb sql proxy<\/em>, p\u00ebr shembull, n\u00eb an\u00ebn e klientit. Nj\u00eb lloj i ndrysh\u00ebm klient\u00ebsh mund t\u00eb k\u00ebrkoj\u00eb nj\u00eb lloj t\u00eb ndrysh\u00ebm sql proxy<\/em>, dhe vet\u00ebm zhvilluesit e klient\u00ebve e din\u00eb se kujt i nevojitet \u00e7far\u00eb. Kjo funksionalitet mund t\u00eb realizohet si nga nj\u00eb demon t\u00eb jasht\u00ebm, ashtu edhe nga nj\u00eb bibliotek\u00eb klienti (connection pool), etj. T\u00eb gjitha k\u00ebto dalin jasht\u00eb k\u00ebsaj teme t\u00eb klas\u00ebs s\u00eb dh\u00ebnash me toleranc\u00eb ndaj d\u00ebshtimit (toleranc\u00eb ndaj d\u00ebshtimit SQL proxy<\/em> mund t\u00eb realizohet n\u00eb m\u00ebnyr\u00eb t\u00eb pavarur, s\u00eb bashku me toleranc\u00ebn e klientit).<\/p>\n

<\/p>\n

D\u00ebshtimi Tuchanka4<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Kur ndodh d\u00ebshtimi i nj\u00eb qendre t\u00eb dh\u00ebnash (dmth. dy server\u00eb), witness voton p\u00ebr t\u00eb dytin. Si rezultat, n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave funksionojn\u00eb dy server\u00eb: n\u00eb nj\u00eb funksionon masteri, dhe n\u00eb t\u00eb tregohet IP fluturuese p\u00ebr masterin (p\u00ebr t\u00eb pranuar k\u00ebrkesa read-write); dhe n\u00eb serverin e dyt\u00eb funksionon skllavi me replikim t\u00eb nj\u00ebansh\u00ebm, dhe n\u00eb t\u00eb tregohet nj\u00eb nga IP-t\u00eb flutruese t\u00eb skllavit (p\u00ebr k\u00ebrkesat read only).<\/p>\n

<\/p>\n

E para q\u00eb duhet t\u00eb theksohet: IP fluturuese e skllavit do t\u00eb jet\u00eb vet\u00ebm nj\u00eb, dhe p\u00ebr funksionim t\u00eb duhur me t\u00eb, do t\u00eb nevojitet q\u00eb sql proxy<\/em> ka drejtonte t\u00eb gjitha k\u00ebrkesat n\u00eb IP-n\u00eb e mbetur float; dhe n\u00ebse sql proxy<\/em> jo, mund t\u00eb renditni t\u00eb gjitha IP-t\u00eb float t\u00eb skllev\u00ebrve me presje n\u00eb URL p\u00ebr lidhje. N\u00eb k\u00ebt\u00eb rast me libpq<\/em> lidhja do t\u00eb jet\u00eb me IP-n\u00eb e par\u00eb punuese, ashtu si\u00e7 \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb sistemin e testimit automatik. Ndoshta, n\u00eb biblioteka t\u00eb tjera, si JDBC, kjo nuk do t\u00eb funksionoj\u00eb dhe \u00ebsht\u00eb e nevojshme sql proxy<\/em>. Kjo \u00ebsht\u00eb b\u00ebr\u00eb sepse ka nj\u00eb ndalim p\u00ebr t\u00eb ngritur nj\u00ebkoh\u00ebsisht IP-t\u00eb float p\u00ebr skllev\u00ebrit n\u00eb nj\u00eb server, p\u00ebr t'i shp\u00ebrndar\u00eb ato n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00eb server\u00ebt e skllev\u00ebrve, n\u00ebse punohet me disa.<\/p>\n

<\/p>\n

E dyta: madje n\u00eb rastin e d\u00ebshtimit t\u00eb qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave, do t\u00eb ruhet replikimi sinkron. Dhe madje n\u00ebse ndodh nj\u00eb d\u00ebshtim i dyt\u00eb, dometh\u00ebn\u00eb n\u00eb qendr\u00ebn e mbetur, nj\u00eb nga dy server\u00ebt d\u00ebshtojn\u00eb, klasteri edhe pse do t\u00eb ndaloj\u00eb ofrimin e sh\u00ebrbimeve, do t\u00eb ruaj\u00eb informacionin p\u00ebr t\u00eb gjitha transaksionet e angazhuara, p\u00ebr t\u00eb cilat ai dha nj\u00eb konfirmim p\u00ebr angazhimin (nuk do t\u00eb ket\u00eb humbje informacioni n\u00eb rastin e d\u00ebshtimit t\u00eb dyt\u00eb).<\/p>\n

<\/p>\n

Tuchanka3 (3 qendra t\u00eb dh\u00ebnash)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Ky \u00ebsht\u00eb nj\u00eb klaster p\u00ebr nj\u00eb situat\u00eb kur ka tre qendra t\u00eb plota t\u00eb t\u00eb dh\u00ebnave n\u00eb funksionim, n\u00eb secil\u00ebn prej t\u00eb cilave ka nj\u00eb server t\u00eb DB n\u00eb funksionim. N\u00eb k\u00ebt\u00eb rast quorum device<\/em> nuk \u00ebsht\u00eb e nevojshme. N\u00eb nj\u00eb qend\u00ebr t\u00eb t\u00eb dh\u00ebnave punon masteri, n\u00eb dy t\u00eb tjera jan\u00eb skllev\u00ebr. Replikimi \u00ebsht\u00eb sinkron, lloji ANY (slave1, slave2), dometh\u00ebn\u00eb klienti do t\u00eb marr\u00eb konfirmimin e angazhimit, kur ndonj\u00eb nga skllev\u00ebrit e para t\u00eb p\u00ebrgjigjet q\u00eb ka pranuar angazhimin. Burimet indikojn\u00eb nj\u00eb IP float p\u00ebr masterin dhe dy p\u00ebr skllev\u00ebrit. Ndryshe nga Tuchanka4, t\u00eb gjitha tre IP-t\u00eb float jan\u00eb t\u00eb disponueshme. P\u00ebr balancimin e k\u00ebrkesave SQL read-only mund t\u00eb p\u00ebrdorin sql proxy<\/em> (me disponueshm\u00ebri t\u00eb ve\u00e7ant\u00eb), ose t\u00eb caktuar nj\u00eb IP float skllev\u00ebr p\u00ebr gjysm\u00ebn e klient\u00ebve, nd\u00ebrsa gjysm\u00ebs tjet\u00ebr nj\u00eb IP float tjet\u00ebr.<\/p>\n

<\/p>\n

D\u00ebshtimi Tuchanka3<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

N\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00eb nga qendrat e t\u00eb dh\u00ebnave, mbeten dy. Nj\u00ebra ka ngritur masterin dhe IP-n\u00eb float nga masteri, n\u00eb tjetr\u00ebn ka skllev\u00ebr dhe t\u00eb dyja IP-t\u00eb float t\u00eb skllev\u00ebrve (n\u00eb instanc\u00eb duhet t\u00eb ket\u00eb rezerv\u00eb dyfish p\u00ebr burimet, p\u00ebr t\u00eb pranuar t\u00eb gjitha lidhjet nga t\u00eb dyja IP-t\u00eb float t\u00eb skllev\u00ebrve). Nd\u00ebrmjet master\u00ebve dhe skllev\u00ebrit ekziston replikimi sinkron. Gjithashtu klasteri do t\u00eb ruaj\u00eb informacionin p\u00ebr transaksionet e angazhuara dhe t\u00eb konfirmuara (nuk do t\u00eb ket\u00eb humbje informacioni) n\u00eb rastin e shkat\u00ebrrimit t\u00eb dy qendrave t\u00eb t\u00eb dh\u00ebnave (n\u00ebse ato jan\u00eb shkat\u00ebrruar jo nj\u00ebkoh\u00ebsisht).<\/p>\n

<\/p>\n

Un\u00eb vendosa t\u00eb mos p\u00ebrfshij nj\u00eb p\u00ebrshkrim t\u00eb detajuar t\u00eb struktur\u00ebs s\u00eb skedar\u00ebve dhe shp\u00ebrndarjes. Kush do t\u00eb doj\u00eb t\u00eb eksperimentoj\u00eb, mund ta lexoj\u00eb t\u00eb gjith\u00eb k\u00ebt\u00eb n\u00eb README. Un\u00eb po jap vet\u00ebm p\u00ebrshkrimin e testimit automatik.<\/em><\/p>\n

<\/p>\n

Sistemi i testimit automatizuar<\/h1>\n

<\/p>\n

P\u00ebr t\u00eb verifikuar q\u00ebndrueshm\u00ebrin\u00eb e klaster\u00ebve me simuluar defekte t\u00eb ndryshme u krijua nj\u00eb sistem testimi automatik. Aktivizohet me nj\u00eb skript test\/failure<\/code>. Skripti mund t\u00eb pranoj\u00eb si parametra numrat e klaster\u00ebve q\u00eb d\u00ebshironi t\u00eb testoni. P\u00ebr shembull, kjo komand\u00eb:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
do t\u00eb testoj\u00eb vet\u00ebm klasterin e dyt\u00eb dhe t\u00eb tret\u00eb. N\u00ebse parametrat nuk jan\u00eb t\u00eb specifikuar, t\u00eb gjitha klaster\u00ebt do t\u00eb testohen. T\u00eb gjitha klaster\u00ebt testohen paralelisht, dhe rezultati shfaqet n\u00eb panelin tmux. Tmux p\u00ebrdor nj\u00eb server t\u00eb dedikuar tmux, k\u00ebshtu q\u00eb skripti mund t\u00eb aktivizohet nga tmux default, duke krijuar nj\u00eb tmux t\u00eb brendsh\u00ebm. Rekomandoj t\u00eb p\u00ebrdorni terminalin n\u00eb nj\u00eb dritare t\u00eb madhe dhe me nj\u00eb shkronj\u00eb t\u00eb vog\u00ebl. Para fillimit t\u00eb testimit, t\u00eb gjitha virtualkat rikthehen n\u00eb nj\u00eb snapshot n\u00eb momentin kur skripti p\u00ebrfundon. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelimi<\/p>\n
<\/p>\n
Terminali \u00ebsht\u00eb ndar\u00eb n\u00eb kolona n\u00eb p\u00ebrputhje me numrin e klaster\u00ebve q\u00eb po testohen, n\u00eb parazgjedhje (n\u00eb screenshot) ato jan\u00eb kat\u00ebr. Un\u00eb do ta shqiptoj p\u00ebrmbajtjen e kolonave me shembullin Tuchanka2. Panelet n\u00eb screenshot jan\u00eb t\u00eb num\u00ebruara:<\/p>\n
<\/p>\n
    \n
  1. K\u00ebtu shfaqet statistika mbi testet. Kolonat:\n