Patroni neveiksmju stāsti vai PostgreSQL klastera avārija. Aleksejs Ļesovskis

Patroni galvenais mērķis ir nodrošināt augstu PostgreSQL pieejamību. Bet Patroni ir tikai veidne, nevis gatavs rīks (kas kopumā ir teikts dokumentācijā). No pirmā acu uzmetiena, iestatot Patroni testa laboratorijā, varat redzēt, cik tas ir lielisks rīks un cik viegli tas tiek galā ar mūsu mēģinājumiem izjaukt kopu. Taču praksē ražošanas vidē ne vienmēr viss notiek tik skaisti un eleganti kā testa laboratorijā.

Pastāstīšu mazliet par sevi. Es sāku strādāt kā sistēmas administrators. Strādājis tīmekļa izstrādē. Es strādāju Data Egret kopš 2014. gada. Uzņēmums nodarbojas ar konsultācijām Postgres jomā. Un mēs apkalpojam tieši Postgres, un mēs strādājam ar Postgres katru dienu, tāpēc mums ir dažādas zināšanas saistībā ar darbību.

Un 2018. gada beigās mēs sākām lēnām lietot Patroni. Un zināma pieredze ir uzkrāta. Mēs kaut kā to diagnosticējām, noregulējām, nonācām pie savas labākās prakses. Un šajā ziņojumā es par tiem runāšu.

Izņemot Postgres, man patīk Linux. Man patīk tajā bakstīties un izpētīt, man patīk vākt serdes. Man patīk virtualizācija, konteineri, doks, Kubernetes. Tas viss mani interesē, jo ietekmē vecie admin paradumi. Man patīk nodarboties ar monitoringu. Un man patīk postgres lietas, kas saistītas ar administrēšanu, t.i., replikāciju, dublēšanu. Un brīvajā laikā rakstu Go. Es neesmu programmatūras inženieris, es vienkārši rakstu sev Go. Un tas man sagādā prieku.

• Es domāju, ka daudzi no jums zina, ka Postgres nav pieejams HA (augsta pieejamība). Lai iegūtu HA, jums kaut kas jāinstalē, jākonfigurē, jāpieliek pūles un jāiegūst tas.
• Ir vairāki rīki, un Patroni ir viens no tiem, kas lieliski un ļoti labi atrisina HA. Bet, ievietojot to visu testa laboratorijā un palaižot to, mēs varam redzēt, ka tas viss darbojas, mēs varam reproducēt dažas problēmas, redzēt, kā Patroni tās apkalpo. Un mēs redzēsim, ka tas viss darbojas lieliski.
• Taču praksē mēs saskārāmies ar dažādām problēmām. Un es runāšu par šīm problēmām.
• Es jums pastāstīšu, kā mēs to diagnosticējām, ko mēs pielāgojām - vai tas mums palīdzēja vai nē.

• Patroni nestāstīšu, jo internetā var googlēt, var paskatīties konfigurācijas failus, lai saprastu, kā tas viss sākas, kā tiek konfigurēts. Var saprast shēmas, arhitektūru, atrodot informāciju par to internetā.
• Par kāda cita pieredzi nerunāšu. Es runāšu tikai par problēmām, ar kurām mēs saskārāmies.
• Un es nerunāšu par problēmām, kas ir ārpus Patroni un PostgreSQL. Ja, piemēram, ir problēmas, kas saistītas ar balansēšanu, kad mūsu klasteris ir sabrucis, es par to nerunāšu.

Un neliela atruna pirms ziņojuma sākšanas.

Visas šīs problēmas, ar kurām mēs saskārāmies, mums tās bija pirmajos 6-7-8 darbības mēnešos. Laika gaitā mēs nonācām pie savas iekšējās paraugprakses. Un mūsu problēmas pazuda. Tāpēc ziņojums tika izziņots apmēram pirms pusgada, kad tas viss bija svaigi manā galvā un es to visu lieliski atcerējos.

Ziņojuma gatavošanas gaitā jau pacēlu vecas pēcnāves, apskatīju baļķus. Problēmu analīzes laikā dažas detaļas var aizmirst vai arī dažas detaļas nebija pilnībā izpētītas, tāpēc dažos punktos var šķist, ka problēmas nav pilnībā izskatītas vai arī trūkst informācijas. Un tāpēc es lūdzu jūs mani atvainot par šo brīdi.

Kas ir Patroni?

• Šī ir veidne HA veidošanai. Tas ir teikts dokumentācijā. Un no mana viedokļa tas ir ļoti pareizs precizējums. Patroni nav sudraba lode, kas atrisinās visas jūsu problēmas, tas ir, jums ir jāpieliek pūles, lai tas darbotos un nestu labumu.
• Šis ir aģenta pakalpojums, kas tiek instalēts katrā datu bāzes pakalpojumā un ir sava veida sākuma sistēma jūsu Postgres. Tas palaiž Postgres, aptur, restartē, pārkonfigurē un maina jūsu klastera topoloģiju.
• Attiecīgi, lai saglabātu klastera stāvokli, tā pašreizējo attēlojumu, kā izskatās, ir nepieciešama sava veida krātuve. Un no šī viedokļa Patroni izvēlējās stāvokļa saglabāšanu ārējā sistēmā. Tā ir sadalīta konfigurācijas uzglabāšanas sistēma. Tas var būt Etcd, Consul, ZooKeeper vai kubernetes Etcd, t.i., viena no šīm opcijām.
• Un viena no Patroni funkcijām ir tāda, ka jūs varat izņemt automātisko filtrēšanu no kastes, tikai to iestatot. Ja salīdzinājumam ņemam Repmgr, tad filer tur ir iekļauts. Ar Repmgr mēs iegūstam pārslēgšanos, bet, ja mēs vēlamies autofiler, tad mums tas ir jākonfigurē papildus. Patroni jau ir izņemts no kastes.
• Un ir vēl daudzas citas lietas. Piemēram, konfigurāciju uzturēšana, jaunu reprodukciju ieliešana, dublēšana utt. Bet tas ir ārpus ziņojuma jomas, par to es nerunāšu.

Un neliels rezultāts ir tas, ka Patroni galvenais uzdevums ir labi un uzticami veikt autofailu, lai mūsu klasteris turpinātu darboties un lietojumprogramma nepamanītu izmaiņas klastera topoloģijā.

Bet, kad sākam lietot Patroni, mūsu sistēma kļūst nedaudz sarežģītāka. Ja agrāk mums bija Postgres, tad, izmantojot Patroni, mēs iegūstam pašu Patroni, mēs iegūstam DCS, kurā tiek saglabāts stāvoklis. Un tam visam kaut kā ir jāstrādā. Tātad, kas var noiet greizi?

