issues<\/a><\/noindex> p\u00e5 GitHub. Der er mange forskellige historier, og der diskuteres mange interessante problemer. Og i sidste ende har nogle fejl blevet registreret og l\u00f8st, dvs. det er interessant l\u00e6sning. <\/p>\n<\/p>\n
Der er interessante historier om, hvordan folk skyder sig selv i foden. Meget l\u00e6rerigt. Du l\u00e6ser og forst\u00e5r, at man ikke skal g\u00f8re s\u00e5dan. Man s\u00e6tter sig selv en checkmark. <\/p>\n
<\/p>\n
Og jeg vil gerne give en stor tak til Zalando for at de udvikler dette projekt, is\u00e6r til Alexander Kukushkin og Alexey Klyukin. Alexey Klyukin er en af medforfatterne, han arbejder ikke l\u00e6ngere hos Zalando, men det er to personer, der begyndte at arbejde med dette produkt. <\/p>\n
<\/p>\n
Og jeg mener, at Patroni er en virkelig cool ting. Jeg er glad for, at den findes, det er sp\u00e6ndende. Og en stor tak til alle bidragsydere, der skriver patches til Patroni. Jeg h\u00e5ber, at Patroni med tiden bliver mere modnet, cool og fungerende. Den fungerer allerede, men jeg h\u00e5ber, at den bliver endnu bedre. S\u00e5 hvis du planl\u00e6gger at bruge Patroni, s\u00e5 v\u00e6r ikke bange. Det er en god l\u00f8sning, det kan implementeres og bruges. <\/p>\n
<\/p>\n
Det var alt. Hvis du har sp\u00f8rgsm\u00e5l, s\u00e5 sp\u00f8rg endelig.<\/p>\n
<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l<\/p>\n
<\/p>\n
Tak for pr\u00e6sentationen! Hvis vi stadig skal se meget grundigt efter en failover, hvorfor har vi s\u00e5 en automatisk failover?<\/em> <\/p>\n<\/p>\n
Fordi det er en ny ting. Vi har arbejdet med det i kun et \u00e5r. Det er bedre at v\u00e6re forsigtig. Vi \u00f8nsker at g\u00e5 ind og se, om alt virkelig har fungeret som det skal. Det er et niveau af voksent mistillid \u2013 det er bedre at efterkontrollere og se. <\/p>\n
<\/p>\n
For eksempel, vi gik ind om morgenen og kiggede, ikke?<\/em><\/p>\n<\/p>\n
Ikke om morgenen, vi f\u00e5r normalt besked om auto-failover n\u00e6sten med det samme. Vi modtager notifikationer, vi ser, at auto-failoveren fandt sted. Vi g\u00e5r n\u00e6sten med det samme ind og kigger. Men alle disse tjek skal overg\u00e5s til overv\u00e5gningsniveauet. Hvis man henvender sig til Patroni via REST API, er der en historie. Ud fra historien kan man se tidsstempler for, hvorn\u00e5r failoveren skete. Baseret p\u00e5 dette kan man lave overv\u00e5gning. Man kan se historien og hvor mange h\u00e6ndelser der har v\u00e6ret. Hvis vi har f\u00e5et flere h\u00e6ndelser, betyder det, at der har v\u00e6ret en auto-failover. Man kan g\u00e5 ind og tjekke. Eller vores automatisering i overv\u00e5gningen har tjekket, at alle vores repliker er p\u00e5 plads, der ikke er nogen lag, og alt er i orden. <\/p>\n
<\/p>\n
Tak!<\/em><\/p>\n<\/p>\n
Tusind tak for den fremragende pr\u00e6sentation! Hvis vi flyttede DCS-klienten langt v\u00e6k fra Postgres-klienten, skal denne klient s\u00e5 ogs\u00e5 vedligeholdes periodisk? Hvilke best practices er der for, hvilke dele af DCS-klienten der skal slukkes, hvad der skal g\u00f8res osv.? Hvordan fungerer hele denne struktur under s\u00e5danne omst\u00e6ndigheder? Og hvordan skal disse ting g\u00f8res?<\/em><\/p>\n<\/p>\n
For \u00e9n virksomhed var det n\u00f8dvendigt at lave en problemmatrix for, hvad der sker, hvis en eller flere komponenter fejler. Baseret p\u00e5 denne matrix gennemg\u00e5r vi systematisk alle komponenter og skaber scenarier i tilf\u00e6lde af, at disse komponenter svigter. Hver fejlscenarie kan derfor have en handlingsplan for genopretning. Og for DCS er det en del af standardinfrastrukturen. Administratoren administrerer det, og vi stoler allerede p\u00e5 administratorer, der styrer dette, og deres evne til at reparere det i tilf\u00e6lde af en n\u00f8dsituation. Hvis DCS slet ikke findes, er det os, der implementerer det, men vi f\u00f8lger ikke n\u00f8je med, fordi vi ikke har ansvaret for infrastrukturen, men giver anbefalinger til, hvad og hvordan der skal overv\u00e5ges. <\/p>\n
<\/p>\n
Dvs. har jeg forst\u00e5et korrekt, at man skal deaktivere Patroni, deaktivere failoveren, deaktivere alt, f\u00f8r man g\u00f8r noget med v\u00e6rterne?<\/em><\/p>\n<\/p>\n
Det afh\u00e6nger af, hvor mange knuder vi har i DCS-klusteret. Hvis der er mange knuder, og hvis vi kun tager \u00e9n knude (replica) ud af drift, s\u00e5 er der stadig quorum i klusteret. Og Patroni forbliver funktionsdygtig. Og der trigges ikke noget. Hvis vi har nogle komplekse operationer, der involverer flere knuder, hvis frav\u00e6r kan bryde quorum, s\u00e5 ja, det kan give mening at s\u00e6tte Patroni p\u00e5 pause. Han har en tilsvarende kommando \u2013 patronictl pause, patronictl resume. Vi s\u00e6tter bare p\u00e5 pause, og autofailover aktiveres ikke i denne periode. Vi udf\u00f8rer vedligeholdelse p\u00e5 DCS-klusteret, og derefter fjerner vi pausen og forts\u00e6tter med at k\u00f8re.<\/p>\n
<\/p>\n
Mange tak!<\/em><\/p>\n<\/p>\n
Tusind tak for pr\u00e6sentationen! Hvordan forholder produktteamet sig til, at data kan g\u00e5 tabt?<\/em> <\/p>\n<\/p>\n
Produktteamet er ligeglade, men teamlederne er bekymrede. <\/p>\n
<\/p>\n
Hvilke garantier findes der?<\/em><\/p>\n<\/p>\n
Det er meget sv\u00e6rt med garantier. Der er et foredrag af Alexander Kukushkin \"Hvordan man beregner RPO og RTO\", alts\u00e5 genopretningstid og hvor meget data vi kan miste. Jeg tror, vi skal finde disse slides og studere dem. S\u00e5 vidt jeg husker, er der konkrete trin til, hvordan man beregner disse ting. Hvor mange transaktioner vi kan miste, hvor meget data vi kan miste. Som en mulighed kan vi bruge synkron replikation p\u00e5 Patroni-niveau, men det er en tve\u00e6gget sv\u00e6rd: vi har enten dataintegritet eller taber i hastighed. Der er synkron replikation, men den garanterer heller ikke 100% beskyttelse mod datatab.<\/p>\n
<\/p>\n
Alexey, tak for en fantastisk pr\u00e6sentation! Har du erfaring med at bruge Patroni til zero level protection? Alts\u00e5 i kombination med synkron standby? Det er det f\u00f8rste sp\u00f8rgsm\u00e5l. Det andet sp\u00f8rgsm\u00e5l. I har brugt forskellige l\u00f8sninger. Vi har brugt Repmgr, men uden autofailover og planl\u00e6gger nu at tilf\u00f8je autofailover. Vi overvejer Patroni som en alternativ l\u00f8sning. Hvad kan du sige er fordelene i forhold til Repmgr?<\/em><\/p>\n<\/p>\n
Det f\u00f8rste sp\u00f8rgsm\u00e5l om synkrone replikater var. Ingen bruger synkron replikation, fordi alle er bange for det (Flere kunder bruger det allerede, og har ikke bem\u00e6rket problemer med ydeevnen \u2014 Noter fra pr\u00e6sent\u00f8ren<\/em>). Men vi har lavet en regel for os selv om, at der skal v\u00e6re mindst tre noder i en synkron replikationsklynge, fordi hvis vi har to noder, og hvis master eller replika g\u00e5r ned, s\u00e5 overf\u00f8rer Patroni denne node til Standalone-tilstand, s\u00e5 applikationen fortsat kan k\u00f8re. I dette tilf\u00e6lde er der risici for datatab.<\/p>\n<\/p>\n
Vedr\u00f8rende det andet sp\u00f8rgsm\u00e5l, har vi brugt Repmgr og bruger det stadig hos nogle af vores kunder af historiske grunde. Hvad kan vi sige? I Patroni kommer auto-failover som standard, mens auto-failover i Repmgr kommer som en ekstra funktion, der skal aktiveres. Vi skal starte Repmgr daemon p\u00e5 hver node, og s\u00e5 kan vi konfigurere auto-failover. <\/p>\n
<\/p>\n
Repmgr tjekker, om Postgres-noderne er i live. Repmgr-processerne tjekker for hinandens eksistens, hvilket ikke er en s\u00e6rlig effektiv tilgang, da der kan opst\u00e5 komplekse tilf\u00e6lde af netv\u00e6rksisolering, hvor en stor Repmgr-klynge kan splittes op i flere sm\u00e5 og forts\u00e6tte med at fungere. Jeg har ikke fulgt med i Repmgr i lang tid, m\u00e5ske har de fikset det ... eller m\u00e5ske ikke. Men det at flytte information om klyngens tilstand til DCS, som Stolon og Patroni g\u00f8r, er den mest levedygtige l\u00f8sning. <\/p>\n
<\/p>\n
Alexey, jeg har et sp\u00f8rgsm\u00e5l, m\u00e5ske et naivt. I et af de f\u00f8rste eksempler tog I DCS ud fra den lokale maskine og over til en fjern node. Vi forst\u00e5r, at netv\u00e6rket er noget, der har sine egne s\u00e6regenheder, det lever sit eget liv. Hvad sker der, hvis DCS-klyngen bliver utilg\u00e6ngelig af en eller anden grund? Jeg vil ikke n\u00e6vne \u00e5rsagerne, der kan v\u00e6re mange: fra d\u00e5rligt arbejde af netv\u00e6rksteknikere til reelle problemer.<\/em> <\/p>\n<\/p>\n
Jeg n\u00e6vnte ikke h\u00f8jt, men DCS-klyngen skal ogs\u00e5 v\u00e6re fejlbestandig, dvs. det skal v\u00e6re et ulige antal noder, s\u00e5 kvorum kan samles. Hvad sker der, hvis DCS-klyngen bliver utilg\u00e6ngelig, eller ikke kan samle et kvorum, dvs. en form for netv\u00e6rks-split eller nedbrud af noder? I dette tilf\u00e6lde g\u00e5r Patroni-klyngen over i read only-tilstand. Patroni-klyngen kan ikke bestemme status for klyngen og hvad den skal g\u00f8re. Den kan ikke kontakte DCS og gemme den nye status for klyngen, derfor g\u00e5r hele klyngen ind i read only. Den venter enten p\u00e5 manuel indgriben fra operat\u00f8ren eller p\u00e5 at DCS bliver genoprettet.<\/p>\n
<\/p>\n
Groft sagt bliver DCS for os en tjeneste, der er liges\u00e5 vigtig som selve databasen?<\/em><\/p>\n<\/p>\n
Ja ja. I mange moderne virksomheder er Service Discovery en uundg\u00e5elig del af infrastrukturen. Det implementeres ofte f\u00f8r databasen i infrastrukturen overhovedet er til stede. For at sige det p\u00e5 en anden m\u00e5de, n\u00e5r infrastrukturen er startet op, og datacenteret er bygget, s\u00e5 har vi automatisk Service Discovery. Hvis det er Consul, kan DNS ogs\u00e5 bygges p\u00e5 det. Hvis det er Etcd, kan det v\u00e6re en del af Kubernetes-klyngen, hvor alt andet allerede vil blive implementeret. Jeg mener, at Service Discovery allerede er en uundg\u00e5elig del af moderne infrastrukturer, og man t\u00e6nker p\u00e5 det meget tidligere end databaser. <\/p>\n
<\/p>\n
Tak!<\/em><\/p>\nKilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0441\u043d\u043e\u0432\u043d\u0430\u044f \u0446\u0435\u043b\u044c Patroni \u2014 \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u0435 High Availability \u0434\u043b\u044f PostgreSQL. \u041d\u043e Patroni \u2014 \u044d\u0442\u043e \u043b\u0438\u0448\u044c template, \u0430 \u043d\u0435 \u0433\u043e\u0442\u043e\u0432\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 (\u0447\u0442\u043e, \u0432 \u043e\u0431\u0449\u0435\u043c, \u0438 \u0441\u043a\u0430\u0437\u0430\u043d\u043e \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438). \u041d\u0430 \u043f\u0435\u0440\u0432\u044b\u0439 \u0432\u0437\u0433\u043b\u044f\u0434, \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0432 Patroni \u0432 \u0442\u0435\u0441\u0442\u043e\u0432\u043e\u0439 \u043b\u0430\u0431\u0435, \u043c\u043e\u0436\u043d\u043e \u0443\u0432\u0438\u0434\u0435\u0442\u044c, \u043a\u0430\u043a\u043e\u0439 \u044d\u0442\u043e \u043f\u0440\u0435\u043a\u0440\u0430\u0441\u043d\u044b\u0439 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442 \u0438 \u043a\u0430\u043a \u043e\u043d \u043b\u0435\u0433\u043a\u043e \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043d\u0430\u0448\u0438 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0440\u0430\u0437\u0432\u0430\u043b\u0438\u0442\u044c \u043a\u043b\u0430\u0441\u0442\u0435\u0440. \u041e\u0434\u043d\u0430\u043a\u043e \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0432 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":90104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-90103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Patroni](\"\/wp-content\/uploads\/2020\/07\/6404cba13214f499d1f347cca0aacbe7.jpeg\")
<\/p>\n