Na nevojitet monitorim shtes\u00eb p\u00ebr funksionimin e failover-it, p\u00ebr k\u00ebt\u00eb kemi 12 sharda PostgreSQL, q\u00eb do t\u00eb thot\u00eb se duhet t\u00eb monitorojm\u00eb 12 klaster\u00eb. Me rritjen e numrit t\u00eb shardeve, duhet t\u00eb mos harrojm\u00eb t\u00eb p\u00ebrdit\u00ebsojm\u00eb gjithashtu edhe failover-in.<\/li>\n<\/ul>\nFailover-i i shkruar n\u00eb m\u00ebnyr\u00eb manuale duket shum\u00eb i komplikuar dhe k\u00ebrkon mb\u00ebshtetje jo triviale. Me nj\u00eb klaster PostgreSQL, kjo do t\u00eb ishte opsioni m\u00eb i thjesht\u00eb, por nuk \u00ebsht\u00eb i shkall\u00ebzuar, prandaj nuk na p\u00ebrshtatet.<\/p>\n
Repmgr<\/h3>\n Replication Manager p\u00ebr grupe PostgreSQL, i cili di t\u00eb menaxhoj\u00eb pun\u00ebn e grupit PostgreSQL. Megjithat\u00eb, nuk ka nj\u00eb automatik p\u00ebrfailje \"jasht\u00eb kutis\u00eb\", prandaj do t\u00eb nevojitet t\u00eb shkruani nj\u00eb \"mb\u00ebshtjell\u00ebs\" mbi zgjidhjen e gatshme. K\u00ebshtu q\u00eb gjith\u00e7ka mund t\u00eb jet\u00eb edhe m\u00eb e komplikuar se me skenar\u00ebt e shkruar vet\u00eb, prandaj ne as q\u00eb e provuam Repmgr.<\/p>\n
AWS RDS<\/h3>\n Mb\u00ebshtet gjith\u00e7ka q\u00eb na nevojitet, di t\u00eb b\u00ebj\u00eb kopje rezerv\u00eb dhe mb\u00ebshtet grupin e lidhjeve. Ka nj\u00eb kalim automatik: kur nd\u00ebrron masteri, riplika b\u00ebhet masteri i ri dhe AWS ndryshon regjistrimin DNS n\u00eb masterin e ri, nd\u00ebrkoh\u00eb q\u00eb replikat mund t\u00eb ndodhen n\u00eb AZ t\u00eb ndryshme.<\/p>\n
Si\u00e7 t\u00eb met\u00eb mund t\u00eb p\u00ebrmendim munges\u00ebn e konfigurimeve t\u00eb detajuara. Si nj\u00eb shembull i konfigurimeve t\u00eb detajuara: n\u00eb instancat tona ka kufizime p\u00ebr lidhjet TCP, \u00e7ka fatkeq\u00ebsisht nuk mund t\u00eb realizohet n\u00eb RDS:<\/p>\n
net.ipv4.tcp_keepalive_time=10\nnet.ipv4.tcp_keepalive_intvl=1\nnet.ipv4.tcp_keepalive_probes=5\nnet.ipv4.tcp_retries2=3\n<\/code><\/pre>\nP\u00ebrve\u00e7 k\u00ebsaj, \u00e7mimi i AWS RDS \u00ebsht\u00eb gati dy her\u00eb m\u00eb i lart\u00eb se \u00e7mimi normal i instanc\u00ebs, q\u00eb ishte arsyeja kryesore p\u00ebr t\u00eb hequr dor\u00eb nga kjo zgjidhje.<\/p>\n
Patroni<\/h3>\n Ky \u00ebsht\u00eb nj\u00eb model n\u00eb Python p\u00ebr menaxhimin e PostgreSQL me dokumentacion t\u00eb mir\u00eb, automatik p\u00ebrfailje dhe kod burimi n\u00eb GitHub.<\/p>\n
Avantazhet e Patroni:<\/p>\n
\n\u00c7do parametr i konfigurimit \u00ebsht\u00eb i detajuar, duke shpjeguar si funksionon \u00e7do gj\u00eb;<\/li>\n Failover automatik punon nga kutia;<\/li>\n I shkruar n\u00eb Python, dhe duke qen\u00eb se ne po shkruajm\u00eb shum\u00eb n\u00eb Python, do na jet\u00eb m\u00eb e leht\u00eb t\u00eb merremi me problemet dhe ndoshta madje t\u00eb ndihmojm\u00eb n\u00eb zhvillimin e projektit;<\/li>\n Menaxhon plot\u00ebsisht PostgreSQL, lejon ndryshimin e konfiguracionit menj\u00ebher\u00eb n\u00eb t\u00eb gjitha nodet e klasterit, dhe n\u00ebse p\u00ebr t\u00eb zbatuar konfigurimin e ri k\u00ebrkohet ri-nisja e klasterit, at\u00ebher\u00eb mund ta b\u00ebjm\u00eb p\u00ebrs\u00ebri me ndihm\u00ebn e Patroni.<\/li>\n<\/ul>\nDisavantazhet:<\/p>\n
\nNga dokumentacioni nuk \u00ebsht\u00eb e qart\u00eb si t\u00eb punosh sakt\u00ebsisht me PgBouncer. Megjithat\u00eb, \u00ebsht\u00eb e v\u00ebshtir\u00eb ta quash k\u00ebt\u00eb si nj\u00eb minus, sepse detyra e Patroni \u00ebsht\u00eb t\u00eb menaxhoj\u00eb PostgreSQL, dhe si do t\u00eb kalojn\u00eb lidhjet me Patroni \u2014 \u00ebsht\u00eb problemi yn\u00eb;<\/li>\n Ka pak shembuj t\u00eb implementimit t\u00eb Patroni n\u00eb volumen t\u00eb madh, nd\u00ebrsa ka shum\u00eb shembuj t\u00eb implementimit nga e para.<\/li>\n<\/ul>\nN\u00eb fund, p\u00ebr krijimin e nj\u00eb klasteri t\u00eb q\u00ebndruesh\u00ebm, ne zgjodh\u00ebm pik\u00ebrisht Patroni.<\/p>\n
Procesi i implementimit t\u00eb Patroni<\/h2>\n Para Patroni kishim 12 sharded PostgreSQL n\u00eb konfigurimin nj\u00eb master dhe nj\u00eb replik\u00eb me replikim asinkron. Server\u00ebt e aplikacioneve lidhen me bazat e t\u00eb dh\u00ebnave p\u00ebrmes Network Load Balancer, pas t\u00eb cilit ishin dy instance me PgBouncer, dhe pas tyre ndodheshin t\u00eb gjith\u00eb server\u00ebt PostgreSQL.
P\u00ebr t\u00eb implementuar Patroni, na duhej t\u00eb zgjidhim nj\u00eb ruajtje t\u00eb shp\u00ebrndar\u00eb p\u00ebr konfigurimin e klasterit. Patroni punon me sisteme t\u00eb shp\u00ebrndara p\u00ebr ruajtjen e konfigurimeve, t\u00eb tilla si etcd, Zookeeper, Consul. Ne kemi nj\u00eb klaster t\u00eb plot\u00eb Consul n\u00eb prodhim, i cili funksionon n\u00eb lidhje me Vault, dhe p\u00ebrndryshe nuk e p\u00ebrdorim. Nj\u00eb mund\u00ebsi e shk\u00eblqyer p\u00ebr t\u00eb filluar ta p\u00ebrdorim Consul p\u00ebr q\u00ebllimin e tij.<\/p>\n
Si funksionon Patroni me Consul<\/h3>\n Ne kemi nj\u00eb klaster Consul, i cili p\u00ebrb\u00ebhet nga tre node dhe nj\u00eb klaster Patroni, i cili p\u00ebrb\u00ebhet nga nj\u00eb lider dhe nj\u00eb replik\u00eb (n\u00eb Patroni, masteri quhet lider klasteri, nd\u00ebrsa skllav\u00ebt quhen replika). \u00c7do instanc\u00eb e klasterit Patroni vazhdimisht d\u00ebrgon n\u00eb Consul informacion mbi gjendjen e klasterit. Prandaj, nga Consul gjithmon\u00eb mund t\u00eb m\u00ebsojm\u00eb konfigurimin aktual t\u00eb klasterit Patroni dhe se kush \u00ebsht\u00eb lideri n\u00eb k\u00ebt\u00eb moment.<\/p>\n
P\u00ebr t\u00eb lidhur Patroni me Consul, mjafton t\u00eb studiojm\u00eb dokumentacionin zyrtar, ku thuhet se duhet t\u00eb tregojm\u00eb hostin n\u00eb formatin http ose https, var\u00ebsisht se si punojm\u00eb me Consul, dhe skem\u00ebn e lidhjes, opsionale:<\/p>\n
host: host:port p\u00ebr pik\u00ebn e fundit Consul, n\u00eb formatin: http(s):\/\/host:port\nscheme: (opsionale) http ose https, me parazgjedhje http<\/code><\/pre>\nDuket e thjesht\u00eb, por k\u00ebtu fillojn\u00eb problemet kapitale. Me Consul ne punojm\u00eb p\u00ebrmes nj\u00eb lidhjeje t\u00eb sigurt p\u00ebrmes https dhe konfigurimi yn\u00eb i lidhjes do t\u00eb duket si m\u00eb posht\u00eb:<\/p>\n
consul:\n host: https:\/\/server.production.consul:8080 \n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nPor nuk funksionon k\u00ebshtu. Gjat\u00eb nisjes, Patroni nuk mund t\u00eb lidhet me Consul, sepse p\u00ebrpiqet t\u00eb shkoj\u00eb ende p\u00ebrmes http.<\/p>\n
T\u00eb kuptosh problemin ndihmoi kodi burimor i Patroni. \u00cbsht\u00eb mir\u00eb q\u00eb \u00ebsht\u00eb shkruar n\u00eb python. Duket se parametri host nuk analizoi asnj\u00ebher\u00eb, dhe protokolli duhet t\u00eb specifikohet n\u00eb scheme. K\u00ebshtu duket blloku i pun\u00ebs konfigurues p\u00ebr t\u00eb punuar me Consul tek ne:<\/p>\n
consul:\n host: server.production.consul:8080\n scheme: https\n verify: true\n cacert: {{ consul_cacert }}\n cert: {{ consul_cert }}\n key: {{ consul_key }}<\/code><\/pre>\nConsul-template<\/h3>\n Pra, kemi zgjedhur magazin\u00ebn p\u00ebr konfigurim. Tani duhet t\u00eb kuptojm\u00eb se si PgBouncer do t\u00eb kaloj\u00eb konfigurimin e tij kur t\u00eb ndryshoj\u00eb lideri n\u00eb klasterin Patroni. N\u00eb dokumentacionin p\u00ebr k\u00ebt\u00eb pyetje nuk ka p\u00ebrgjigje, sepse aty nuk \u00ebsht\u00eb p\u00ebrshkruar puna me PgBouncer n\u00eb thelb.<\/p>\n
N\u00eb k\u00ebrkim t\u00eb nj\u00eb zgjidhjeje, gjet\u00ebm nj\u00eb artikull (emri, p\u00ebr fat t\u00eb keq, nuk m\u00eb vjen n\u00eb mendje), ku ishte shkruar se Consul-template ndihmonte shum\u00eb n\u00eb lidhjen midis PgBouncer dhe Patroni. Kjo na nxit t\u00eb studiojm\u00eb pun\u00ebn e Consul-template.<\/p>\n
Doli, q\u00eb Sonsul-template monitoron vazhdimisht konfigurimin e klasterit PostgreSQL n\u00eb Sonsul. Kur ndalon lideri, ajo p\u00ebrdit\u00ebson konfigurimin e PgBouncer dhe d\u00ebrgon nj\u00eb komand\u00eb p\u00ebr ta rinisur at\u00eb.<\/p>\n
Nj\u00eb p\u00ebrfitim i madh i template \u00ebsht\u00eb se ai ruhet si kod, prandaj kur shtohet nj\u00eb shard i ri, mjafton t\u00eb b\u00ebhet nj\u00eb komit i ri dhe t\u00eb p\u00ebrdit\u00ebsohet template n\u00eb m\u00ebnyr\u00eb automatike, duke mb\u00ebshtetur parimin e Infrastruktur\u00ebs si Kod.<\/p>\n
Arkitektura e re me Patroni<\/h3>\n Si rezultat, ne mor\u00ebm k\u00ebt\u00eb skem\u00eb pune:
T\u00eb gjitha serverat e aplikacionit i drejtohen balancuesit \u2192 pas tij q\u00ebndrojn\u00eb dy instance PgBouncer \u2192 n\u00eb \u00e7do instance \u00ebsht\u00eb e aktivizuar Sonsul-template, e cila monitoron gjendjen e \u00e7do klasteri Patroni dhe kontrollon aktualitetin e konfigurations s\u00eb PgBouncer, e cila d\u00ebrgon k\u00ebrkesat te lideri aktual i \u00e7do klasteri.<\/p>\n
Testimi manual<\/h3>\n K\u00ebt\u00eb skem\u00eb para l\u00ebshimit n\u00eb prodhim, e kemi drejtuar n\u00eb nj\u00eb ambient t\u00eb vog\u00ebl testimi dhe kemi verifikuar funksionimin e kalimit automatizuar. Hap\u00ebm tabel\u00ebn, l\u00ebviz\u00ebm sticker-in dhe n\u00eb at\u00eb moment \u201cvritnim\u201d liderin e klasterit. N\u00eb AWS, p\u00ebr k\u00ebt\u00eb mjafton t\u00eb fiket instance p\u00ebrmes konsol\u00ebs.<\/p>\n
Stickeri u rikthej brenda 10-20 sekondave, dhe pastaj filloi p\u00ebrs\u00ebri t\u00eb l\u00ebviz\u00eb normalisht. K\u00ebshtu q\u00eb, klasteri Patroni ka funksionuar si\u00e7 duhet: nd\u00ebroi liderin, d\u00ebrgoi informacionin n\u00eb Consul, dhe Consul-template e kap at\u00eb informacion menj\u00ebher\u00eb, z\u00ebvend\u00ebsoi konfigurimin e PgBouncer dhe d\u00ebrgoi komand\u00ebn p\u00ebr reload.<\/p>\n
Si t\u00eb mbijetosh n\u00ebn ngarkes\u00eb t\u00eb lart\u00eb dhe t\u00eb ruash minimumin e koh\u00ebs s\u00eb papun\u00ebsis\u00eb?<\/h2>\n Punon gjith\u00e7ka shk\u00eblqyer! Por shfaqen pyetje t\u00eb reja: Si do t\u00eb funksionoj\u00eb n\u00ebn ngarkes\u00eb t\u00eb lart\u00eb? Si t\u00eb implementojm\u00eb gjith\u00e7ka shpejt dhe sigurt n\u00eb production?<\/p>\n
P\u00ebr t\u00eb p\u00ebrgjigjur pyetjes s\u00eb par\u00eb, na ndihmon mjedisi testues, ku b\u00ebjm\u00eb testimin e ngarkes\u00ebs. Ai \u00ebsht\u00eb plot\u00ebsisht identik me production n\u00eb arkitektur\u00eb dhe ka t\u00eb dh\u00ebna testuese t\u00eb gjeneruara, q\u00eb n\u00eb volum jan\u00eb p\u00ebraf\u00ebrsisht t\u00eb barabarta me produksionin. Ne e zgjidhim thjesht ta \"vrasim\" nj\u00eb nga masterat e PostgreSQL gjat\u00eb testit dhe t\u00eb shohim se \u00e7far\u00eb do t\u00eb ndodh\u00eb. Por para k\u00ebsaj, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kontrollojm\u00eb automatizimin e roll-out-it, sepse n\u00eb k\u00ebt\u00eb mjedis kemi disa shard-e PostgreSQL, k\u00ebshtu q\u00eb do t\u00eb marrim nj\u00eb testim t\u00eb shk\u00eblqyer t\u00eb skripteve konfigurimi para produksionit.<\/p>\n
T\u00eb dyja detyrat duken ambicioze, por ne kemi PostgreSQL 9.6. Ndoshta mund t\u00eb azhurnohemi direkt n\u00eb 11.2?<\/p>\n
Ne jemi duke vendosur ta b\u00ebjm\u00eb k\u00ebt\u00eb n\u00eb 2 etapa: s\u00eb pari t\u00eb p\u00ebrdit\u00ebsojm\u00eb versionin n\u00eb 11.2, pastaj t\u00eb nisim Patroni.<\/p>\n
P\u00ebrdit\u00ebsimi i PostgreSQL<\/h3>\n P\u00ebr nj\u00eb p\u00ebrdit\u00ebsim t\u00eb shpejt\u00eb t\u00eb versionit t\u00eb PostgreSQL, duhet t\u00eb p\u00ebrdorni opsionin -k<\/b>, n\u00eb t\u00eb cilin krijohen hard link-e n\u00eb disk dhe nuk ka nevoj\u00eb p\u00ebr kopjimin e t\u00eb dh\u00ebnave tuaja. N\u00eb bazat mbi 300-400 GB, p\u00ebrdit\u00ebsimi zgjat 1 sekond\u00eb.<\/p>\n
Kemi shum\u00eb shard-e, prandaj duhet ta b\u00ebjm\u00eb p\u00ebrdit\u00ebsimin n\u00eb m\u00ebnyr\u00eb automatike. P\u00ebr k\u00ebt\u00eb kemi shkruar nj\u00eb Ansible playbook, q\u00eb realizon t\u00eb gjith\u00eb procesin e p\u00ebrdit\u00ebsimit p\u00ebr ne:<\/p>\n
\/usr\/lib\/postgresql\/11\/bin\/pg_upgrade \n<b>--link <\/b>\n--old-datadir='' --new-datadir='' \n --old-bindir='' --new-bindir='' \n --old-options=' -c config_file=' \n --new-options=' -c config_file='<\/code><\/pre>\nK\u00ebtu \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet se para se t\u00eb nisim p\u00ebrmir\u00ebsimin, duhet ta realizojm\u00eb at\u00eb me parametrin —check<\/b>, p\u00ebr t\u00eb qen\u00eb t\u00eb sigurt p\u00ebr mund\u00ebsin\u00eb e p\u00ebrmir\u00ebsimit. Po ashtu, skenari yn\u00eb b\u00ebn z\u00ebvend\u00ebsimin e konfigurimeve p\u00ebr koh\u00ebn e p\u00ebrdit\u00ebsimit. Skenari yn\u00eb u ekzekutua p\u00ebr 30 sekonda, rezultat i shk\u00eblqyer.<\/p>\nNisja e Patroni<\/h3>\n
P\u00ebr t\u00eb zgjidhur problemin e dyt\u00eb, mjafton t\u00eb shikoni konfigurimin e Patroni. N\u00eb depozit\u00ebn zyrtare ka nj\u00eb shembull konfigurimi me initdb, q\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr inicializimin e nj\u00eb baze t\u00eb re gjat\u00eb nisjes s\u00eb par\u00eb t\u00eb Patroni. Por pasi kemi nj\u00eb baz\u00eb t\u00eb p\u00ebrfunduar, thjesht e hoq\u00ebm k\u00ebt\u00eb seksion nga konfigurimi.<\/p>\n
Kur filluam t\u00eb vendosnim Patroni n\u00eb nj\u00eb klaster PostgreSQL t\u00eb gatsh\u00ebm dhe ta nisim at\u00eb, u p\u00ebrball\u00ebm me nj\u00eb problem t\u00eb ri: t\u00eb dy serverat fillonin si lider\u00eb. Patroni nuk di asgj\u00eb p\u00ebr gjendjen e m\u00ebparshme t\u00eb klasterit dhe p\u00ebrpiqet t\u00eb niste t\u00eb dy serverat si dy klaster\u00eb t\u00eb ve\u00e7ant\u00eb me t\u00eb nj\u00ebjtin em\u00ebr. P\u00ebr t\u00eb zgjidhur k\u00ebt\u00eb problem, \u00ebsht\u00eb e nevojshme t\u00eb fshini direktoriumin me t\u00eb dh\u00ebna n\u00eb slave:<\/p>\n
rm -rf \/var\/lib\/postgresql\/<\/code><\/pre>\nKjo duhet b\u00ebr\u00eb vet\u00ebm n\u00eb slave!<\/b><\/p>\n
Kur lidhet nj\u00eb replik\u00eb e past\u00ebr, Patroni b\u00ebn nj\u00eb basebackup t\u00eb liderit dhe e rikthen at\u00eb n\u00eb replik\u00eb, m\u00eb pas p\u00ebrdit\u00ebson gjendjen aktuale p\u00ebrmes wal-loga.<\/p>\n
Nj\u00eb v\u00ebshtir\u00ebsi tjet\u00ebr me t\u00eb cil\u00ebn u p\u00ebrball\u00ebm \u00ebsht\u00eb se t\u00eb gjitha klaster\u00ebt PostgreSQL p\u00ebrfundimisht quhen main. Kur \u00e7do klaster nuk di asgj\u00eb p\u00ebr tjetrin, \u00ebsht\u00eb n\u00eb rregull. Por kur d\u00ebshironi t\u00eb p\u00ebrdorni Patroni, t\u00eb gjith\u00eb klaster\u00ebt duhet t\u00eb ken\u00eb nj\u00eb em\u00ebr unik. Zgjidhja \u00ebsht\u00eb t\u00eb ndryshoni emrin e klasterit n\u00eb konfigurimin e PostgreSQL.<\/p>\n
Testi i ngarkes\u00ebs<\/h3>\n Ne kemi lansuar nj\u00eb test q\u00eb imiton pun\u00ebn e p\u00ebrdoruesve n\u00eb tabela. Kur ngarkesa arriti mesataren ton\u00eb t\u00eb p\u00ebrditshme, ne p\u00ebrs\u00ebrit\u00ebm t\u00eb nj\u00ebjtin test, e ndaluam nj\u00eb instanc\u00eb me liderin PostgreSQL. Failover-i automatik funksionoi ashtu si\u00e7 prisnim: Patroni ndryshoi liderin, Konsul-template p\u00ebrdit\u00ebsoi konfigurimin e PgBouncer dhe d\u00ebrgoi urdhrin p\u00ebr ri-ngarkim. Nga grafikat ton\u00eb n\u00eb Grafana, dallohej q\u00eb kishte vonesa prej 20-30 sekondash dhe disa gabime t\u00eb vogla nga server\u00ebt lidhur me lidhjen me baz\u00ebn e t\u00eb dh\u00ebnave. Kjo \u00ebsht\u00eb nj\u00eb situat\u00eb normale, k\u00ebto vlera jan\u00eb t\u00eb pranueshme p\u00ebr failover-in ton\u00eb dhe sigurisht m\u00eb t\u00eb mira se ndalimi i sh\u00ebrbimit.<\/p>\n
Doli Patroni n\u00eb prodhim<\/h2>\n N\u00eb fund, plani yn\u00eb \u00ebsht\u00eb si n\u00eb vijim:<\/p>\n
\nDeploy Konsul-template n\u00eb serverat PgBouncer dhe nisja;<\/li>\n P\u00ebrdit\u00ebsimi i PostgreSQL n\u00eb versionin 11.2;<\/li>\n Ndryshimi i emrit t\u00eb klasterit;<\/li>\n Nisja e klasterit Patroni.<\/li>\n<\/ul>\nN\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb, skema jon\u00eb lejon q\u00eb pika e par\u00eb t\u00eb b\u00ebhet n\u00eb \u00e7do koh\u00eb, mund t\u00eb heqim nj\u00eb nga \u00e7do PgBouncer dhe t\u00eb kryejm\u00eb deploy-in dhe nisjen e consul-template. K\u00ebshtu b\u00ebjm\u00eb.<\/p>\n
P\u00ebr nj\u00eb implementim t\u00eb shpejt\u00eb, ne p\u00ebrdor\u00ebm Ansible, pasi t\u00eb gjitha playbook-t i kishim testuar tashm\u00eb n\u00eb mjedisin e prov\u00ebs, dhe koha e ekzekutimit t\u00eb skenarit t\u00eb plot\u00eb varionte nga 1.5 deri n\u00eb 2 minuta p\u00ebr secilin shard. Ne mund t\u00eb ishim n\u00eb gjendje t\u00eb implementonim secilin shard nj\u00eb nga nj\u00eb pa ndalur sh\u00ebrbimin ton\u00eb, por do t\u00eb na duhej t\u00eb ndalonim p\u00ebr disa minuta secilin PostgreSQL. N\u00eb k\u00ebt\u00eb rast, p\u00ebrdoruesit, t\u00eb cil\u00ebt kishin t\u00eb dh\u00ebna n\u00eb k\u00ebt\u00eb shard, nuk do t\u00eb ishin n\u00eb gjendje t\u00eb punonin plot\u00ebsisht n\u00eb k\u00ebt\u00eb koh\u00eb, dhe kjo \u00ebsht\u00eb e papranueshme p\u00ebr ne.<\/p>\n
Zgjidhja p\u00ebr k\u00ebt\u00eb situat\u00eb ishte nj\u00eb mir\u00ebmbajtje e planifikuar, e cila zhvillohet \u00e7do 3 muaj. Ky \u00ebsht\u00eb nj\u00eb interval p\u00ebr pun\u00ebt e planifikuara, kur ne e ndalim krejt\u00ebsisht sh\u00ebrbimin ton\u00eb dhe p\u00ebrdit\u00ebsojm\u00eb instancat e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave. Nj\u00eb jav\u00eb para intervalit t\u00eb ardhsh\u00ebm, ne vendos\u00ebm t\u00eb prisnim dhe t\u00eb p\u00ebrgatitemi m\u00eb mir\u00eb. Gjat\u00eb k\u00ebtij koh\u00ebprerje, ne mor\u00ebm masa t\u00eb tjera sigurie: p\u00ebr secilin shard PostgreSQL ngrit\u00ebm nj\u00eb replik\u00eb rezerv\u00eb n\u00eb rast t\u00eb d\u00ebshtimeve, p\u00ebr t\u00eb ruajtur t\u00eb dh\u00ebnat m\u00eb t\u00eb fundit, dhe shtuam nj\u00eb instanc\u00eb t\u00eb re p\u00ebr secilin shard, e cila do t\u00eb b\u00ebhej nj\u00eb replik\u00eb e re n\u00eb klasterin Patroni, p\u00ebr t\u00eb shmangur ekzekutimin e komand\u00ebs p\u00ebr fshirjen e t\u00eb dh\u00ebnave. T\u00eb gjitha k\u00ebto ndihmuan n\u00eb minimizimin e rrezikut t\u00eb gabimeve.
Ne kemi rivendosur sh\u00ebrbimin ton\u00eb; gjith\u00e7ka funksionoi si\u00e7 duhet, p\u00ebrdoruesit vazhduan t\u00eb punojn\u00eb, por n\u00eb grafikun ton\u00eb v\u00ebrejt\u00ebm nj\u00eb ngarkes\u00eb anormalisht t\u00eb lart\u00eb n\u00eb server\u00ebt Consul.
Pse nuk e pam\u00eb k\u00ebt\u00eb n\u00eb mjedisin testues? Ky problem ilustron shum\u00eb mir\u00eb se sa e nevojshme \u00ebsht\u00eb t\u00eb ndiqet principi Infrastructure as code dhe t\u00eb p\u00ebrmir\u00ebsohet e gjith\u00eb infrastruktura, duke filluar nga mjediset testuese dhe duke p\u00ebrfunduar me prodhimin. N\u00eb t\u00eb kund\u00ebrt, \u00ebsht\u00eb shum\u00eb e leht\u00eb t\u00eb p\u00ebrballesh me nj\u00eb problem t\u00eb till\u00eb si\u00e7 pat\u00ebm ne. \u00c7far\u00eb ndodhi? Konsul fillimisht u shfaq n\u00eb prodhim dhe m\u00eb pas n\u00eb mjediset testuese; p\u00ebrfundimisht, n\u00eb mjediset testuese versioni Consul ishte m\u00eb i lart\u00eb se n\u00eb prodhim. Pik\u00ebrisht n\u00eb nj\u00eb nga l\u00ebshimet ishte zgjidhur rrjedhja e CPU-s\u00eb gjat\u00eb pun\u00ebs me consul-template. Prandaj ne thjesht p\u00ebrdit\u00ebsuam Consul, duke zgjidhur k\u00ebshtu problemin.<\/p>\n
Rivendosni klust\u00ebrin Patroni<\/h3>\n Megjithat\u00eb, ne pat\u00ebm nj\u00eb problem t\u00eb ri, p\u00ebr t\u00eb cilin as q\u00eb e dyshonim. Gjat\u00eb p\u00ebrdit\u00ebsimit t\u00eb Consul, ne thjesht e fshijm\u00eb nod\u00ebn e Consul nga klust\u00ebri duke p\u00ebrdorur komand\u00ebn consul leave \u2192 Patroni lidhet me nj\u00eb server tjet\u00ebr Consul \u2192 gjith\u00e7ka funksionon. Por kur arrit\u00ebm n\u00eb instanc\u00ebn e fundit t\u00eb klustrit Consul dhe i d\u00ebrguam komand\u00ebn consul leave, t\u00eb gjith\u00eb klust\u00ebrit Patroni thjesht u rivendos\u00ebn, dhe n\u00eb logje pam\u00eb gabimin e m\u00ebposht\u00ebm:<\/p>\n
KALIM: get_cluster\nGjetja (telefononi i fundit):\n...\nRetryFailedError: 'Kalim i arritur i skaduar'\nKALIM: Gabim në komunikim me DCS\n<b>LOG: sistemi i bazës së të dhënave është mbyllur<\/b><\/code><\/pre>\nKlleri Patroni nuk mundi t\u00eb merrte informacionin p\u00ebr klusterin e tij dhe u rindez.<\/p>\n
P\u00ebr t\u00eb gjetur nj\u00eb zgjidhje, ne u drejtuam te autor\u00ebt e Patronit p\u00ebrmes nj\u00eb \u00e7\u00ebshtjeje n\u00eb github. Ata sugjeruan p\u00ebrmir\u00ebsime n\u00eb skedar\u00ebt tan\u00eb t\u00eb konfigurimit:<\/p>\n
consul:\n consul.checks: []\nbootstrap:\n dcs:\n retry_timeout: 8<\/code><\/pre>\nNe arrit\u00ebm ta p\u00ebrs\u00ebrisim problemin n\u00eb mjedisin testues dhe e testuam atje k\u00ebto parametra, por fatkeq\u00ebsisht, ato nuk funksionuan.<\/p>\n
Problemi ende mbetet i pazgjidhur. Ne planifikojm\u00eb t\u00eb provojm\u00eb opsione t\u00eb tjera p\u00ebr zgjidhje:<\/p>\n
\nT\u00eb p\u00ebrdorim agentin Consul n\u00eb \u00e7do instanc\u00eb t\u00eb klasterit Patroni;<\/li>\n T\u00eb rregullojm\u00eb problemin n\u00eb kod.<\/li>\n<\/ul>\nNa \u00ebsht\u00eb e qart\u00eb vendi i shfaqjes s\u00eb gabimit: me siguri, problemi \u00ebsht\u00eb n\u00eb p\u00ebrdorimin e default timeout, i cili nuk rip\u00ebrcaktohet p\u00ebrmes skedarit t\u00eb konfigurimit. Kur heqim serverin e fundit t\u00eb Consul nga klusteri, ndodh ngrirja e t\u00ebr\u00eb klusterit Consul, e cila zgjat m\u00eb shum\u00eb se nj\u00eb sekond\u00eb, dhe p\u00ebr k\u00ebt\u00eb arsye Patroni nuk mund t\u00eb marr\u00eb gjendjen e klasterit dhe e rindez t\u00ebr\u00eb klasterin.<\/p>\n
P\u00ebr fat t\u00eb mir\u00eb, nuk has\u00ebm m\u00eb ndonj\u00eb gabim tjet\u00ebr.<\/p>\n
P\u00ebrfundimet e p\u00ebrdorimit t\u00eb Patronit<\/h2>\n Pas pastrimit t\u00eb suksessh\u00ebm t\u00eb Patroni, ne kemi shtuar nj\u00eb replik\u00eb shtes\u00eb n\u00eb secilin klaster. Tani, n\u00eb \u00e7do klaster ka nj\u00eb lloj kuorumi: nj\u00eb lider dhe dy replika, p\u00ebr t\u00eb siguruar mb\u00ebshtetje n\u00eb rast t\u00eb ndarjes s\u00eb mendimeve gjat\u00eb kalimit.
N\u00eb prodhim, Patroni ka funksionuar p\u00ebr m\u00eb shum\u00eb se tre muaj. Gjat\u00eb k\u00ebsaj kohe, ai ka ndihmuar tashm\u00eb. S\u00eb fundmi, lideri i nj\u00eb prej klashtave vdiq n\u00eb AWS, dhe automatikisht ndodhi failover dhe p\u00ebrdoruesit vazhduan t\u00eb punonin. Patroni realizoi detyr\u00ebn e tij kryesore.<\/p>\n
Nj\u00eb p\u00ebrmbledhje e p\u00ebrdorimit t\u00eb Patroni:<\/b><\/p>\n\nLeht\u00ebsia e ndryshimit t\u00eb konfiguracionit. B\u00ebhet e mjaftueshme t\u00eb ndryshoni konfiguracionin n\u00eb nj\u00eb instanc\u00eb dhe ajo do t\u2019u transmetohet t\u00ebr\u00eb klashtit. N\u00ebse k\u00ebrkohet rinisja p\u00ebr t\u00eb zbatuar konfiguracionin e ri, at\u00ebher\u00eb Patroni do ta njoftoj\u00eb p\u00ebr k\u00ebt\u00eb. Patroni mund t\u00eb rinis\u00eb t\u00ebr\u00eb klashtin me nj\u00eb komand\u00eb, q\u00eb gjithashtu \u00ebsht\u00eb shum\u00eb e p\u00ebrshtatshme.<\/li>\n Automatikisht ndodhi failover dhe tashm\u00eb ka ndihmuar.<\/li>\n P\u00ebrdit\u00ebsimi i PostgreSQL pa ndonj\u00eb koh\u00eb t\u00eb mbylljes s\u00eb aplikacionit. Fillimisht, nevojitet t\u00eb p\u00ebrdit\u00ebsohen replikat n\u00eb versionin e ri, pastaj t\u00eb ndryshohet lideri n\u00eb klasterin e Patroni dhe t\u00eb p\u00ebrdit\u00ebsohet lideri i vjet\u00ebr. Gjat\u00eb k\u00ebsaj, b\u00ebhet testimi i nevojsh\u00ebm i automatikisht ndodhur t\u00eb failover.<\/li>\n<\/ul>\nBurimi: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0434\u043e\u0448\u043b\u0438 \u043a \u0432\u043e\u043f\u0440\u043e\u0441\u0443 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 PostgreSQL, \u043f\u043e\u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u0441\u0442\u0430\u043b\u043e \u0434\u043b\u044f \u043d\u0430\u0441 \u0432\u0430\u0436\u043d\u043e \u0438 \u0447\u0442\u043e \u0432 \u0438\u0442\u043e\u0433\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c. \u0423 \u043d\u0430\u0441 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441: 2,5 \u043c\u043b\u043d \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, 50\u041a+ \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u0436\u0434\u044b\u0439 \u0434\u0435\u043d\u044c. \u0421\u0435\u0440\u0432\u0435\u0440\u0430 \u043d\u0430\u0445\u043e\u0434\u044f\u0442\u0441\u044f \u0432 Amazone \u0432 \u043e\u0434\u043d\u043e\u043c \u0440\u0435\u0433\u0438\u043e\u043d\u0435 \u0418\u0440\u043b\u0430\u043d\u0434\u0438\u0438: \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e 100+ \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432, \u0438\u0437 \u043d\u0438\u0445 \u043f\u043e\u0447\u0442\u0438 50 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26749,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/443f85815b0560fade7db5b639942935.png\")
![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/674dd77de4c8b48a946c9f64c0b2fdd1.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/dabcb7f6006520c4fec85fb925e8975e.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/2c1f1e7d9f7be4fdeb43858520d55e36.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/8e5350d2466311593e11add30d5b1bdc.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/3234594b363904424fdce64c9d77fca5.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/6cf92996a127bb6637ab81dc45fdd60a.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/bf9a9eff675a26039e3f76b16c6cd713.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/d670fe373b774f1b52bfd8a8c3b53a21.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/29e5c5f50dbfebfe5665fa0aeb009728.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/af0eef9ac235706c0aac62d2e1ee179d.png\")
<\/p>\n![\"Klastri](\"\/wp-content\/uploads\/2019\/06\/3bb4c0495fea274b04edd2e99b59eacb.png\")
<\/p>\n