Di gotarê de ez ê ji we re vebêjim ka em çawa nêzî pirsgirêka tolerasyona xeletiya PostgreSQL bûn, çima ew ji me re girîng bû û di dawiyê de çi qewimî.
Karûbarek me ya pir barkirî heye: 2,5 mîlyon bikarhêner li çaraliyê cîhanê, 50K+ bikarhênerên çalak her roj. Pêşkêşker li Amazone li herêmek Irelandrlanda ne: Zêdetirî 100 serverên cihêreng bi domdarî dixebitin, ji wan hema hema 50 bi databasan re ne.
Tevahiya paşîn serîlêdana Java-ya dewletparêz a yekparêz a mezin e ku pêwendiyek websocketê ya domdar bi xerîdar re digire. Dema ku çend bikarhêner di heman demê de li ser heman panelê dixebitin, ew hemî guhertinan di wextê rast de dibînin, ji ber ku em her guhartinê li databasê dinivîsin. Li ser databasên me li ser 10K daxwazên me hene. Di barkirina lûtkeyê de li Redis, em di çirkeyê de 80-100K daxwaz dinivîsin.
Çima me ji Redis veguherand PostgreSQL
Di destpêkê de, karûbarê me bi Redis re xebitî, firotgehek nirxa sereke ku hemî daneyan di RAM-a serverê de hilîne.
Aliyên Redis:
- Leza bersiva bilind, ji ber her tişt di bîrê de tê hilanîn;
- Hêsaniya hilanînê û dubarekirinê.
Kêmasiyên Redis ji bo me:
- Danûstandinên rastîn tune. Me hewl da ku em wan di asta serlêdana xwe de simule bikin. Mixabin, ev her gav baş nedikir û hewceyê nivîsandina kodek pir tevlihev bû.
- Hejmara daneyan ji hêla mêjûya bîranînê ve tê sînorkirin. Her ku mîqdara daneyê zêde dibe, bîranîn dê mezin bibe, û, di dawiyê de, em ê bikevin nav taybetmendiyên mînaka hilbijartî, ku di AWS de hewce dike ku karûbarê me rawestîne da ku celebê nimûneyê biguhezîne.
- Pêdivî ye ku bi berdewamî asta derengiya kêm were domandin, ji ber. hejmareke pir mezin ji daxwazên me hene. Asta derengiya çêtirîn ji bo me 17-20 ms e. Di asta 30-40 ms de, em bersivên dirêj li ser daxwazên serîlêdana me û xirabkirina karûbarê digirin. Mixabin, ev yek di Îlona 2018-an de bi me re qewimî, dema ku yek ji wan bûyerên bi Redis re ji ber hin sedeman 2 carî ji gelemperî dereng dereng wergirt. Ji bo çareserkirina pirsgirêkê, me karûbarê nîvrojê ji bo lênihêrîna neplankirî rawestand û mînaka Redis ya pirsgirêkî guherand.
- Hêsan e ku meriv bi xeletiyên piçûk ên di kodê de jî nerazîbûna daneyan bigire û dûv re gelek wext bi nivîsandina kodê derbas bike da ku vê daneyê rast bike.
Me kêmasiyan hesab kir û fêm kir ku pêdivî ye ku em berbi tiştek hêsantir, bi danûstendinên normal û kêmtir girêdayîbûna bi derengbûnê ve biçin. Lêkolîn kir, gelek vebijark analîz kir û PostgreSQL hilbijart.
Em 1,5 sal berê berê xwe didin danegehek nû û tenê beşek piçûk ji daneyan bar kirine, ji ber vê yekê em niha bi Redis û PostgreSQL re hevdem dixebitin. Zêdetir agahdarî li ser qonaxên veguheztin û veguheztina daneyan di navbera databasan de tê nivîsandin .
Dema ku me dest bi tevgerê kir, serîlêdana me rasterast bi databasê re xebitî û xwe gihandiye master Redis û PostgreSQL. Komxebata PostgreSQL ji master û kopiyek bi dubarekirina asynkron pêk tê. Bi vî rengî nexşeya databasê wusa xuya bû:
Pêkanîna PgBouncer
Dema ku em diçûn, hilber jî pêşve diçû: hejmara bikarhêneran û hejmara serverên ku bi PostgreSQL re dixebitin zêde bûn, û me dest bi kêmbûna girêdanan kir. PostgreSQL ji bo her girêdanê pêvajoyek cihê diafirîne û çavkaniyan dixwe. Hûn dikarin hejmara pêwendiyan heya xalek diyarkirî zêde bikin, wekî din şansek heye ku hûn performansa databasa nebaş bistînin. Di rewşek weha de vebijarka îdeal dê ev be ku meriv rêveberek pêwendiyê hilbijêrin ku dê li ber bingehê raweste.
Ji bo rêvebirê pêwendiyê du vebijarkên me hebûn: Pgpool û PgBouncer. Lê ya yekem moda danûstendinê ya xebata bi databasê re piştgirî nake, ji ber vê yekê me PgBouncer hilbijart.
Me pilana xebatê ya jêrîn saz kiriye: sepana me digihîje yek PgBouncer, li pişt wê masterên PostgreSQL hene, û li pişt her masterê kopiyek bi repplication asynchronous heye.
Di heman demê de, me nekarî tevahiya daneyê di PostgreSQL de hilîne û leza xebata bi databasê re ji bo me girîng bû, ji ber vê yekê me dest bi parvekirina PostgreSQL di asta serîlêdanê de kir. Pîlana ku li jor hatî destnîşan kirin ji bo vê yekê bi rehetî ye: dema ku şûreyek PostgreSQL-ya nû lê zêde bike, bes e ku hûn veavakirina PgBouncer nûve bikin û serîlêdan tavilê dikare bi şûşeya nû re bixebite.
PgBouncer têkçûn
Vê planê heya dema ku yekane mînaka PgBouncer mir xebitî. Em li AWS-ê ne, ku hemî mînak li ser hardware ku bi periyodîk dimire dimeşîne. Di rewşên weha de, mînak tenê berbi hardware nû ve diçe û dîsa dixebite. Ev bi PgBouncer re çêbû, lê ew ne berdest bû. Encama vê payîzê 25 deqîqeyan nebûna xizmeta me bû. AWS pêşniyar dike ku ji bo rewşên weha, ku di wê demê de li welatê me nehat bicîhanîn, zêdebariya aliyê bikarhêner bikar bînin.
Piştî wê, em bi ciddî li ser tolerasyona xeletiya komikên PgBouncer û PostgreSQL fikirîn, ji ber ku rewşek wusa dikare bi her mînakek di hesabê meya AWS de çêbibe.
Me nexşeya tolerasyona xeletiya PgBouncer bi vî rengî çêkir: hemî serverên serîlêdanê digihîjin Balansa Barkirina Torgilokê, li pişta ku du PgBouncer hene. Her PgBouncer li heman masterê PostgreSQL ya her şûşeyê dinêre. Ger têkçûnek mînakek AWS dîsa çêbibe, hemî seyrûsefer ji hêla PgBouncerek din ve têne rêve kirin. Têkçûna Balansa Barkirina Torê ji hêla AWS ve tê peyda kirin.
Ev nexşe zêdekirina serverên nû yên PgBouncer hêsan dike.
Komek Failover PostgreSQL biafirînin
Dema ku em vê pirsgirêkê çareser dikin, me vebijarkên cihêreng fikirîn: têkçûna xwe-nivîskî, repmgr, AWS RDS, Patroni.
Nivîsarên xwe-nivîskî
Ew dikarin karê masterê bişopînin û, heke ew biser nekeve, kopiyek ji masterê re pêşve bibin û veavakirina PgBouncer nûve bikin.
Feydeyên vê nêzîkatiyê hêsaniya herî zêde ne, ji ber ku hûn bi xwe nivîsan dinivîsin û tam fam dikin ka ew çawa dixebitin.
Bawer:
- Dibe ku master nemira, di şûna wê de dibe ku têkçûnek torê çêbibe. Failover, ji vê yekê nizane, dê replica ji masterê re pêşve bibe, dema ku axayê kevn dê xebata xwe bidomîne. Wekî encamek, em ê di rola masterê de du serveran bistînin û em ê nizanin kîjan ji wan daneyên nûjen ên herî dawî hene. Ji vê rewşê re jî tê gotin mejî perçebûyî;
- Em bê bersiv man. Di veavakirina me de, master û yek kopiyek, piştî veguheztinê, kopya ber bi masterê ve diçe û êdî kopiyên me nîn in, ji ber vê yekê divê em bi destan kopiyek nû lê zêde bikin;
- Pêdiviya me bi çavdêriya zêde ya operasyona têkçûyî heye, dema ku me 12 şûşeyên PostgreSQL hene, ku tê vê wateyê ku divê em 12 koman bişopînin. Bi zêdebûna hejmara şûşeyan re, divê hûn ji bîr nekin ku failover jî nûve bikin.
Failover-a xwe-nivîskî pir tevlihev xuya dike û piştgirîya ne-tişt hewce dike. Bi yek komê PostgreSQL re, ev ê bijareya herî hêsan be, lê ew pîvan nake, ji ber vê yekê ew ji me re ne maqûl e.
Repmgr
Rêvebirê Replication ji bo komikên PostgreSQL, ku dikare xebata komek PostgreSQL birêve bibe. Di heman demê de, ew ji qutîkê de têkçûnek otomatîkî tune ye, ji ber vê yekê ji bo xebatê hûn ê hewce ne ku li ser çareseriya qediyayî "pêça" xwe binivîsin. Ji ber vê yekê her tişt dikare ji senaryoyên xwe-nivîsandî tevlihevtir derkeve holê, ji ber vê yekê me Repmgr jî ceriband.
AWS RDS
Her tiştê ku em hewce ne piştgirî dike, dizane ku meriv çawa paşvekêşan çêdike û hewzek pêwendiyan diparêze. Veguheztina otomatîkî ya wê heye: gava ku master dimire, kopya dibe mastera nû, û AWS tomara dns-ê diguhezîne serwerê nû, dema ku kopya dikarin di AZ-yên cihêreng de werin bicîh kirin.
Di dezawantajan de nebûna verastkirinên baş hene. Wek mînakek birêkûpêkkirina baş: mînakên me ji bo girêdanên tcp sînorkirin hene, ku, mixabin, di RDS de nayê kirin:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Digel vê yekê, AWS RDS hema hema du caran ji bihayê mînaka birêkûpêk biha ye, ku sedema bingehîn a dev ji vê çareseriyê bû.
Patroni
Ev şablonek python e ku ji bo birêvebirina PostgreSQL bi belgeyên baş, têkçûna otomatîkî û koda çavkaniyê li ser github-ê ye.
Aliyên Patroni:
- Her parametreya veavakirinê tê ravekirin, diyar e ku ew çawa dixebite;
- Failover-a otomatîk ji qutiyê dixebite;
- Bi python hatî nivîsandin, û ji ber ku em bi xwe jî di python de pir dinivîsin, dê ji me re hêsantir be ku em bi pirsgirêkan re mijûl bibin û, belkî, tewra jî alîkariya pêşveçûna projeyê bikin;
- PostgreSQL bi tevahî rêve dibe, destûrê dide te ku hûn bi yekcarî veavakirina li ser hemî girêkên komê biguhezînin, û ger pêdivî ye ku kom ji nû ve were destpêkirin da ku veavakirina nû bicîh bîne, wê hingê ev dikare dîsa bi karanîna Patroni were kirin.
Bawer:
- Ji belgeyê ne diyar e ka meriv çawa bi PgBouncer re rast dixebite. Her çend dijwar e ku meriv jê re bibêje kêmek, ji ber ku peywira Patroni birêvebirina PostgreSQL ye, û dê têkiliyên bi Patroni re çawa biçin jixwe pirsgirêka me ye;
- Çend mînakên pêkanîna Patroni li ser cildên mezin hene, di heman demê de gelek mînakên pêkanîna ji sifirê hene.
Wekî encamek, me Patroni hilbijart ku komek têkçûyî biafirîne.
Patroni Pêvajoya Pêkanîna
Berî Patroni, me 12 şûşeyên PostgreSQL di veavakirina yek master û yek kopiyek bi repplication asynchronous de hebûn. Pêşkêşkerên serîlêdanê bi navgîniya Tora Load Balancer ve gihîştin databasan, li pişta ku du mînak bi PgBouncer re hebûn, û li pişt wan hemî serverên PostgreSQL hebûn.
Ji bo bicihanîna Patroni, me hewce bû ku mîhengek komê hilanînê ya belavkirî hilbijêrin. Patroni bi pergalên hilanîna mîhengê yên belavkirî yên wekî etcd, Zookeeper, Konsul re dixebite. Li sûkê me tenê komek konsulê bêkêmasî heye, ku bi Vault re bi hev re dixebite û em êdî wê bikar nakin. Sedemek girîng e ku hûn dest bi karanîna Konsulê ji bo armanca xwe bikin.
Çawa Patroni bi Konsul re dixebite
Komek me ya Konsulê heye, ku ji sê girêkan pêk tê, û komek Patroni, ku ji serokek û kopiyek pêk tê (li Patroni, ji axayê re serokê komê, û ji koleyan re replicas re tê gotin). Her mînakek koma Patroni bi berdewamî agahdariya li ser rewşa komê ji Konsul re dişîne. Ji ber vê yekê, ji Konsul hûn her gav dikarin konfigurasyona heyî ya koma Patroni û kî di vê gavê de rêber e fêr bibin.
Ji bo girêdana Patroni bi Konsulê re, bes e ku hûn belgeya fermî bixwînin, ku dibêje ku hûn hewce ne ku mêvandarek di formata http an https de diyar bikin, li gorî ka em çawa bi Konsul re dixebitin, û pilana girêdanê, vebijarkî:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpEw hêsan xuya dike, lê li vir xeletî dest pê dikin. Bi Konsul re, em bi rêya https ve li ser pêwendiyek ewledar dixebitin û konfigurasyona pêwendiya me dê wiha xuya bike:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Lê ev kar nake. Di destpêkê de, Patroni nikare bi Konsulê ve girêbide, ji ber ku ew bi her awayî hewl dide ku bi http derbas bibe.
Koda çavkaniyê ya Patroni alîkariya çareserkirina pirsgirêkê kir. Tiştek baş e ku ew di python de hatî nivîsandin. Derket holê ku pîvana mêvandar bi ti awayî nayê pars kirin, û divê protokol di nexşeyê de were diyar kirin. Bi vî rengî bloka veavakirina xebatê ya ji bo xebata bi Konsul re ji me re xuya dike:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul-şablon
Ji ber vê yekê, me hilanîn ji bo veavakirinê hilbijart. Naha pêdivî ye ku em fam bikin ka PgBouncer dê çawa veavakirina xwe biguhezîne dema ku serokê di koma Patroni de biguhezîne. Di belgeyê de bersiva vê pirsê tune, ji ber. li wir, di prensîbê de, xebata bi PgBouncer re nayê vegotin.
Di lêgerîna çareseriyekê de, me gotarek dît (mixabin sernav nayê bîra min) ku tê de hatibû nivîsandin ku Сonsul-şablon di berhevkirina PgBouncer û Patroni de pir alîkar kir. Vê yekê me hişt ku em lêkolîn bikin ka Konsul-şablon çawa dixebite.
Derket holê ku Konsul-şablon bi berdewamî veavakirina koma PostgreSQL ya li Konsulê dişopîne. Dema ku rêber diguhere, ew veavakirina PgBouncer nûve dike û fermanek dişîne da ku wê ji nû ve bar bike.
Pîvanek mezin a şablonê ev e ku ew wekî kodê tête hilanîn, ji ber vê yekê dema ku şûreyek nû lê zêde bike, bes e ku meriv pevrabûnek nû çêbike û şablonê bixweber nûve bike, binesaziya wekî prensîba kodê piştgirî bike.
Mîmariya nû bi Patroni
Di encamê de, me plansaziya xebatê ya jêrîn wergirt:
Hemî pêşkêşkerên serîlêdanê digihîjin balanserê → li pişt wê du mînakên PgBouncer hene → li ser her nimûneyê, Konsul-şablon tê destpêkirin, ku rewşa her komek Patroni dişopîne û têkildariya veavakirina PgBouncer, ku daxwazan ji serokê heyî re dişîne. ji her komê.
testkirina manual
Berî destpêkirina wê li ser jîngehek ceribandinê ya piçûk me vê pilanê meşand û xebata veguheztina otomatîkî kontrol kir. Wan tablo vekir, çîp bar kir, û di wê gavê de wan serokê komê "kuşt". Di AWS-ê de, ev bi qasî girtina nimûneyê bi konsolê re hêsan e.
Sticker di nav 10-20 çirkeyan de vegeriya, û dûv re dîsa dest bi tevgerê kir. Ev tê vê wateyê ku koma Patroni rast xebitî: wê serok guhert, agahdarî ji Сonsul re şand, û Сonsul-şablon tavilê ev agahdarî hilda, veavakirina PgBouncer guherand û fermana ji nû ve barkirinê şand.
Meriv çawa di bin bargiraniya zêde de bijî û dema domandinê hindik bimîne?
Her tişt bêkêmasî dixebite! Lê pirsên nû hene: Ew ê çawa di bin barê giran de bixebite? Meriv çawa zû û bi ewlehî her tiştî di hilberînê de derxîne?
Jîngeha ceribandinê ya ku em ceribandina barkirinê li ser dikin ji me re dibe alîkar ku bersiva pirsa yekem bidin. Ew di warê mîmariyê de bi hilberînê re bi tevahî wekhev e û daneyên ceribandinê yên ku bi qebareya hilberînê bi qasî hilberînê wekhev e hilberandiye. Em biryar didin ku tenê di dema ceribandinê de yek ji axayên PostgreSQL "bikujin" û bibînin ka çi diqewime. Lê berî wê, girîng e ku meriv guheztina otomatîkî kontrol bike, ji ber ku li ser vê hawîrdorê me çend şûşeyên PostgreSQL hene, ji ber vê yekê em ê berî hilberînê ceribandinek hêja ya nivîsarên mîhengê bistînin.
Herdu peywir jî ambargo xuya dikin, lê me PostgreSQL 9.6 heye. Ma em dikarin tavilê nûve bikin 11.2?
Em biryar didin ku wê di 2 gavan de bikin: pêşî li 11.2 nûve bikin, dûv re Patroni dest pê bikin.
Nûvekirina PostgreSQL
Ji bo zû nûvekirina guhertoya PostgreSQL, vebijarkê bikar bînin -k, ku tê de lînkên hişk li ser dîskê têne çêkirin û ne hewce ye ku daneyên we kopî bikin. Li ser bingehên 300-400 GB, nûvekirin 1 çirke digire.
Gelek şikên me hene, ji ber vê yekê pêdivî ye ku nûvekirin bixweber were kirin. Ji bo vê yekê, me pirtûkek lîstikek Ansible nivîsî ku tevahiya pêvajoya nûvekirinê ji bo me digire:
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='Li vir girîng e ku meriv bala xwe bide ku berî destpêkirina nûvekirinê, divê hûn wê bi parametreyê pêk bînin --berçavkirinda ku bicîh bikin ku hûn dikarin nûve bikin. Nivîsara me di heman demê de ji bo dirêjahiya nûvekirinê veguheztina mîhengan jî dike. Skrîpta me di 30 çirkeyan de qediya, ku ev encamek hêja ye.
Patroni dest pê bikin
Ji bo çareserkirina pirsgirêka duyemîn, tenê li veavakirina Patroni binêre. Depoya fermî bi initdb ve mîhengek mînakek heye, ku dema ku hûn yekem dest bi Patroni dikin berpirsiyar e destpêkirina databasek nû. Lê ji ber ku me berê danegehek amadekirî heye, me bi tenê ev beş ji veavakirinê derxist.
Dema ku me dest bi sazkirina Patroni li ser komek PostgreSQL ya berê kir û xebitandina wê kir, em ketin pirsgirêkek nû: her du server jî wekî rêber dest pê kirin. Patroni di derbarê rewşa destpêkê ya komê de tiştek nizane û hewl dide ku her du serveran wekî du komikên cihêreng ên bi heman navî dest pê bike. Ji bo çareserkirina vê pirsgirêkê, hûn hewce ne ku pelrêça bi daneyên li ser xulamê jêbirin:
rm -rf /var/lib/postgresql/Pêdivî ye ku ev tenê li ser kole were kirin!
Dema ku kopiyek paqij tê girêdan, Patroni rêberek bingehîn a paşvekêşanê çêdike û wê li replikayê vegerîne, û dûv re li gorî têketinên wal rewşa heyî digire.
Zehmetiyek din a ku me pê re rû bi rû maye ev e ku hemî komikên PostgreSQL ji hêla xwerû ve têne navên sereke. Dema ku her kom li ser ya din tiştek nizane, ev normal e. Lê gava ku hûn dixwazin Patroni bikar bînin, wê hingê pêdivî ye ku hemî kom navek yekta hebe. Çareserî guherandina navê komê di veavakirina PostgreSQL de ye.
testa barkirinê
Me ceribandinek ku ezmûna bikarhêner li ser panelan simule dike dest pê kiriye. Dema ku bar gihîştiye nirxa meya rojane ya navîn, me tam heman ceribandinê dubare kir, me bi serokê PostgreSQL re yek mînakek qut kir. Têkçûna otomatîkî wekî ku me hêvî dikir xebitî: Patroni serok guhert, Konsul-şablon veavakirina PgBouncer nûve kir û fermanek ji nû ve barkirinê şand. Li gorî grafikên me yên li Grafana, eşkere bû ku ji serverên ku bi girêdana databasê ve girêdayî ne derengiyên 20-30 saniyeyan û hejmarek piçûk xeletî hene. Ev rewşek normal e, nirxên weha ji bo têkçûna me têne qebûl kirin û bê guman ji domdariya karûbarê çêtir in.
Patroni tîne hilberînê
Di encamê de, me planek jêrîn derxist:
- Konsul-şablon li ser serverên PgBouncer bicîh bikin û dest pê bikin;
- Nûvekirinên PostgreSQL ji bo guhertoya 11.2;
- Navê komê biguherînin;
- Destpêkirina Koma Patroni.
Di heman demê de, pilana me dihêle ku em hema hema di her kêliyê de xala yekem pêk bînin, em dikarin her PgBouncer bi dorê ji kar derxînin û li ser wê konsul-şablon bicîh bikin û bimeşînin. Ji ber vê yekê me kir.
Ji bo bicîhkirina bilez, me Ansible bikar anî, ji ber ku me berê hemî pirtûkên lîstikê li ser hawîrdorek ceribandinê ceriband, û dema bicîhkirina skrîptê ya tevahî ji 1,5 heya 2 hûrdem ji bo her perçek bû. Me dikaribû her tiştî yek bi yek li ser her perçeyek bêyî sekinandina karûbarê xwe bişixulînin, lê pêdivî ye ku em her PostgreSQL çend deqeyan vekin. Di vê rewşê de, bikarhênerên ku daneyên wan li ser vê şikilê ne di vê demê de nekarin bi tevahî bixebitin, û ev ji bo me nayê pejirandin.
Rêya derketina ji vê rewşê, lênihêrîna plankirî bû, ku her 3 mehan carekê pêk tê. Ev pencereyek ji bo xebata plansazkirî ye, dema ku em karûbarê xwe bi tevahî qut dikin û mînakên databasa xwe nûve dikin. Hefteyek mabû ji pencereya din re, û me biryar da ku em tenê li bendê bimînin û bêtir amade bikin. Di dema bendewariyê de, me xwe bi ser de jî ewle kir: ji bo her perçeyek PostgreSQL, me kopiyek yedek hilda di rewşek nehiştina daneyên herî dawî de, û mînakek nû ji bo her perçeyek zêde kir, ku divê di koma Patroni de bibe kopiyek nû. da ku emrêkek jêbirina daneyan pêk neyê. Hemî ev alîkariya kêmkirina xetera xeletiyê kir.
Me karûbarê xwe ji nû ve da destpêkirin, her tişt wekî ku divê xebitî, bikarhêneran xebata xwe domandin, lê li ser grafîkan me li ser serverên Konsulê barek ne asayî bilind dît.
Çima me ev yek di hawîrdora ceribandinê de nedît? Ev pirsgirêk pir baş destnîşan dike ku pêdivî ye ku Binesaziyê wekî prensîba kodê bişopînin û tevahiya binesaziyê, ji hawîrdorên ceribandinê heya hilberînê, safî bikin. Wekî din, ew pir hêsan e ku pirsgirêka ku me peyda kir. Çi qewimî? Konsul pêşî li hilberînê xuya bû, û dûv re li hawîrdorên ceribandinê, di encamê de, li ser hawîrdorên ceribandinê, guhertoya Konsulê ji hilberînê bilindtir bû. Tenê di yek ji serbestberdanan de, dema ku bi konsul-şablon re xebitîn, lekeyek CPU hate çareser kirin. Ji ber vê yekê, me tenê Konsul nû kir, bi vî rengî pirsgirêk çareser kir.
Koma Patroni ji nû ve bidin destpêkirin
Lêbelê, me pirsgirêkek nû peyda kir, ku me guman jî nekir. Dema ku Konsulê nûve dike, em bi karanîna fermana berdana konsulê bi tenê girêka Konsulê ji komê derdixin → Patroni bi serverek Konsulê din ve girêdide → her tişt dixebite. Lê gava ku em gihîştin mînaka paşîn a koma konsulê û emrê hiştina konsulê jê re şandin, hemî komên Patroni bi tenê ji nû ve dest pê kirin, û di qeydan de me xeletiya jêrîn dît:
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>Koma Patroni nekarî agahdariya li ser koma xwe bigire û ji nû ve dest pê kir.
Ji bo ku çareseriyek bibînin, me bi nivîskarên Patroni re bi pirsgirêkek li ser github re têkilî danî. Wan çêtirkirinên pelên mîhengê me pêşniyar kirin:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Me karîbû pirsgirêkê li ser hawîrdorek ceribandinê dubare bikin û van vebijarkan li wir ceriband, lê mixabin ew nexebitîn.
Pirsgirêk hîn jî bê çareserî dimîne. Em plan dikin ku çareseriyên jêrîn biceribînin:
- Li ser her mînakek koma Patroni-a Konsul bikar bînin;
- Pirsgirêka di kodê de rast bikin.
Em fêm dikin ku xeletî li ku derketiye: Pirsgirêk belkî karanîna demara xwerû ye, ku bi pelê veavakirinê ve nayê derbas kirin. Dema ku servera Konsulê ya paşîn ji komê tê rakirin, tevahiya koma Konsulê ji saniyeyekê zêdetir disekine, ji ber vê yekê, Patroni nikare statûya komê bistîne û bi tevahî komê ji nû ve dest pê dike.
Xweşbextane êdî em rastî tu xeletiyan nehatin.
Encamên karanîna Patroni
Piştî destpêkirina serketî ya Patroni, me di her komê de kopiyek din lê zêde kir. Naha di her komê de xuyangek quorumek heye: yek serok û du kopîk, ji bo tora ewlehiyê di bûyera perçebûna mêjî de dema veguheztinê.
Patroni ji sê mehan zêdetir e ku li ser hilberînê dixebite. Di vê demê de, wî berê xwe da alîkariya me. Di van demên dawî de, serokê yek ji koman di AWS de mir, têkçûna otomatîkî xebitî û bikarhêneran xebata xwe domandin. Patronî peywira xwe ya sereke pêk anî.
Kurteyek piçûk a karanîna Patroni:
- Asaniya guhertinên veavakirinê. Guhertina veavakirinê li ser yek nimûneyê bes e û ew ê li tevahiya komê were kişandin. Ger ji bo sepandina veavakirina nû rebootek pêdivî be, Patroni dê we agahdar bike. Patroni dikare bi fermanek yekane, ku di heman demê de pir rehet e, tevahiya komê ji nû ve bide destpêkirin.
- Failover-a otomatîk dixebite û berê xwe daye alîkariya me.
- Nûvekirina PostgreSQL bêyî demdirêjiya serîlêdanê. Pêdivî ye ku hûn pêşî kopiyan li guhertoya nû nûve bikin, dûv re serokê di koma Patroni de biguhezînin û rêberê kevn nûve bikin. Di vê rewşê de, ceribandina pêwîst a têkçûna otomatîkî pêk tê.
Source: www.habr.com