Var pārtraukums:

• Postgres var salūzt. Tas var būt kapteinis vai kopija, viens no tiem var neizdoties.
• Patroni var salūzt.
• DCS, kurā tiek saglabāts stāvoklis, var sabojāt.
• Un tīkls var pārtrūkt.

Visus šos punktus es apsvēršu ziņojumā.

Es izskatīšu lietas, kad tās kļūst sarežģītākas, nevis no viedokļa, ka lieta ietver daudzas sastāvdaļas. Un no subjektīvo sajūtu viedokļa, ka man šis korpuss bija grūts, bija grūti to izjaukt ... un otrādi, kaut kāds korpuss bija viegls un to bija viegli izjaukt.

Un pirmais gadījums ir vieglākais. Tas ir gadījums, kad mēs paņēmām datu bāzes klasteru un izvietojām savu DCS krātuvi tajā pašā klasterī. Šī ir visizplatītākā kļūda. Tā ir kļūda, veidojot arhitektūru, t.i., apvienojot dažādas sastāvdaļas vienuviet.

Tātad, bija failētājs, ejam, lai tiktu galā ar notikušo.

Un šeit mēs esam ieinteresēti, kad fails noticis. Tas ir, mūs interesē šis brīdis, kad mainījās klastera stāvoklis.

Bet fails ne vienmēr notiek uzreiz, t.i., tas neaizņem nevienu laika vienību, tas var aizkavēties. Tas var būt ilgstošs.

Tāpēc tam ir sākuma laiks un beigu laiks, t.i., tas ir nepārtraukts notikums. Un mēs sadalām visus notikumus trīs intervālos: mums ir laiks pirms faila, faila laikā un pēc faila. Tas ir, mēs ņemam vērā visus notikumus šajā laika skalā.

Un pirmā lieta, kad notika fails, mēs meklējam notikušā cēloni, kas bija iemesls tam, kas noveda pie faila.

Ja skatāmies uz baļķiem, tie būs klasiskie Patroni baļķi. Tajās viņš mums stāsta, ka serveris ir kļuvis par galveno, un saimnieka loma ir pārgājusi uz šo mezglu. Šeit tas ir izcelts.

Tālāk mums ir jāsaprot, kāpēc fails notika, t.i., kādi notikumi radās, kuru dēļ galvenā loma tika pārvietota no viena mezgla uz citu. Un šajā gadījumā viss ir vienkārši. Sadarbojoties ar krātuves sistēmu, radās kļūda. Meistars saprata, ka nevar strādāt ar DCS, tas ir, radās kāda veida mijiedarbības problēma. Un saka, ka vairs nevar būt saimnieks un atkāpjas. Šī rinda “pazeminātais es” saka tieši to.

Ja aplūkojam notikumus pirms faila, mēs varam redzēt pašus iemeslus, kas radīja vedņa turpināšanas problēmu.

Ja apskatīsim Patroni žurnālus, redzēsim, ka mums ir daudz kļūdu, taimautu, t.i., Patroni aģents nevar strādāt ar DCS. Šajā gadījumā tas ir konsula aģents, kas sazinās pa 8500. portu.

Un problēma šeit ir tāda, ka Patroni un datu bāze darbojas vienā un tajā pašā resursdatorā. Un Consul serveri tika palaisti tajā pašā mezglā. Izveidojot slodzi uz serveri, radījām problēmas arī Consul serveriem. Viņi nevarēja pareizi sazināties.

Pēc kāda laika, kad slodze mazinājās, mūsu Patroni atkal varēja sazināties ar aģentiem. Atsākās normāls darbs. Un tas pats Pgdb-2 serveris atkal kļuva par galveno. Tas ir, notika neliels flips, kura dēļ mezgls atteicās no kapteiņa pilnvarām un pēc tam pārņēma tās vēlreiz, tas ir, viss atgriezās kā bijis.

Un to var uzskatīt par viltus trauksmi vai arī uzskatīt, ka Patroni visu izdarīja pareizi. Tas ir, viņš saprata, ka nevar uzturēt klastera stāvokli un atņēma savu autoritāti.

Un šeit problēma radās tāpēc, ka Consul serveri atrodas uz vienas aparatūras ar bāzēm. Attiecīgi jebkura slodze: neatkarīgi no tā, vai tā ir slodze uz diskiem vai procesoriem, tā ietekmē arī mijiedarbību ar Consul klasteru.

Un mēs nolēmām, ka tai nevajadzētu dzīvot kopā, konsulam piešķīrām atsevišķu kopu. Un Patroni jau strādāja ar atsevišķu konsulu, tas ir, bija atsevišķs Postgres klasteris, atsevišķs konsulu klasteris. Šī ir pamata instrukcija, kā nēsāt un turēt visas šīs lietas, lai tās nedzīvotu kopā.

Kā opciju varat pagriezt parametrus ttl, loop_wait, retry_timeout, t.i., mēģināt pārdzīvot šos īstermiņa slodzes maksimumus, palielinot šos parametrus. Bet tas nav vispiemērotākais variants, jo šī slodze var būt ilga laikā. Un mēs vienkārši pārsniegsim šīs šo parametru robežas. Un tas var nepalīdzēt.

Pirmā problēma, kā jūs saprotat, ir vienkārša. Paņēmām un salikām DCS kopā ar bāzi, sanāca problēma.

Otrā problēma ir līdzīga pirmajai. Tas ir līdzīgs ar to, ka mums atkal ir sadarbspējas problēmas ar DCS sistēmu.

Ja apskatīsim žurnālus, mēs redzēsim, ka mums atkal ir komunikācijas kļūda. Un Patroni saka, ka es nevaru mijiedarboties ar DCS, tāpēc pašreizējais kapteinis pāriet replicēšanas režīmā.

Vecmeistars kļūst par repliku, te Patroni izdodas, kā nākas. Tas palaiž pg_rewind, lai attītu darījumu žurnālu un pēc tam izveidotu savienojumu ar jauno galveno, lai panāktu jauno galveno. Šeit Patroni strādā, kā nākas.

Šeit mums jāatrod vieta, kas bija pirms faila, t.i., tās kļūdas, kuru dēļ mums bija fails. Un šajā sakarā ar Patroni apaļkokiem ir diezgan ērti strādāt. Viņš raksta vienus un tos pašus ziņojumus noteiktā intervālā. Un, ja mēs ātri sāksim ritināt šos žurnālus, tad no žurnāliem redzēsim, ka žurnāli ir mainījušies, kas nozīmē, ka ir sākušās dažas problēmas. Ātri atgriežamies šajā vietā, skatāmies, kas notiek.

