A sengem Gespréich wäert den Andrey Borodin Iech soen wéi se d'Erfahrung vu PgBouncer Skala berücksichtegt hunn beim Design vun engem Verbindungspooler , wéi se et an der Produktioun ausgerullt hunn. Zousätzlech wäerte mir diskutéieren wéi eng Funktiounen vum Pooler mir an neie Versioune wëllen gesinn: et ass wichteg fir eis net nëmmen eis Bedierfnesser ze decken, mee d'Benotzergemeinschaft z'entwéckelen .
Video:
Moien alleguer! Mäin Numm ass Andrew.
Bei Yandex entwéckelen ech Open Source Datenbanken. An haut hu mir en Thema iwwer Verbindung Pooler Verbindungen.
Wann Dir wësst wéi Verbindung Pooler op Russesch ze ruffen, sot mir. Ech wëll wierklech e gudden technesche Begrëff fannen, deen an der technescher Literatur etabléiert ass.
D'Thema ass zimlech komplizéiert, well a ville Datenbanken ass de Verbindungspooler agebaut an Dir musst net emol doriwwer wëssen. E puer Astellunge sinn natierlech iwwerall, awer am Postgres funktionnéiert dat net. A parallel (bei HighLoad++ 2019) gëtt et e Bericht vum Nikolai Samokhvalov iwwer d'Opstellung vun Ufroen am Postgres. An ech verstinn, datt Leit hei komm sinn, déi schonn Ufroe perfekt konfiguréiert hunn, an dës sinn Leit, déi mat rar System Problemer am Zesummenhang mat dem Reseau konfrontéiert sinn, Ressource Notzung. An op e puer Plazen kann et zimmlech schwéier sinn am Sënn datt d'Problemer net evident sinn.
Yandex huet Postgres. Vill Yandex Servicer liewen an Yandex.Cloud. A mir hunn e puer Petabytes vun Daten déi op d'mannst eng Millioun Ufroe pro Sekonn am Postgres generéieren.
A mir bidden e relativ typesche Stärekoup fir all Servicer - dëst ass den Haaptprimär Node vum Node, déi üblech zwee Repliken (synchron an asynchron), Backup, Skaléierung vu Liesufroen op der Replica.
All Cluster Node ass Postgres, op deem, nieft Postgres an Iwwerwaachungssystemer, och e Verbindungspooler installéiert ass. Connection Pooler gëtt fir Fechter benotzt a fir säin Haaptzweck.
Wat ass den Haaptziel vun engem Verbindungspooler?
Postgres adoptéiert e Prozessmodell fir mat enger Datebank ze schaffen. Dëst bedeit datt eng Verbindung ee Prozess ass, ee Postgres Backend. An et gi vill verschidde Cache an dësem Backend, déi zimlech deier si fir verschidde Verbindungen anescht ze maachen.
Och gëtt et eng Array am Postgres Code genannt procArray. Et enthält Basisdaten iwwer Netzwierkverbindungen. A bal all procArray Veraarbechtung Algorithmen hunn linear Komplexitéit, si lafen duerch déi ganz Palette vun Netzwierkverbindungen. Et ass e relativ séieren Zyklus, awer mat méi erakommen Netzwierkverbindunge ginn d'Saachen e bësse méi deier. A wann d'Saachen e bësse méi deier ginn, bezuelt Dir um Enn e ganz héije Präis fir eng grouss Zuel vu Netzwierkverbindungen.
Et ginn 3 méiglech Approche:
- Op der Applikatioun Säit.
- Op der Datebank Säit.
- An tëscht, dat ass, all méiglech Kombinatioune.
Leider ass den agebaute Pooler am Moment ënner Entwécklung. Frënn bei PostgreSQL Professional maachen dëst meeschtens. Wéini et erschéngt ass schwéier virauszesoen. An eigentlech hu mir zwou Léisunge fir de Choix vun engem Architekt. Dës sinn Applikatioun-Säit Pool a Proxy Pool.
Applikatioun-Säit Pool ass deen einfachste Wee. A bal all Client Treiber bidden Iech e Wee: Millioune vun Äre Verbindungen am Code als e puer Dosende vu Verbindunge mat der Datebank ze representéieren.
Et gëtt e Problem mat der Tatsaach datt op engem gewësse Punkt Dir de Backend wëllt skaléieren, Dir wëllt et op vill virtuell Maschinnen ofsetzen.
Da mierkt Dir nach ëmmer datt Dir e puer méi Disponibilitéitszonen hutt, e puer Datenzenteren. An de Client Säit Pooling Approche féiert zu groussen Zuelen. Grouss sinn ongeféier 10 Verbindungen. Dëst ass e Rand dee gutt ka funktionnéieren.
Wa mir iwwer Proxy Pooler schwätzen, da ginn et zwee Pooler déi vill Saache maache kënnen. Si sinn net nëmmen Pooler. Si sinn Pooler + méi cool Funktionalitéit. Dëst и .
Awer leider brauch net jiddereen dës zousätzlech Funktionalitéit. An et féiert zu der Tatsaach datt Pooler nëmmen Sessiounspooling ënnerstëtzen, dh een erakommen Client, een erausginn Client an d'Datebank.
Dëst ass net ganz gëeegent fir eis Aufgaben, also benotze mir PgBouncer, deen Transaktiounspooling implementéiert, dh Serververbindunge ginn nëmme fir d'Dauer vun der Transaktioun op Clientverbindunge mapéiert.
An op eis Laascht - et ass wouer. Mee et gi verschidde Problemer.
Probleemer fänken un wann Dir eng Sessioun diagnostizéiere wëllt, well all erakommen Verbindunge lokal sinn. Jiddereen ass mat Loopback komm an iergendwéi gëtt et schwéier d'Sessioun ze verfolgen.
Natierlech kënnt Dir application_name_add_host benotzen. Dëst ass de Bouncer Säit Wee fir eng IP Adress un den application_name ze addéieren. Awer application_name gëtt duerch eng zousätzlech Verbindung gesat.
Op dëser Grafik, wou déi giel Linn richteg Ufroen ass, a wou déi blo Linn Ufroen ass, déi an d'Datebank fléien. An dësen Ënnerscheed ass genau d'Astellung vum application_name, deen nëmme fir Tracing gebraucht gëtt, awer et ass guer net gratis.
Zousätzlech kann Bouncer net ee Pool limitéieren, dh d'Zuel vun den Datebankverbindunge pro Benotzer, pro Datebank.
Wat féiert dat zu? Dir hutt e geluedene Service geschriwwen an C ++ an iergendwou an der Géigend e klenge Service op engem Node, deen näischt falsch mat der Basis mécht, awer säi Chauffer geet verréckt. Et mécht 20 Verbindungen op an alles anescht wäert waarden. Och Äre Code ass richteg.
Natierlech hu mir e klenge Patch fir Bouncer geschriwwen, deen dës Astellung bäigefüügt huet, dh Clienten op de Pool limitéieren.
Et wier méiglech dat op der Postgres Säit ze maachen, also d'Rollen an der Datebank op d'Zuel vun de Verbindungen ze limitéieren.
Awer da verléiert Dir d'Fäegkeet ze verstoen firwat Dir keng Verbindunge mam Server hutt. PgBouncer werft kee Verbindungsfehler, et gëtt ëmmer déiselwecht Informatioun zréck. An Dir kënnt net verstoen: vläicht ass Äert Passwuert geännert, vläicht ass d'Datebank just erofgaang, vläicht ass eppes falsch. Awer et gëtt keng Diagnos. Wann d'Sessioun net etabléiert ka ginn, wësst Dir net firwat et net ka gemaach ginn.
Zu engem gewësse Punkt kuckt Dir d'Grafike vun der Applikatioun a kuckt datt d'Applikatioun net funktionnéiert.
Kuckt uewen a kuckt datt de Bouncer Single-threaded ass. Dëst ass e Wendepunkt am Liewen vum Service. Dir verstitt datt Dir Iech virbereet hutt d'Datebank an engem Joer an en halleft ze skaléieren, an Dir musst de Pooler skaléieren.
Mir sinn zur Conclusioun komm datt mir méi PgBouncers brauchen.
Bouncer ass liicht gefléckt.
A si hunn et sou gemaach datt verschidde Bouncers kënne mat der Wiederverwendung vum TCP Hafen opgehuewe ginn. A schonn iwwerdréit de Betribssystem automatesch Entréeën TCP Verbindungen tëscht hinnen duerch Ronn-robin'om.
Dëst ass transparent fir Clienten, dh et gesäit aus wéi wann Dir ee Bouncer hutt, awer Dir hutt Fragmentatioun vun Idle Verbindungen tëscht Lafen Bouncers.
An iergendwann kënnt Dir feststellen datt dës 3 Bouncer all hire Kär ëm 100% iessen. Dir braucht zimmlech e puer Bouncers. Firwat?
Well Dir hutt TLS. Dir hutt eng verschlësselte Verbindung. A wann Dir Postgres mat an ouni TLS benchmark, fannt Dir datt d'Zuel vun etabléierte Verbindungen ëm bal zwou Uerderen vun der Gréisst fällt mat Verschlësselung aktivéiert, well den TLS Handshake CPU Ressourcen verbraucht.
An uewen kënnt Dir zimmlech e puer kryptographesch Funktiounen gesinn, déi während enger Welle vun erakommen Verbindungen ausgefouert ginn. Well eis Primär tëscht Disponibilitéitszonen ka wiesselen, ass eng Welle vun erakommende Verbindungen eng zimlech typesch Situatioun. Dat ass, aus irgendege Grënn, war déi al Primärschoul net verfügbar, déi ganz Laascht gouf an en anert Rechenzentrum geschéckt. Si kommen all gläichzäiteg fir den TLS Hallo ze soen.
An eng grouss Unzuel vun TLS Handschlag kann de Bouncer net scho begréissen, awer den Hals drécken. Eng Welle vun erakommende Verbindunge kann ongedämpft ginn wéinst dem Timeout. Wann Dir e Versuch op d'Basis ouni exponentiell Réckzuch hutt, komme se net ëmmer erëm an enger kohärent Welle zréck.
Hei ass e Beispill vu 16 PgBouncers déi 16 Cores op 100% lueden.
Mir sinn op de kaskadende PgBouncer ukomm. Dëst ass déi bescht Konfiguratioun déi mir op eiser Bouncer Last erreechen kënnen. Eis extern Bouncers déngen fir TCP Handshake, an intern Bouncers déngen fir real Pooling, fir net extern Verbindungen staark ze fragmentéieren.
An dëser Konfiguratioun ass e mëllen Neistart méiglech. Dir kënnt all dës 18 Bouncers een nom aneren nei starten. Awer sou eng Konfiguratioun z'erhalen ass zimlech schwéier. Systemadministratoren, DevOps, an d'Leit, déi wierklech fir dëse Server verantwortlech sinn, wäerten net ganz zefridden mat dësem Schema sinn.
Et géif schéngen datt all eis Verbesserungen an Open Source gefördert kënne ginn, awer Bouncer ënnerstëtzt net ganz gutt. Zum Beispill, d'Fäegkeet fir verschidde PgBouncers um selwechten Hafen ze lafen ass virun engem Mount engagéiert. Eng Pull Ufro mat dëser Feature war virun e puer Joer.
Oder nach ee Beispill. An Postgres kënnt Dir eng lafend Ufro annuléieren andeems Dir de Geheimnis op eng aner Verbindung schéckt ouni déi extra Authentifikatioun. Awer e puer Clienten schécken einfach en TCP-Reset, dh se briechen d'Netzverbindung. Wat wäert de Bouncer mat dësem maachen? Hie wäert näischt maachen. Et wäert weiderhin d'Ufro ausféieren. Wann Dir eng riesech Unzuel u Verbindunge kritt hutt, déi d'Basis mat klengen Ufroe geluecht hunn, dann ass einfach d'Verbindung vum Bouncer ze trennen net genuch, Dir musst och déi Ufroen ausfëllen, déi an der Datebank lafen.
Dëst gouf gepatched an d'Thema ass nach ëmmer net an de Bouncer's Upstream fusionéiert.
An dofir si mir zur Conclusioun komm, datt mir eisen eegene Verbindungspooler brauchen, deen entwéckelt, gefléckt gëtt, an deem et méiglech ass séier Problemer ze fixéieren an deen natierlech multi-threaded muss sinn.
Mir setzen Multithreading als Haaptaufgab. Mir mussen fäeg sinn d'Welle vun erakommen TLS Verbindunge gutt ze handhaben.
Fir dëst ze maachen, hu mir eng separat Bibliothéik mam Numm Machinarium z'entwéckelen, déi entwéckelt ass fir d'Maschinnzoustand vun enger Netzwierkverbindung als Seriencode ze beschreiwen. Wann Dir de libpq Quellcode kuckt, gesitt Dir zimlech komplex Uriff déi Iech e Resultat zréckginn a soen: "Rufft mech e bësse méi spéit. De Moment hunn ech IO fir de Moment, awer wann den IO passéiert, hunn ech eng Laascht op de Prozessor. An dëst ass e Multi-Level Schema. Netzwierkinteraktioun gëtt normalerweis vun enger Staatsmaschinn beschriwwen. Vill Regele wéi "Wann ech virdru e Paket Header vun der Gréisst N krut, dann waarden ech elo op N Bytes", "Wann ech e SYNC Paket geschéckt hunn, dann waarden ech elo op e Paket mat Resultatmetadaten." Et stellt sech e zimlech schwieregen kontra-intuitive Code eraus, wéi wann de Labyrinth an e Linn Scan ëmgewandelt gouf. Mir hunn et sou gemaach datt amplaz vun enger Staatsmaschinn de Programméierer den Haaptinteraktiounswee a Form vun engem gewéinleche Imperativcode beschreift. Just an dësem Imperativcode musst Dir Plazen asetzen, wou d'Ausféierungssequenz muss ënnerbrach ginn andeems Dir op Daten aus dem Netz wart, den Ausféierungskontext an eng aner Coroutine (gréng Fuedem) weiderginn. Dës Approche ass ähnlech wéi d'Tatsaach, datt mir de meescht erwaarte Wee am Labyrinth an enger Zeil schreiwen, an dann Filialen derbäi addéieren.
Als Resultat hu mir ee Fuedem deen en TCP akzeptéiert a Round-Robin passéiert eng TPC Verbindung fir vill Aarbechter.
An dësem Fall leeft all Clientverbindung ëmmer op engem Prozessor. An dëst erlaabt Iech et Cache-frëndlech ze maachen.
An ausserdeem hu mir d'Sammlung vu klenge Päckchen an ee grousse Paket liicht verbessert fir de System TCP Stack ofzelueden.
Zousätzlech hu mir Transaktiounspooling verbessert am Sënn datt Odyssey, wann se konfiguréiert ass, CANCEL a ROLLBACK am Fall vun engem Netzverbindungsfehler schécken kann, dh wann keen op d'Ufro waart, Odyssey wäert der Datebank soen net ze probéieren ze erfëllen der Demande datt wäertvoll Ressourcen Offall kann.
A wa méiglech, behale mir Verbindunge mam selwechte Client. Dëst vermeit d'Applikatioun_name_add_host nei z'installéieren. Wa méiglech, hu mir keng zousätzlech Reset vun de Parameteren, déi fir Diagnostik gebraucht ginn.
Mir schaffen am Interesse vun Yandex.Cloud. A wann Dir verwaltete PostgreSQL benotzt an Dir hutt e Verbindungspooler installéiert, kënnt Dir logesch Replikatioun no baussen erstellen, dh eis verloossen wann Dir wëllt, mat logescher Replikatioun. Bouncer ausserhalb vum Flux vun der logescher Replikatioun wäert net ginn.
Dëst ass e Beispill fir eng logesch Replikatioun opzestellen.
Zousätzlech hu mir Ënnerstëtzung fir kierperlech Replikatioun no baussen. An der Cloud ass et natierlech onméiglech, well da gëtt de Cluster Iech ze vill Informatioun iwwer sech selwer. Awer an Ären Installatiounen, wann Dir kierperlech Replikatioun iwwer Verbindungspooler an Odyssey braucht, ass et méiglech.
Odyssey huet voll kompatibel Iwwerwaachung mat PgBouncer. Mir hunn déiselwecht Konsole déi bal all déiselwecht Kommandoen ausféiert. Wann eppes fehlt, schéckt eng Pull-Ufro oder op d'mannst e Problem op GitHub, mir wäerte déi néideg Kommandoen ausfëllen. Awer mir hu schonn d'Haaptfunktionalitéit vun der PgBouncer Konsole.
An natierlech hu mir Feeler Forwarding. Mir wäerten de Feeler vun der Basis gemellt zréck. Dir kritt Informatiounen firwat Dir net an der Basis sidd, net nëmmen datt Dir net dra sidd.
Dës Fonktioun ass ausgeschalt am Fall wou Dir 100% Kompatibilitéit mat PgBouncer braucht. Mir kënnen eis wéi Bouncer behuelen, just am Fall.
Entwécklung
E puer Wierder iwwer den Odyssee Quellcode.
Zum Beispill ginn et "Pause / Resume" Kommandoen. Si ginn normalerweis benotzt fir d'Datebank ze aktualiséieren. Wann Dir Postgres upgradéiere musst, kënnt Dir et am Verbindungspooler pausen, e pg_upgrade maachen, da weidergoen. A vun der Client Säit wäert et ausgesinn wéi wann d'Datebank just verlangsamt gouf. Dës Funktionalitéit gouf eis vu Leit aus der Gemeinschaft bruecht. Si ass nach net gestuerwen, awer geschwënn wäert alles sinn. (schon dout)
- schonn dout
Zousätzlech ass eng vun den neie Fonctiounen am PgBouncer SCRAM Authentifikatioun Ënnerstëtzung, déi och eis vun enger Persoun bruecht gouf, déi net an Yandex.Cloud schafft. Béid sinn komplex Funktionalitéit a wichteg.
Dofir wëll ech Iech soen, aus wat d'Odyssey besteet, am Fall wou Dir och elo e Code wëllt schreiwen.
Dir hutt d'Original Odyssey Basis, déi op zwou Haaptbibliothéiken hänkt. D'Kiwi Bibliothéik ass eng Implementatioun vum Postgres Message Protokoll. Dat ass, Postgres 'native Proto 3 ass Standard Messagen déi Frontends a Backends austausche kënnen. Si sinn an der Kiwi Bibliothéik ëmgesat.
D'Machinarium Bibliothéik ass eng thread Implementatiounsbibliothéik. E klengt Fragment vun dësem Machinarium ass am Assembler geschriwwen. Ma maach der keng Suergen, et gi just 15 Linnen.
Odyssee Architektur. Et gëtt eng Haaptmaschinn Lafen Coroutines. Dës Maschinn implementéiert Entréeën TCP Verbindungen akzeptéieren an ënner Aarbechter verdeelen.
Bannent engem Aarbechter kann en Handler fir verschidde Cliente schaffen. An och am Haaptfuedem dréint d'Konsole an d'Veraarbechtung vu Crone-Aufgaben fir Verbindungen ze läschen, déi net méi am Pool gebraucht ginn.
Odyssey gëtt mat der Standard Postgres Test Suite getest. Mir lafen just installéieren-Check duerch Bouncer an duerch Odyssee, mir kréien eng null div. Et gi verschidde Tester am Zesummenhang mat Datumformatéierung déi genau d'selwecht am Bouncer an Odyssey feelen.
Zousätzlech ginn et vill Chauffeuren déi hiren eegene Test hunn. A mir benotzen hir Tester fir Odyssee ze testen.
Och, wéinst eiser Kaskadkonfiguratioun, musse mir verschidde Bündel testen: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey fir sécher ze sinn datt wann Odyssey an engem vun den Deeler an der Kaskade ass, et och nach ëmmer funktionnéiert wéi erwaart .
Rake
Mir benotzen Odyssee an der Produktioun. An et wier net gerecht, wann ech soen, datt alles just funktionnéiert. Nee, d.h. jo, awer net ëmmer. Zum Beispill, an der Produktioun huet alles just geschafft, dunn sinn eis Frënn vum PostgreSQL Professional komm a soten datt mir e Memory Leak haten. Si ware wierklech, mir hunn se fixéiert. Mee et war einfach.
Duerno hu mir festgestallt datt de Verbindungspooler erakommende TLS Verbindungen an erausginn TLS Verbindungen huet. A Verbindunge brauchen Client Certificaten a Server Certificaten.
Bouncer an Odyssey Server Zertifikater ginn duerch PCache nei gelies, awer Client Zertifikater brauchen net vun PCache nei gelies ze ginn, well eis skalierbar Odyssey schlussendlech op d'Systemleistung vun dësem Zertifikat liesen. Dëst huet eis iwwerrascht, well hien net direkt ausgerout huet. Fir d'éischt huet et linear skaléiert, an no 20 erakommen simultan Verbindungen huet dëse Problem sech manifestéiert.
Pluggable Authentifikatiounsmethod ass d'Fäegkeet fir mat agebaute Lunux Tools ze authentifizéieren. Am PgBouncer gëtt et esou ëmgesat datt et e separate Fuedem op eng Äntwert vum PAM waart an et gëtt en Haapt PgBouncer thread deen déi aktuell Verbindung servéiert a kann se froen am PAM thread ze liewen.
Mir hunn dat net aus engem einfache Grond ëmgesat. Mir hu vill Baachen. Firwat brauche mir et?
Als Resultat kann dëst Probleemer kreéieren an datt wann Dir PAM Authentifikatioun an Net-PAM Authentifikatioun hutt, da kann eng grouss Welle vun der PAM Authentifikatioun wesentlech d'Net-PAM Authentifikatioun verspéiten. Et ass eng vun deene Saachen déi mir net fixéiert hunn. Awer wann Dir et wëllt fixéieren, kënnt Dir dëst maachen.
Eng aner Rake war mat der Tatsaach datt mir ee Fuedem hunn deen all erakommen Verbindungen akzeptéiert. An da gi se an den Aarbechterpool transferéiert, wou den TLS Handshake stattfënnt.
Als Resultat, wann Dir eng kohärent Welle vun 20 Netzwierkverbindungen hutt, ginn se all ugeholl. An op der Client Säit fänkt libpq Timeouts ze mellen. Par défaut ass et wéi 000 Sekonnen do.
Wa se net all gläichzäiteg an d'Basis kommen, da kënnen se net an d'Basis kommen, well dat alles kann duerch en net-exponentiellen Neiversuch ofgedeckt ginn.
Mir hunn endlech de PgBouncer Schema hei kopéiert, sou datt mir d'Zuel vun den TCP Verbindungen déi mir akzeptéieren, drosselen.
Wa mir gesinn datt mir Verbindungen akzeptéieren, awer se hunn keng Zäit fir um Enn ze handshaken, setzen mir se an eng Schlaang fir datt se net CPU Ressourcen verbrauchen. Dëst féiert zu der Tatsaach datt e gläichzäiteg Handschlag net fir all Verbindunge gemaach gëtt, déi ukomm sinn. Awer op d'mannst wäert een an d'Datebank kommen, och wann d'Laascht staark genuch ass.
Fahrplang
Wat wëllt Dir an Zukunft an der Odyssee gesinn? Wat si mir prett fir eis z'entwéckelen a wat erwaarden mir vun der Gemeinschaft?
Fir August 2019.
Dëst ass wéi d'Odyssey Fahrplang am August ausgesinn huet:
- Mir wollten SCRAM a PAM Authentifikatioun.
- Mir wollten d'Liesufroen op de Standby weiderginn.
- Ech wéilt online-Restart.
- An d'Fäegkeet fir um Server ze pausen.
D'Halschent vun dëser Fahrplang ass gemaach, an net vun eis. An dëst ass gutt. Also loosst eis diskutéieren wat iwwreg ass a méi derbäi.
? Mir hunn Repliken déi, ouni Ufroen ze erfëllen, einfach d'Loft erhëtzen. Mir brauchen se fir Failover a Switchover ze bidden. Am Fall vu Probleemer an engem vun den Datenzenteren, géif ech se gär mat nëtzlech Aarbecht besetzen. Well mir kënnen net déi selwecht zentrale Prozessor konfiguréieren, déi selwecht Erënnerung op eng aner Manéier, well Replikatioun wäert net anescht Aarbecht.
Am Prinzip, am Postgres, ab 10, ass et méiglech session_attrs ze spezifizéieren wann Dir konnektéiert. Dir kënnt all d'Datebankhost an der Verbindung oplëschten a soen firwat Dir an d'Datebank gitt: schreiwen oder nëmmen liesen. An de Chauffer selwer wäert den éischte Host op der Lëscht wielen, déi et am Beschten gefällt, deen d'Ufuerderunge vun session_attrs erfëllt.
Awer de Problem mat dëser Approche ass datt et d'Replikatiounslag net kontrolléiert. Dir hutt vläicht eng Zort Replika déi hannert enger inakzeptabel Zäit fir Äre Service ass. Fir eng vollstänneg Ausféierung vu Liesufroen op enger Replika ze maachen, musse mir an der Odyssey d'Fäegkeet ënnerstëtzen net ze schaffen wann et onméiglech ass ze liesen.
Odyssey muss vun Zäit zu Zäit an d'Datebank goen a froen no der Replikatiounsdistanz vum Primär. A wann et d'Limite erreecht huet, loosst net nei Ufroen an d'Datebank, sot de Client datt Dir d'Verbindungen nei initiéiert musst an eventuell en anere Host auswielen fir Ufroen auszeféieren. Dëst erlaabt d'Datebank séier d'Replikatiounslag ze restauréieren an erëm zréckzekommen fir mat enger Ufro ze reagéieren.
Et ass schwéier d'Ëmsetzungsdatum ze nennen, well et Open Source ass. Mee, hoffen ech, net 2,5 Joer wéi Kollege vu PgBouncer. Dëst ass d'Feature, déi ech an der Odyssey gesinn.
. Elo kënnt Dir eng preparéiert Ausso op zwou Weeër erstellen. Als éischt kënnt Dir e SQL Kommando ausféieren, nämlech "preparéiert". Fir dëst SQL Kommando ze verstoen, musse mir léieren wéi SQL op der Bouncer Säit versteet. Dëst wier iwwerkill well et iwwerkill ass well mir de ganze Parser brauchen. Mir kënnen net all SQL Kommando parséieren.
Awer et gëtt eng preparéiert Ausso um Message Protokoll Niveau op Proto3. An dëst ass d'Plaz wou d'Informatioun, déi d'preparéiert Ausso erstallt gëtt, an enger strukturéierter Form kënnt. A mir kéinten d'Versteesdemech ënnerstëtzen datt op e puer Serververbindung de Client gefrot huet virbereet Aussoen ze kreéieren. An och wann d'Transaktioun zougemaach ass, musse mir nach ëmmer de Server an de Client verbonne halen.
Awer hei gëtt et eng Diskrepanz am Dialog, well iergendeen seet datt Dir musst verstoen wéi eng preparéiert Aussoen de Client erstallt huet an d'Serververbindung tëscht all de Clienten deelen déi dës Serververbindung erstallt hunn, dat heescht, wien esou eng preparéiert Ausso erstallt huet.
Den Andres Freund sot, datt wann e Client bei Iech komm ass, deen esou eng preparéiert Ausso schonn an enger anerer Serververbindung erstallt huet, dann erstellt et fir hien. Awer et schéngt e bësse falsch ze sinn fir Ufroen an der Datebank auszeféieren amplaz vum Client, awer aus der Siicht vum Entwéckler deen de Protokoll fir d'Interaktioun mat der Datebank schreift, wier et bequem wann hien einfach eng Netzwierkverbindung kritt. dat huet esou eng bereet Demande.
An nach eng Feature déi mir musse implementéieren. Mir hunn elo Iwwerwaachung kompatibel mat PgBouncer. Mir kënnen déi duerchschnëttlech Ufro Ausféierungszäit zréckginn. Awer déi duerchschnëttlech Zäit ass déi duerchschnëttlech Temperatur am Spidol: een ass kal, een ass waarm - am Duerchschnëtt ass jiddereen gesond. Et ass net wouer.
Mir mussen Ënnerstëtzung fir percentiles ëmsetzen, wat géif weisen datt et lues Ufroe ginn, déi Ressourcen verbrauchen an d'Iwwerwaachung méi akzeptabel maachen.
Déi wichtegst Saach ass datt ech Versioun 1.0 wëll (Versioun 1.1 ass scho verëffentlecht ginn). De Fakt ass datt elo Odyssey an der Versioun 1.0rc ass, dh Verëffentlechungskandidat. An all d'Rake, déi ech opgezielt hunn, gouf genee mat der selwechter Versioun fixéiert, ausser fir d'Erënnerungsleck.
Wat bedeit d'Versioun 1.0 fir eis? Mir rullen d'Odyssee op eis Basen aus. Et leeft schonn op eise Datenbanken, awer wann et de Punkt vun 1 Ufroen pro Sekonn erreecht, da kënne mir soen datt dëst eng Verëffentlechungsversioun ass an dëst eng Versioun ass déi 000 genannt ka ginn.
Verschidde Leit an der Gemeinschaft hu gefrot fir méi Paus a SCRAM an der Versioun 1.0. Awer dëst wäert heeschen datt mir déi nächst Versioun op d'Produktioun musse rullen, well weder SCRAM nach d'Paus ass nach fusionéiert ginn. Awer, wahrscheinlech, wäert dëst Thema zimlech séier geléist ginn.
Ech waarden op Är Pull Ufro. An ech géif och gären héieren wéi eng Problemer Dir mam Bouncer hutt. Loosst eis se diskutéieren. Vläicht kënne mir e puer Funktiounen ëmsetzen déi Dir braucht.
Dëst schléisst mäin Deel of, ech géif gär vun Iech héieren. Merci!
Är Froen
Wann ech meng eegen application_name setzen, gëtt et richteg geworf, och am Transaktiounspooling an Odyssey?
Odyssee oder Bouncer?
An der Odyssee. De Bouncer gëtt geheit.
Mir maachen e Set.
A wann meng richteg Verbindung iwwer aner Verbindungen hopsen, gëtt se iwwerdroen?
Mir maachen e Set vun all de Parameteren déi opgezielt sinn. Ech kann net soen ob application_name an dëser Lëscht ass. Et schéngt, datt hien hien do gesinn huet. Mir setzen all déiselwecht Parameteren. Mat enger Ufro wäert de Set alles maachen wat vum Client während dem Startup installéiert gouf.
Merci Andrey fir de Bericht! Gudde Bericht! Ech si frou datt Odyssey all Minutt méi séier a méi séier entwéckelt. Ech géif gären déi selwecht weider. Mir hunn Iech scho gefrot fir eng Multi-Datenquellverbindung ze hunn, sou datt Odyssey gläichzäiteg mat verschiddenen Datenbanken konnektéiere kann, dh de Sklave Master, an dann automatesch mam neie Master verbannen no engem Failover.
Jo, ech erënnere mech un déi Diskussioun. Elo ginn et e puer Stockage. Awer et gëtt kee Wiessel tëscht hinnen. Op eiser Säit musse mir de Server froen datt et nach ëmmer lieweg ass a verstoen datt e Failover geschitt ass, deen pg_recovery nennt. Ech hunn e Standard Wee fir ze verstoen datt mir net bei de Meeschter komm sinn. A mir mussen iergendwéi aus de Feeler verstoen oder wéi? Dat heescht, d'Iddi ass interessant, et gëtt diskutéiert. Schreift méi Kommentaren. Wann Dir schaffen Hänn hutt, déi C kennen, dann ass dëst allgemeng wonnerbar.
D'Thema vun der Skaléierung iwwer Repliken ass och fir eis interessant, well mir wëllen d'Adoptioun vu replizéierte Cluster sou einfach wéi méiglech fir Applikatiounsentwéckler maachen. Mee hei hätt ech gär méi Kommentaren, dat ass, wéi et ze maachen, wéi et gutt ze maachen.
D'Fro ass och iwwer Repliken. Et stellt sech eraus datt Dir e Meeschter an e puer Repliken hutt. An et ass kloer datt se manner dacks op d'Replique goen wéi de Master fir Verbindungen, well se en Ënnerscheed hunn. Dir sot datt den Ënnerscheed an den Donnéeën esou ka sinn datt Äert Geschäft net zefridden wäert an Dir wäert net dohinner goen bis et replizéiert gëtt. Zur selwechter Zäit, wann Dir net laang dohinner gaang sidd, an dann ugefaang ze goen, da sinn d'Donnéeën déi Dir braucht net direkt verfügbar. Dat ass, wa mir stänneg op de Meeschter goen, da gëtt de Cache do opgewiermt, an de Cache ass e bëssen hannendrun an der Replica.
Jo et stëmmt. Et gi keng Datenblocken am pcache déi Dir wëllt, am richtege Cache gëtt et keng Informatioun iwwer Dëscher déi Dir wëllt, et gëtt keng parséiert Ufroen an de Pläng, guer näischt.
A wann Dir eng Zort Cluster hutt, an Dir eng nei Replica do bäidréit, da wärend et ufänkt, ass alles schlecht dran, dh et wiisst säi Cache.
Ech hunn d'Iddi. Déi richteg Approche wier fir e klenge Prozentsaz vun Ufroen op der Replica als éischt ze lafen, wat de Cache géif opwiermen. Grof geschwat, mir hunn eng Konditioun datt mir net méi wéi 10 Sekonnen hannert dem Meeschter sinn. An dës Conditioun soll net an enger Welle abegraff ginn, awer glat fir e puer Clienten.
Jo, Gewiicht erhéijen.
Dëst ass eng gutt Iddi. Awer als éischt musst Dir dëse Shutdown ëmsetzen. Als éischt musse mir ausschalten, an da wäerte mir iwwerdenken wéi et ausschalten. Dëst ass eng super Feature fir glat opzemaachen.
nginx huet dës Optioun slowly start am Cluster fir de Server. An hie baut d'Laascht no an no op.
Jo, super Iddi, mir probéieren et wann mir dohinner kommen.
Source: will.com