Un parastā situācijā baļķi izskatās apmēram šādi. Tiek pārbaudīts slēdzenes īpašnieks. Un, ja, piemēram, ir mainījies īpašnieks, var notikt daži notikumi, uz kuriem Patroni ir jāreaģē. Bet šajā gadījumā mums viss ir kārtībā. Mēs meklējam vietu, kur sākās kļūdas.

Un, ritinot līdz vietai, kur sāka parādīties kļūdas, mēs redzam, ka mums ir bijusi automātiska failu pārslēgšana. Un tā kā mūsu kļūdas bija saistītas ar mijiedarbību ar DCS un mūsu gadījumā mēs izmantojām Consul, mēs skatāmies arī Consul žurnālus, kas tur notika.

Aptuveni salīdzinot lietvedības laiku un laiku konsulu žurnālos, redzam, ka mūsu kaimiņi konsulu klasterī sāka šaubīties par citu konsulu klastera dalībnieku eksistenci.

Un, ja paskatās citu konsula aģentu žurnālus, tad arī var redzēt, ka tur notiek kaut kāds tīkla sabrukums. Un visi Konsulu klastera dalībnieki apšauba viens otra esamību. Un tas bija stimuls iesniegtājam.

Ja paskatās uz to, kas notika pirms šīm kļūdām, tad var redzēt, ka ir visādas kļūdas, piemēram, termiņš, RPC kritās, tas ir, nepārprotami ir kaut kāda problēma konsulu klastera dalībnieku savstarpējā mijiedarbībā. .

Vienkāršākā atbilde ir tīkla remonts. Bet man, stāvot uz pjedestāla, to pateikt ir viegli. Taču apstākļi ir tādi, ka ne vienmēr klients var atļauties tīkla remontu. Viņš var dzīvot līdzstrāvas tīklā un nevarēs salabot tīklu, ietekmēt aprīkojumu. Un tāpēc ir vajadzīgas dažas citas iespējas.

Ir iespējas:

• Vienkāršākais variants, kas, manuprāt, ir rakstīts pat dokumentācijā, ir atspējot konsulu pārbaudes, tas ir, vienkārši iziet tukšu masīvu. Un mēs sakām konsula aģentam, lai viņš neizmanto nekādus čekus. Veicot šīs pārbaudes, mēs varam ignorēt šīs tīkla vētras un nesākt failu failu.
• Vēl viena iespēja ir vēlreiz pārbaudīt raft_multiplier. Tas ir paša Consul servera parametrs. Pēc noklusējuma tā ir iestatīta uz 5. Šī vērtība ir ieteikta dokumentācijā par inscenēšanas vidēm. Faktiski tas ietekmē ziņojumapmaiņas biežumu starp Consul tīkla dalībniekiem. Faktiski šis parametrs ietekmē pakalpojumu saziņas ātrumu starp konsulu klastera dalībniekiem. Un ražošanai jau ir ieteicams to samazināt, lai mezgli biežāk apmainītos ar ziņojumiem.
• Vēl viena mūsu piedāvātā iespēja ir palielināt Consul procesu prioritāti starp citiem operētājsistēmas procesu plānotāja procesiem. Ir tāds “jauks” parametrs, tas tikai nosaka procesu prioritāti, ko OS plānotājs ņem vērā, plānojot. Esam samazinājuši arī jauko vērtību Consul aģentiem, t.i. palielināja prioritāti, lai operētājsistēma Consul procesiem dotu vairāk laika darbam un koda izpildei. Mūsu gadījumā tas atrisināja mūsu problēmu.
• Vēl viena iespēja ir neizmantot Consul. Man ir draugs, kurš ir liels Etcd atbalstītājs. Un mēs regulāri ar viņu strīdamies, kas ir labāks utt. vai konsuls. Bet attiecībā uz to, kurš ir labāks, mēs parasti piekrītam viņam, ka Consulam ir aģents, kuram vajadzētu darboties katrā mezglā ar datu bāzi. Tas ir, Patroni mijiedarbība ar konsulu kopu notiek caur šo aģentu. Un šis aģents kļūst par sašaurinājumu. Ja ar aģentu kaut kas notiek, tad Patroni vairs nevar strādāt ar konsulu kopu. Un šī ir problēma. Etcd plānā aģenta nav. Patroni var strādāt tieši ar Etcd serveru sarakstu un jau sazināties ar tiem. Šajā sakarā, ja savā uzņēmumā izmantojat Etcd, tad Etcd, iespējams, būs labāka izvēle nekā Consul. Taču mūs, klientus, vienmēr ierobežo tas, ko klients ir izvēlējies un lieto. Un mums lielākoties ir konsuls visiem klientiem.
• Un pēdējais punkts ir parametru vērtību pārskatīšana. Mēs varam paaugstināt šos parametrus, cerot, ka mūsu īstermiņa tīkla problēmas būs īslaicīgas un neietilpst ārpus šo parametru diapazona. Tādā veidā mēs varam samazināt Patroni agresivitāti automātiskai failēšanai, ja rodas dažas tīkla problēmas.

Es domāju, ka daudzi, kas izmanto Patroni, ir pazīstami ar šo komandu.

Šī komanda parāda pašreizējo klastera stāvokli. Un no pirmā acu uzmetiena šis attēls var šķist normāls. Mums ir meistars, mums ir replika, nav replikācijas kavēšanās. Bet šis attēls ir normāls, līdz mēs zinām, ka šajā klasterī ir jābūt trim mezgliem, nevis diviem.

Attiecīgi bija autofails. Un pēc šī automātiskā faila mūsu kopija pazuda. Mums jānoskaidro, kāpēc viņa pazuda, un jāatgriež, jāatjauno. Un mēs atkal ejam uz žurnāliem un noskaidrojam, kāpēc mums bija automātiska failu pārslēgšana.

Šajā gadījumā par meistaru kļuva otrā kopija. Šeit viss ir kārtībā.

Un mums ir jāaplūko kopija, kas nokrita un kura nav klasterī. Mēs atveram Patroni žurnālus un redzam, ka mums radās problēma, veidojot savienojumu ar kopu pg_rewind posmā. Lai izveidotu savienojumu ar klasteru, jums ir jāattina darījumu žurnāls, jāpieprasa nepieciešamais darījumu žurnāls no galvenā un jāizmanto tas, lai panāktu galveno.

Šajā gadījumā mums nav darījumu žurnāla, un reprodukciju nevar palaist. Attiecīgi mēs apturam Postgres ar kļūdu. Un tāpēc tas nav klasterī.

Mums ir jāsaprot, kāpēc tas nav klasterī un kāpēc nebija žurnālu. Ejam pie jaunā meistara un skatāmies, kas viņam ir baļķos. Izrādās, kad pg_rewind tika izdarīts, notika kontrolpunkts. Un daži vecie darījumu žurnāli tika vienkārši pārdēvēti. Kad vecais meistars mēģināja pieslēgties jaunajam meistaram un vaicāt šos žurnālus, tie jau tika pārdēvēti, tie vienkārši neeksistēja.

Es salīdzināju laikspiedolus, kad šie notikumi notika. Un tur atšķirība ir burtiski 150 milisekundes, tas ir, kontrolpunkts tika pabeigts 369 milisekundēs, WAL segmenti tika pārdēvēti. Un burtiski 517. gadā pēc 150 milisekundēm sākās vecās kopijas attīšana. Tas ir, burtiski mums pietika ar 150 milisekundēm, lai kopija nevarētu izveidot savienojumu un nopelnīt.

Kādas ir iespējas?

Sākotnēji mēs izmantojām replikācijas slotus. Mēs domājām, ka tas ir labi. Lai gan pirmajā darbības posmā mēs izslēdzām slotus. Mums šķita, ka, ja sloti uzkrāj daudz WAL segmentu, mēs varam nomest master. Viņš nokritīs. Mēs kādu laiku cietām bez laika nišām. Un mēs sapratām, ka mums vajag slotus, mēs atdevām slotus.

Bet šeit ir problēma, ka, kad galvenais dodas uz repliku, tas dzēš slotus un izdzēš WAL segmentus kopā ar slotiem. Un, lai novērstu šo problēmu, mēs nolēmām paaugstināt parametru wal_keep_segments. Pēc noklusējuma tas ir 8 segmenti. Mēs to palielinājām līdz 1 un paskatījāmies, cik daudz brīvas vietas mums ir. Un mēs ziedojām 000 gigabaitus wal_keep_segments. Tas ir, pārslēdzoties, mums vienmēr ir 16 gigabaitu rezerve darījumu žurnāliem visos mezglos.

Un plus - tas joprojām ir aktuāls ilgtermiņa apkopes darbiem. Pieņemsim, ka mums ir jāatjaunina viena no replikām. Un mēs vēlamies to izslēgt. Mums ir jāatjaunina programmatūra, varbūt operētājsistēma, kaut kas cits. Un, kad mēs izslēdzam repliku, tiek noņemts arī šīs kopijas slots. Un, ja mēs izmantojam nelielu wal_keep_segments, tad, ja reprodukcija ilgstoši nebūs, darījumu žurnāli tiks zaudēti. Mēs izveidosim repliku, tas pieprasīs tos darījumu žurnālus, kur tas apstājās, bet tie var nebūt galvenajā. Un arī kopija nevarēs izveidot savienojumu. Tāpēc mēs glabājam lielus žurnālu krājumus.

Mums ir ražošanas bāze. Projekti jau ir procesā.

Bija failētājs. Iegājām un skatījāmies - viss kārtībā, replikas savās vietās, replikācijas aizkavēšanās nav. Arī žurnālos kļūdu nav, viss kārtībā.

Produkta komanda saka, ka vajadzētu būt dažiem datiem, bet mēs tos redzam no viena avota, bet mēs tos neredzam datu bāzē. Un mums ir jāsaprot, kas ar viņiem notika.

Skaidrs, ka pg_rewind tos palaida garām. Mēs to uzreiz sapratām, bet devāmies skatīties, kas notiek.

Žurnālos mēs vienmēr varam atrast, kad ir noticis fails, kurš kļuva par meistaru, un mēs varam noteikt, kurš bija vecais meistars un kad viņš vēlējās kļūt par repliku, t.i., šie žurnāli ir nepieciešami, lai uzzinātu darījumu žurnālu apjomu, kas bija pazudis.

Mūsu vecmeistars ir pārstartējis. Un Patroni tika reģistrēts autorun. Uzsākta Patroni. Pēc tam viņš sāka Postgres. Precīzāk, pirms Postgres palaišanas un pirms tā izveidošanas par reprodukciju, Patroni uzsāka pg_rewind procesu. Attiecīgi viņš izdzēsa daļu darījumu žurnālu, lejupielādēja jaunus un izveidoja savienojumu. Šeit Patroni strādāja gudri, tas ir, kā gaidīts. Klasteris ir atjaunots. Mums bija 3 mezgli, pēc filera 3 mezgli - viss forši.

Mēs esam zaudējuši dažus datus. Un mums ir jāsaprot, cik daudz mēs esam zaudējuši. Mēs meklējam tieši to brīdi, kad mums bija attīšana. Mēs to varam atrast šādos žurnāla ierakstos. Sākās attīšana, tur kaut ko izdarīja un beidzās.

Darījumu žurnālā jāatrod pozīcija, kurā vecais meistars pārtrauca darbu. Šajā gadījumā šī ir zīme. Un mums ir vajadzīga otrā atzīme, tas ir, attālums, ar kuru vecais meistars atšķiras no jaunā.

Mēs ņemam parasto pg_wal_lsn_diff un salīdzinām šīs divas atzīmes. Un šajā gadījumā mēs iegūstam 17 megabaitus. Daudz vai maz, katrs izlemj pats. Jo kādam 17 megabaiti nav daudz, kādam tas ir daudz un nepieņemami. Šeit katrs indivīds nosaka pats atbilstoši biznesa vajadzībām.

Bet ko mēs paši esam noskaidrojuši?

Pirmkārt, mums pašiem ir jāizlemj – vai mums vienmēr ir nepieciešams Patroni, lai pēc sistēmas atsāknēšanas automātiski startētu? Bieži gadās, ka jāiet pie vecmeistara, jāskatās, cik tālu viņš ir aizgājis. Varbūt pārbaudiet darījumu žurnāla segmentus un skatiet, kas tur ir. Un saprast, vai mēs varam pazaudēt šos datus, vai arī mums ir jāpalaiž vecais meistars savrupajā režīmā, lai šos datus izņemtu.

Un tikai pēc tam mums ir jāizlemj, vai mēs varam izmest šos datus vai varam tos atjaunot, pievienojiet šo mezglu kā kopiju mūsu klasterim.

Turklāt ir parametrs "maximum_lag_on_failover". Pēc noklusējuma, ja mana atmiņa mani neviļ, šī parametra vērtība ir 1 megabaits.

Kā viņš strādā? Ja mūsu replika replikācijas aizkavē atpaliek par 1 megabaitu datu, tad šī replika nepiedalās vēlēšanās. Un, ja pēkšņi notiek failu pārvēršana, Patroni skatās, kuras kopijas atpaliek. Ja viņiem atpaliek liels skaits darījumu žurnālu, viņi nevar kļūt par meistaru. Šī ir ļoti laba drošības funkcija, kas neļauj zaudēt daudz datu.

Bet pastāv problēma, ka replikācijas aizkave Patroni klasterī un DCS tiek atjaunināta ar noteiktu intervālu. Es domāju, ka 30 sekundes ir noklusējuma ttl vērtība.

Attiecīgi var būt situācija, ka replikām DCS ir viena replikācijas nobīde, bet patiesībā var būt pavisam cita nobīde vai arī lag nav vispār, t.i., šī lieta nav reāllaika. Un tas ne vienmēr atspoguļo patieso ainu. Un nav vērts ar to nodarboties ar izdomātu loģiku.

Un zaudējuma risks vienmēr paliek. Un sliktākajā gadījumā viena formula, bet vidējā gadījumā cita formula. Tas ir, plānojot Patroni ieviešanu un izvērtējot, cik daudz datu varam zaudēt, mums jāpaļaujas uz šīm formulām un aptuveni jāiedomājas, cik daudz datu varam zaudēt.

Un ir labas ziņas. Kad vecmeistars ir gājis pa priekšu, tad kaut kādu fona procesu dēļ var iet uz priekšu. Tas ir, bija kaut kāds autovakuums, viņš ierakstīja datus, saglabāja tos darījumu žurnālā. Un mēs varam viegli ignorēt un zaudēt šos datus. Šajā gadījumā nav nekādu problēmu.

Un šādi izskatās žurnāli, ja ir iestatīts maximum_lag_on_failover un ir noticis fails, un jums ir jāizvēlas jauns galvenais. Replika sevi vērtē kā nespējīgu piedalīties vēlēšanās. Un viņa atsakās piedalīties sacīkstēs par līderi. Un viņa gaida, kad tiks izvēlēts jauns meistars, lai pēc tam varētu ar to pieslēgties. Tas ir papildu pasākums pret datu zudumu.

Šeit mums ir produktu komanda, kas rakstīja, ka viņu produktam ir problēmas ar Postgres. Tajā pašā laikā nevar piekļūt pašam galvenajam, jo ​​tas nav pieejams caur SSH. Un arī automātiskais fails nenotiek.

Šis saimniekdators bija spiests atsāknēt. Atsāknēšanas dēļ notika automātisks fails, lai gan, kā es tagad saprotu, bija iespējams veikt manuālu automātisko failu. Un pēc pārstartēšanas mēs jau skatīsimies, kas mums bija ar pašreizējo meistaru.

Tajā pašā laikā mēs jau iepriekš zinājām, ka mums ir problēmas ar diskiem, tas ir, mēs jau no uzraudzības zinājām, kur rakt un ko meklēt.

Iekāpām postgres žurnālā, sākām skatīties, kas tur notiek. Mēs redzējām saistības, kas tur ilgst vienu, divas, trīs sekundes, kas nebūt nav normāli. Mēs redzējām, ka mūsu autovakuums ieslēdzas ļoti lēni un dīvaini. Un mēs diskā redzējām pagaidu failus. Tas ir, tie visi liecina par problēmām ar diskiem.

Mēs apskatījām sistēmas dmesg (kodola žurnālu). Un mēs redzējām, ka mums ir problēmas ar vienu no diskiem. Diska apakšsistēma bija programmatūra Raid. Mēs apskatījām /proc/mdstat un redzējām, ka mums trūkst viena diska. Tas ir, ir 8 disku reids, mums viena trūkst. Ja uzmanīgi aplūko slaidu, tad izvadā var redzēt, ka mums tur nav sde. Pie mums, nosacīti runājot, disks ir izkritis. Tas izraisīja diska problēmas, un arī lietojumprogrammām radās problēmas, strādājot ar Postgres kopu.

Un šajā gadījumā Patroni mums nekādi nepalīdzētu, jo Patroni nav uzdevums uzraudzīt servera stāvokli, diska stāvokli. Un mums ir jāuzrauga šādas situācijas ar ārēju uzraudzību. Mēs ātri pievienojām diska uzraudzību ārējai uzraudzībai.

Un radās tāda doma – vai paukošanas vai sargsuņa programmatūra mums varētu palīdzēt? Domājām, ka viņš šajā gadījumā diez vai mums būtu palīdzējis, jo problēmu laikā Patroni turpināja sadarboties ar DCS klasteri un nesaskatīja nekādu problēmu. Tas ir, no DCS un Patroni viedokļa ar klasteru viss bija kārtībā, lai gan patiesībā bija problēmas ar disku, bija problēmas ar datu bāzes pieejamību.

Manuprāt, šī ir viena no dīvainākajām problēmām, ko esmu pētījis ļoti ilgi, esmu lasījis daudz žurnālus, pārlasījis un nosaucis to par klasteru simulatoru.

Problēma bija tā, ka vecais meistars nevarēja kļūt par normālu repliku, t.i. Patroni to palaida, Patroni parādīja, ka šis mezgls bija klāt kā replika, bet tajā pašā laikā tā nebija normāla kopija. Tagad jūs redzēsiet, kāpēc. Tas ir tas, ko es esmu atturējis no šīs problēmas analīzes.

Un kā tas viss sākās? Sākās, tāpat kā iepriekšējā problēmā, ar disku bremzēm. Mums bija saistības uz sekundi, divām.

Bija sakaru pārtraukumi, t.i., tika saplēsti klienti.

Bija dažāda smaguma aizsprostojumi.

Un attiecīgi diska apakšsistēma nav īpaši atsaucīga.

Un visnoslēpumainākais man ir tūlītējais izslēgšanas pieprasījums, kas tika saņemts. Postgres ir trīs izslēgšanas režīmi:

• Tas ir jauki, kad mēs gaidām, kad visi klienti atvienosies paši.
• Ir ātri, kad mēs piespiežam klientus atvienoties, jo mēs gatavojamies izslēgt.
• Un nekavējoties. Šajā gadījumā tūlītēja pat neliek klientiem izslēgt, tas vienkārši izslēdzas bez brīdinājuma. Un visiem klientiem operētājsistēma jau sūta RST ziņojumu (TCP ziņojumu, ka savienojums ir pārtraukts un klientam vairs nav ko ķert).

Kas sūtīja šo signālu? Postgres fona procesi šādus signālus viens otram nesūta, t.i., tas ir kill-9. Viņi nesūta tādas lietas viens otram, viņi tikai reaģē uz tādām lietām, t.i., šī ir Postgres avārijas restartēšana. Kas to sūtīja, es nezinu.

Es paskatījos uz "pēdējo" komandu un redzēju vienu cilvēku, kurš arī pieteicās šajā serverī kopā ar mums, bet es biju pārāk kautrīgs, lai uzdotu jautājumu. Varbūt tas bija nogalināt -9. Es redzētu nogalināt -9 baļķos, jo Postgres saka, ka vajadzēja kill -9, bet es to neredzēju žurnālos.

Paskatoties tālāk, redzēju, ka Patroni diezgan ilgi nerakstīja žurnālam - 54 sekundes. Un, ja salīdzinām divus laikspiedolus, aptuveni 54 sekundes nebija neviena ziņojuma.

Un šajā laikā notika autofails. Patroni šeit atkal paveica lielisku darbu. Mūsu vecmeistars nebija pieejams, ar viņu kaut kas notika. Un sākās jauna meistara vēlēšanas. Šeit viss izdevās labi. Mūsu pgsql01 ir kļuvis par jauno līderi.

Mums ir kopija, kas ir kļuvusi par meistaru. Un ir arī otra atbilde. Un bija problēmas ar otro repliku. Viņa mēģināja pārkonfigurēt. Kā es saprotu, viņa mēģināja mainīt recovery.conf, restartēt Postgres un izveidot savienojumu ar jauno meistaru. Viņa ik pēc 10 sekundēm raksta ziņas, ka mēģina, bet viņai neizdodas.

Un šo mēģinājumu laikā vecmeistaram pienāk tūlītējas izslēgšanas signāls. Master ir restartēts. Un arī atkopšana apstājas, jo vecais meistars pārstartējas. Tas nozīmē, ka kopija nevar izveidot savienojumu ar to, jo tā ir izslēgšanas režīmā.

Kādā brīdī tas darbojās, bet replikācija nesākās.

Mans vienīgais minējums ir tāds, ka failā recovery.conf bija veca galvenā adrese. Un, kad parādījās jauns meistars, otrā kopija joprojām mēģināja savienoties ar veco meistaru.

Kad Patroni startēja otrajā reprodukcijā, mezgls tika palaists, bet nevarēja replicēt. Un izveidojās replikācijas nobīde, kas izskatījās apmēram šādi. Tas ir, visi trīs mezgli bija savās vietās, bet otrais mezgls atpalika.

Tajā pašā laikā, ja paskatās uz ierakstītajiem žurnāliem, var redzēt, ka replikāciju nevarēja sākt, jo darījumu žurnāli bija atšķirīgi. Un tie darījumu žurnāli, ko piedāvā meistars un kas ir norādīti atkopšanas.conf, vienkārši neatbilst mūsu pašreizējam mezglam.

Un šeit es pieļāvu kļūdu. Man bija jāierodas un jāskatās, kas ir failā recovery.conf, lai pārbaudītu savu hipotēzi, ka mēs izveidojam savienojumu ar nepareizo meistaru. Bet tad es tikai ar to nodarbojos, un man tas neienāca prātā, vai arī es redzēju, ka kopija atpaliek un būs jāuzpilda, tas ir, es kaut kā strādāju neuzmanīgi. Šī bija mana locītava.

Pēc 30 minūtēm jau ieradās admins, t.i., es restartēju Patroni uz replikas. Pieliku jau punktu, izdomāju, ka būs jāuzpilda. Un domāju – restartēšu Patroni, varbūt iznāks kas labs. Sākās atveseļošanās. Un bāze pat atvērās, tā bija gatava pieņemt savienojumus.

Ir sākusies replikācija. Taču pēc minūtes viņa nokrita ar kļūdu, ka darījumu žurnāli viņai nav piemēroti.

Es domāju, ka es restartēšu vēlreiz. Es vēlreiz restartēju Patroni un nevis Postgres restartēju, bet gan Patroni, cerot, ka tas maģiski sāks datu bāzi.

Replikācija sākās no jauna, bet atzīmes darījumu žurnālā bija atšķirīgas, tās nebija tādas pašas kā iepriekšējā starta mēģinājumā. Replikācija atkal tika apturēta. Un vēstījums jau bija nedaudz atšķirīgs. Un tas man nebija īpaši informatīvs.

Un tad man ienāk prātā - kā būtu, ja es restartēju Postgres, šajā laikā es izveidoju kontrolpunktu uz pašreizējo galveno, lai pārvietotu punktu darījumu žurnālā nedaudz uz priekšu, lai atkopšana sāktos no cita brīža? Turklāt mums joprojām bija WAL krājumi.

Es restartēju Patroni, veicu pāris kontrolpunktus uz galveno, pāris restartēšanas punktus uz replikas, kad tā tika atvērta. Un tas palīdzēja. Es ilgi domāju, kāpēc tas palīdzēja un kā tas darbojas. Un replika sākās. Un replikācija vairs nebija saplēsta.

Tāda problēma man ir viena no mistiskākajām, par kuru es joprojām prātoju, kas tur īsti notika.

Kādas ir sekas šeit? Patroni var strādāt kā paredzēts un bez kļūdām. Bet tajā pašā laikā tas nav 100% garantija, ka ar mums viss ir kārtībā. Replika var sākties, bet tā var būt daļēji darba stāvoklī, un lietojumprogramma nevar strādāt ar šādu repliku, jo būs veci dati.

Un pēc failētāja vienmēr ir jāpārbauda, ​​vai ar klasteru viss ir kārtībā, tas ir, ir nepieciešamais replikāciju skaits, nav replikācijas nobīdes.

Kad mēs izskatīsim šos jautājumus, es sniegšu ieteikumus. Es mēģināju tos apvienot divos slaidos. Iespējams, visus stāstus varētu apvienot divos slaidos un tikai izstāstīt.

Lietojot Patroni, jums ir jāveic uzraudzība. Jums vienmēr jāzina, kad notika automātiskā failu pārvēršana, jo, ja nezināt, ka jums ir bijusi automātiskā failu pārvēršana, jūs nevarat kontrolēt kopu. Un tas ir slikti.

Pēc katra faila mums vienmēr ir manuāli jāpārbauda klasteris. Mums ir jāpārliecinās, ka mums vienmēr ir atjaunināts reprodukciju skaits, nav replikācijas aizkaves, nav kļūdu žurnālos, kas saistīti ar straumēšanas replikāciju, izmantojot Patroni, ar DCS sistēmu.

Automatizācija var veiksmīgi darboties, Patroni ir ļoti labs instruments. Tas var darboties, taču tas nenovedīs klasteru vēlamajā stāvoklī. Un, ja mēs par to neuzzināsim, mēs nonāksim nepatikšanās.

Un Patroni nav sudraba lode. Mums joprojām ir jāsaprot, kā darbojas Postgres, kā darbojas replikācija un kā Patroni darbojas ar Postgres, un kā tiek nodrošināta saziņa starp mezgliem. Tas ir nepieciešams, lai varētu novērst problēmas ar rokām.

Kā pievērsties diagnozes jautājumam? Sanāca tā, ka strādājam ar dažādiem klientiem un nevienam nav ELK kaudzes, un mums ir jāsakārto žurnāli, atverot 6 konsoles un 2 cilnes. Vienā cilnē tie ir katra mezgla Patroni žurnāli, otrā cilnē tie ir Consul žurnāli vai, ja nepieciešams, Postgres. To ir ļoti grūti diagnosticēt.

Kādas pieejas esmu izstrādājis? Pirmkārt, es vienmēr skatos, kad ir ieradies fails. Un man šī ir ūdensšķirtne. Es skatos, kas notika pirms vīlītes, faila laikā un pēc faila. Fileover ir divas atzīmes: tas ir sākuma un beigu laiks.

Pēc tam es meklēju žurnālos notikumus pirms faila, kas bija pirms faila, t.i., es meklēju iemeslus, kāpēc fails notika.

Un tas dod priekšstatu par to, kā saprast, kas noticis un ko var darīt nākotnē, lai šādi apstākļi nerastos (un rezultātā nav faila).

Un kur mēs parasti skatāmies? ES skatos:

• Pirmkārt, uz Patroni žurnāliem.
• Tālāk es aplūkoju Postgres žurnālus vai DCS žurnālus atkarībā no tā, kas tika atrasts Patroni žurnālos.
• Un arī sistēmas žurnāli dažkārt sniedz izpratni par to, kas izraisīja failu.

Kā es jūtos pret Patroni? Man ar Patroni ir ļoti labas attiecības. Manuprāt, tas ir labākais, kāds šodien ir. Es zinu daudzus citus produktus. Tie ir Stolon, Repmgr, Pg_auto_failover, PAF. 4 instrumenti. Es tos visus izmēģināju. Patroni ir mans mīļākais.

Ja viņi man jautā: "Vai es iesaku Patroni?". Teikšu jā, jo man patīk Patroni. Un es domāju, ka es iemācījos to pagatavot.

Ja vēlaties uzzināt, kādas ir citas problēmas ar Patroni bez manis minētajām problēmām, vienmēr varat apskatīt lapu jautājumi vietnē GitHub. Tur ir daudz dažādu stāstu un tiek apspriesti daudzi interesanti jautājumi. Rezultātā tika ieviestas un novērstas dažas kļūdas, tas ir, šī ir interesanta lasāmviela.

Ir daži interesanti stāsti par cilvēkiem, kuri šauj sev kājā. Ļoti informatīvs. Jūs izlasiet un saprotat, ka tas nav jādara. Es atzīmēju sevi.

Un es vēlos teikt lielu paldies Zalando par šī projekta izstrādi, proti, Aleksandram Kukuškinam un Aleksejam Kļukinam. Aleksejs Kļukins ir viens no līdzautoriem, viņš vairs nestrādā Zalando, taču tie ir divi cilvēki, kas sāka strādāt ar šo produktu.

Un es domāju, ka Patroni ir ļoti forša lieta. Priecājos, ka viņa eksistē, ar viņu ir interesanti. Un liels paldies visiem atbalstītājiem, kuri raksta ielāpus Patroni. Es ceru, ka Patroni ar vecumu kļūs nobriedušāks, foršāks un efektīvāks. Tas jau ir funkcionāls, bet es ceru, ka tas kļūs vēl labāks. Tāpēc, ja plānojat lietot Patroni, tad nebaidieties. Tas ir labs risinājums, to var ieviest un izmantot.

Tas ir viss. Ja jums ir jautājumi, jautājiet.

jautājumi

Paldies par ziņojumu! Ja pēc vīlētāja tur tomēr vajag ļoti rūpīgi paskatīties, tad kāpēc mums vajadzīgs automātiskais vīlētājs?

Jo tās ir jaunas lietas. Mēs ar viņu esam tikai gadu. Labāk būt drošam. Mēs vēlamies ienākt un redzēt, ka viss tiešām ir izdevies tā, kā tam vajadzētu būt. Tas ir pieaugušo neuzticības līmenis - labāk vēlreiz pārbaudīt un redzēt.

Piemēram, mēs gājām no rīta un paskatījāmies, vai ne?

Ne no rīta, mēs parasti uzzinām par automātisko failu gandrīz nekavējoties. Mēs saņemam paziņojumus, redzam, ka ir noticis automātiskais fails. Gandrīz uzreiz ejam un skatāmies. Taču visas šīs pārbaudes ir jānovirza uzraudzības līmenī. Ja piekļūstat Patroni, izmantojot REST API, pastāv vēsture. Pēc vēstures varat redzēt laikspiedolus, kad notika fails. Pamatojoties uz to, var veikt uzraudzību. Var redzēt vēsturi, cik notikumu bija. Ja mums ir vairāk notikumu, ir noticis automātiskais fails. Jūs varat iet un redzēt. Vai arī mūsu uzraudzības automatizācija pārbaudīja, vai mums ir visas kopijas, nav aizkavēšanās un viss ir kārtībā.

Paldies!

Liels paldies par lielisko stāstu! Ja mēs DCS klasteri pārcēlām kaut kur tālu no Postgres klastera, tad arī šim klasterim ir periodiski jākopj? Kāda ir labākā prakse, kad daži DCS klastera elementi ir jāizslēdz, ar tiem kaut kas jādara utt.? Kā visa šī struktūra izdzīvo? Un kā jūs darāt šīs lietas?

Vienam uzņēmumam bija jāizveido problēmu matrica, kas notiek, ja sabojājas kāda no sastāvdaļām vai vairākas sastāvdaļas. Saskaņā ar šo matricu mēs secīgi izejam cauri visiem komponentiem un veidojam scenārijus šo komponentu atteices gadījumā. Attiecīgi katram kļūmes scenārijam jums var būt rīcības plāns atveseļošanai. Un DCS gadījumā tā ir daļa no standarta infrastruktūras. Un administrators to administrē, un mēs jau paļaujamies uz administratoriem, kas to administrē, un viņu spēju to novērst negadījumu gadījumā. Ja DCS vispār nav, tad izvietojam, bet tajā pašā laikā īpaši neuzraugām, jo ​​neatbildam par infrastruktūru, bet sniedzam ieteikumus, kā un ko uzraudzīt.

Tas ir, vai es pareizi sapratu, ka man ir jāatspējo Patroni, jāatspējo fails, jāatspējo viss, pirms kaut ko daru ar saimniekiem?

Tas ir atkarīgs no tā, cik mezglu mums ir DCS klasterī. Ja mezglu ir daudz un ja mēs atspējojam tikai vienu no mezgliem (reprodukciju), tad klasteris uztur kvorumu. Un Patroni turpina darboties. Un nekas netiek iedarbināts. Ja mums ir dažas sarežģītas darbības, kas ietekmē vairāk mezglu, kuru neesamība var sabojāt kvorumu, tad - jā, varētu būt jēga Patroni apturēt. Tam ir atbilstoša komanda - patronictl pause, patronictl resume. Mēs vienkārši pauzējam, un automātiskais fails tajā laikā nedarbojas. Mēs veicam DCS klastera apkopi, pēc tam pārtraucam pauzi un turpinām dzīvot.

Thank you very much!

Liels paldies par ziņojumu! Kā produktu komanda uztver datu zudumu?

Produktu komandām ir vienalga, un komandu vadītāji ir noraizējušies.

Kādas ir garantijas?

Garantijas ir ļoti sarežģītas. Aleksandram Kukuškinam ir ziņojums “Kā aprēķināt RPO un RTO”, t.i., atkopšanas laiks un cik daudz datu varam zaudēt. Es domāju, ka mums ir jāatrod šie slaidi un tie jāizpēta. Cik atceros, ir konkrēti soļi, kā šīs lietas aprēķināt. Cik daudz darījumu mēs varam zaudēt, cik daudz datu varam zaudēt. Kā opciju mēs varam izmantot sinhrono replikāciju Patroni līmenī, taču tas ir abpusēji griezīgs zobens: vai nu mums ir datu uzticamība, vai arī mēs zaudējam ātrumu. Ir sinhronā replikācija, taču tā arī negarantē 100% aizsardzību pret datu zudumu.

Aleksej, paldies par lielisko ziņojumu! Vai jums ir pieredze ar Patroni izmantošanu nulles līmeņa aizsardzībai? Tas ir, savienojumā ar sinhrono gaidīšanas režīmu? Šis ir pirmais jautājums. Un otrais jautājums. Jūs esat izmantojis dažādus risinājumus. Mēs izmantojām Repmgr, bet bez autofiler, un tagad mēs plānojam iekļaut autofiler. Un mēs uzskatām Patroni kā alternatīvu risinājumu. Ko jūs varat teikt kā priekšrocības salīdzinājumā ar Repmgr?

Pirmais jautājums bija par sinhronajām replikām. Sinhrono replikāciju šeit neviens neizmanto, jo visi baidās (vairāki klienti jau to izmanto, principā viņi nepamanīja veiktspējas problēmas - Runātāja piezīme). Bet mēs paši esam izstrādājuši noteikumu, ka sinhronās replikācijas klasterī ir jābūt vismaz trim mezgliem, jo, ja mums ir divi mezgli un ja galvenais vai replika neizdodas, tad Patroni pārslēdz šo mezglu uz Standalone režīmu, lai programma turpinātu darboties. strādāt. Šajā gadījumā pastāv datu zuduma risks.

Attiecībā uz otro jautājumu mēs esam izmantojuši Repmgr un joprojām darām to ar dažiem klientiem vēsturisku iemeslu dēļ. Ko var teikt? Patroni komplektācijā ietilpst automātiskais filtrs, un Repmgr ir automātiskais filtrs kā papildu funkcija, kas ir jāiespējo. Mums ir jāpalaiž Repmgr dēmons katrā mezglā, un tad mēs varam konfigurēt automātisko failu.

Repmgr pārbauda, ​​vai Postgres mezgli ir dzīvi. Repmgr procesi pārbauda viens otra esamību, tā nav pārāk efektīva pieeja. var būt sarežģīti tīkla izolācijas gadījumi, kad liels Repmgr klasteris var sadalīties vairākos mazākos un turpināt darbu. Sen nesekoju līdzi Repmgr, varbūt salaboja...vai varbūt nē. Bet informācijas noņemšana par klastera stāvokli DCS, kā to dara Stolon, Patroni, ir visizdevīgākā iespēja.

Aleksej, man ir jautājums, iespējams, lāgāks. Vienā no pirmajiem piemēriem jūs pārvietojāt DCS no vietējās mašīnas uz attālo resursdatoru. Mēs saprotam, ka tīkls ir lieta, kurai ir savas īpašības, tas dzīvo pats par sevi. Un kas notiek, ja kāda iemesla dēļ DCS klasteris kļūst nepieejams? Iemeslus nepateikšu, to var būt ļoti daudz: no tīklotāju līkajām rokām līdz reālām problēmām.

Es to nepateicu skaļi, bet DCS klasterim ir jābūt arī kļūmjpārlēcei, t.i., tas ir nepāra skaits mezglu, lai nodrošinātu kvorumu. Kas notiek, ja DCS klasteris kļūst nepieejams vai nevar sasniegt kvorumu, t.i., tīkla sadalījums vai mezgla kļūme? Šajā gadījumā Patroni klasteris pāriet tikai lasīšanas režīmā. Patroni klasteris nevar noteikt klastera stāvokli un to, ko darīt. Tas nevar sazināties ar DCS un saglabāt tur jauno klastera stāvokli, tāpēc viss klasteris tiek iestatīts tikai lasāmā režīmā. Un gaida vai nu manuālu operatora iejaukšanos, vai arī DCS atjaunošanos.

Aptuveni runājot, DCS mums kļūst par tikpat svarīgu pakalpojumu kā pati bāze?

Jā jā. Tik daudzos mūsdienu uzņēmumos pakalpojumu atklāšana ir neatņemama infrastruktūras sastāvdaļa. Tas tiek ieviests vēl pirms tam, kad infrastruktūrā vēl nebija datu bāzes. Relatīvi runājot, infrastruktūra tika palaista, izvietota DC, un mums uzreiz ir Service Discovery. Ja tas ir konsuls, tad uz tā var izveidot DNS. Ja tas ir Etcd, iespējams, ir daļa no Kubernetes klastera, kurā tiks izvietots viss pārējais. Man šķiet, ka Service Discovery jau ir mūsdienu infrastruktūras neatņemama sastāvdaļa. Un viņi par to domā daudz agrāk nekā par datu bāzēm.

Paldies!

Avots: www.habr.com