Aruandes räägib Andrei Borodin, kuidas nad arvestasid PgBounceri skaleerimise kogemust ühenduste püüdja projekteerimisel. , kuidas seda tootmisse viidi. Samuti arutame, milliseid funktsioone püüdjas tahaksime näha uutestes versioonides: meile on oluline mitte ainult oma vajadusi rahuldada, vaid ka arendada kasutajate kogukonda. .
Video:
Tere kõigile! Minu nimi on Andrei.
Yandexis tegeleme open source andmebaaside arendamisega. Ja täna on meil teema ühenduste püüdja kohta.
Kui tead, kuidas nimetada ühenduste püüdjat eesti keeles, siis ütle mulle. Ma tõeliselt soovin leida head tehnilist mõistet, mis peaks tehnilises kirjanduses kehtima.
Teema on üsna keeruline, kuna paljudes andmebaasides on ühenduste püüdja sisseehitatud ja selle kohta pole isegi vaja teada. Muidugi on igal pool mõningaid seadeid, kuid Postgreses ei lähe see nii lihtsalt. Ja samal ajal (HighLoad++ 2019 korral) toimub Nikolai Samohvalovi ettekande ajal, kus räägitakse päringute seadistamisest Postgreses. Ja ma saan aru, et siia tulid inimesed, kes on juba päringud ideaalselt seadistanud, ning need on inimesed, kes seisavad silmitsi haruldaste süsteemsete probleemidega, mis on seotud võrguga, ressursside kasutusega. Mõnel juhul võis see olla üsna keeruline, kuna probleemid ei ole ilmsed.
Yandexis on Postgres. Yandexi pilves elavad paljud Yandexi teenused. Ja meil on mitu petabaiti andmeid, mis genereerivad Postgreses vähemalt miljon päringut sekundis.
Ja pakume piisavalt tüüpilist klastrit kõikidele teenustele - see on peamine pearühma nod, tavalised kaks koopiat (sünkroonne ja asünkroonne), varundamine, lugemise päringute skaleerimine koopias.
Iga klastrinode on Postgres, milles on lisaks Postgresile ja süsteemsete seiresüsteemide ühenduste püüdja. Ühenduste püüdjat kasutatakse fencinguks ja oma põhieesmärgi jaoks.
Mis on ühenduste püüdja põhieesmärk?
Postgreses on andmebaasi töötlemisel kasutusele võetud protsesside mudel. See tähendab, et iga ühendus on üks protsess, üks Postgresi taust. Ja selles taustas on erinevaid vahemälu variante, mille loomine erinevatele ühendustele on üsna kulukas.
Lisaks on Postgres'i koodis massiiv, mis nimetatakse procArray'iks. See sisaldab põhiandmeid võrguühenduste kohta. Peaaegu kõik procArray'i töötlemise algoritmid on liniarset keerukust, need läbivad kogu võrguühenduste massiivi. See on üsna kiire tsükkel, kuid suure arvu sissetulevate võrguühenduste korral muutub see veidi kallimaks. Ja kui kõik muutub veidi kallimaks, võite lõpuks maksta väga suure hinna suurte võrguühenduste eest.
On 3 võimalikku lähenemist:
- Rakenduse poolel.
- Andmebaasi poolel.
- Ja nende vahel, st kõikvõimalikud kombinatsioonid.
Kahjuks on sisseehitatud pooler praegu arendamisel. Sõbrad PostgreSQL Professional firmas tegelevad peamiselt sellega. Kui see ilmub, on raske ennustada. Tegelikult on arhitektivalikul meil kaks lahendust. See on rakendusepoolne pool ja proxy pool.
Rakendusepoolne pool on kõige lihtsam viis. Ja peaaegu kõik kliendijuhid pakuvad teile võimalust: miljoneid teie ühendusi koodis esitada mõne tosinana andmebaasi ühendusest.
Tekib probleem, et teatud hetkel soovite skaleerida tagapinda, soovite seda paigutada mitmesse virtuaalsesse masinasse.
Siis mõistate ka, et teil on veel mitu kättesaadavuse tsooni, mitu andmekeskust. Ja kliendipoolimise lähenemine toob kaasa suured numbrid. Suured on umbes 10 000 ühendust. See on piir, milles see võib normaalselt töötada.
Kui rääkida proxy pooler'itest, siis on kaks pooler'it, mis oskavad palju asju. Nad ei ole mitte ainult pooler'id. Need on pooler'id + veel suurepärane funktsionaalsus. Need on ja .
Aga kahjuks ei ole see lisafunktsionaalsus kõigile vajalik. Ja see toob kaasa selle, et pooler'id toetavad ainult sessioonide poolimist, st üks sissetulev klient, üks väljaminev klient andmebaasi.
Meie vajaduste jaoks see ei sobi eriti hästi, seetõttu kasutame PgBouncer'it, mis rakendab tehingute poolimist, st serveri ühendused vastanduvad kliendi ühendustele ainult tehingu ajaks.
Ja meie koormuse korral – see on tõsi. Aga paar probleemi on olemas..
Probleemid algavad siis, kui soovite diagnoosida seanssi, kuna kõik sissetulevad ühendused on kohalikud. Kõik tulid loopback'ilt ja seanssi jälgida muutub keeruliseks.
Muidugi saate kasutada application_name_add_host. See on viis, kuidas Bounceris IP-aadress lisada application_name'ile. Kuid application_name seotakse täiendava ühenduse kaudu.
Sellel graafikul, kus kollane joon tähistab reaalseid päringuid ja sinine joon päringuid, mis sisenevad andmebaasi. Ja see erinevus ongi application_name'i seadistus, mis on vajalik ainult jälgimiseks, kuid see pole absoluutselt tasuta.
Lisaks ei saa Bounceris ühtegi pooli piirata, st andmebaasiga kindla kasutaja jaoks ühenduste arvu.
Millele see viib? Teil on koormatud teenus, mis on kirjutatud C++-s ja kuskil läheduses väike teenus Node.js-is, mis ei tee andmebaasil midagi hullu, kuid tema draiver läheb hulluks. Ta avab 20 000 ühendust ja kõik muu peab ootama. Teie kood on isegi normaalne.
Me kirjutame kindlasti väikese plaastri Bouncerile, mis lisab selle seadistuse, st klientide piiramise poolile.
Seda oleks saanud teha Postgresis, st andmebaasi rollide piiramine ühenduste arvuga.
Aga siis kaotate võimaluse mõista, miks teil ei ole ühendusi serveriga. PgBouncer ei edasta ühenduse viga, ta tagastab alati sama teabe. Ja te ei saa aru: võib-olla on teie parool muutunud, võib-olla on andmebaas lihtsalt kukkunud, võib-olla on midagi valesti. Kuid diagnostika puudub. Kui seanssi ei saa luua, ei saa te teada, miks seda ei saa teha.
Ühel hetkel vaatate rakenduse graafikuid ja näete, et rakendus ei tööta.
Vaadake ülemist ja näete, et Bouncer on ühesuunaline. See on murranguline hetk teenuse elus. Te mõistate, et olete valmistunud andmebaasi skaleerimiseks aasta ja poole pärast, aga peate skaleerima poolerit.
Olemegi jõudnud järeldusele, et vajame rohkem PgBouncer'eid.
Paar korda plaastrit Bouncernile.
Ja tegime nii, et mitu Bouncerit saavad olla tõstetud TCP-porti taaskasutamisega. Ja operatsioonisüsteem suunab sissetulevaid TCP-ühendusi nende vahel automaatselt round-robin'iga.
See on klientidele läbipaistev, st kõik näib nagu teil oleks üks Bouncer, kuid teil on idle-ühenduste fragmentatsioon käivitatud Bouncerite vahel.
Ja teatud hetkel võite märgata, et need kolm Bouncera kasutavad oma protsessorituuma 100%. Teil on vaja palju Bouncereid. Miks?
Sest teil on TLS. Teil on krüpteeritud ühendus. Ja kui benchmarkite Postgresit TLS-i abil ja ilma, siis avastate, et loodud ühenduste arv väheneb peaaegu kahe järgu võrra krüpteerimise sisselülitamisega, kuna TLS-i käepigistus tarbib keskprotsessorist ressursse.
Ja tipptasemel võite näha üsna palju krüptograafilisi funktsioone, mis töötavad sissetulevate ühenduste laine ajal. Kuna meie põhiserver võib vahetuda kättesaadavuse tsoonide vahel, on sissetulevate ühenduste laine üsna tüüpiline olukord. See tähendab, et mingil põhjusel oli vana põhiserver kergesti kättesaamatuks, ja kogu koormus suunati teise andmekeskusesse. Kõik need tulevad korraga TLesse tervitama.
Ja suur hulk TLS-i käepigistusi ei pruugi enam Bounceriga tervitada, vaid pigem pigistab seda. Aegumise tõttu võib sissetulevate ühenduste laine muutuda järkjärguliseks. Kui teil on taaskatsetus andmebaasi ilma eksponentsiaalse tagasiastumiseta, siis need ei tule järjestikku tagasi, vaid pidevas laine.
Siin on näide 16 PgBouncerist, mis koormab 16 tuuma 100%.
Oleme jõudnud kaskaadse PgBounceri juurde. See on parim konfiguratsioon, mida saame saavutada meie koormuse ja Bounceriga. Välimised Bouncerid teenivad TCP käepigistuse jaoks ja sisemised Bouncerid teenivad tegeliku koondamise eesmärki, et mitte liiga palju lõhestada välimisi ühendusi.
Sellises konfiguratsioonis on sujuv taaskäivitamine võimalik. Saate kõik need 18 Bouncerit taaskäivitada ükshaaval. Kuid sellise konfiguratsiooni toetamine on üsna keeruline. Süsteemihaldurid, DevOps ja inimesed, kes tõeliselt vastutavad selle serveri eest, ei ole selle skeemiga väga rahul.
Tundub, et saame kõik meie täiustused edastada avatud lähtekoodiga, kuid Bouncer ei saa eriti head tuge. Näiteks võimalus käivitada mitu PgBouncerit ühel pordil pandi toime kuu aega tagasi. Aga pull-request selle funktsiooni kohta tehti mitu aastat tagasi.
Või veel üks näide. Postgresis saate jooksva päringu tühistada, saatdes salaja teise ühenduse kaudu ilma täiendava autentimiseta. Kuid mõned kliendid saadavad lihtsalt TCP-resetti, st lõhuvad võrguühenduse. Mida teeb sel juhul Bouncer? Ta ei tee midagi. Ta jätkab päringu täitmist. Kui teil on tulnud tohutult ühendusi, mis väikeste päringutega andmebaasi koormavad, siis on lihtsalt Bounceriga ühenduse katkestamine ebapiisav; tuleb lõpetada ka need päringud, mis andmebaasis töötavad.
See oli vigade parandatud ja see probleem pole veel upstream Bouncerisse lisatud.
Ja nii jõudsime järeldusele, et vajame oma ühenduse puhverserverit, mis arendaks, parandaks ja kus saaks probleeme kiiresti lahendada ning mis peab olema loomulikult mitme käideldav.
Mitmekäideldus seab meile peamise ülesande. Me peame hästi taluma sisenenud TLS-ühenduste laine.
Selle jaoks pidime välja töötama eraldi teegi, mida nimetatakse Machinarium, mis on mõeldud võrguühenduse masinadenööride kirjeldamiseks järjestikuse koodina. Kui vaatate libpq allika koodi, näete üsna keerulisi väljakutseid, mis võivad teile tagastada tulemuse ja öelda: "Kutsuge mind hiljem tagasi. Praegu on mul IO, kuid kui IO on möödas, on mul protsessori koormus". See on mitmeastmeline skeem. Võrgu interaktsioone kirjeldatakse tavaliselt olekutehnikaga. Palju reeglid, nagu "Kui olen varem saanud paketi päise suurusega N, siis ootan praegu N baiti", "Kui olen saatnud paketi SYNC, siis ootan praegu metainformeeriva paketi". Tulemuseks on üsna keeruline ja vastupidine kood, nagu oleks labürint muudetud ridade avamiseks. Me tegime nii, et arendaja kirjeldab selle asemel oleku masinat põhiühenduste teed tavapärase imperatiivse koodina. Lihtsalt peab selle imperatiivse koodi sisse panema kohad, kus läbiviimise järjestust tuleb katkestada andmete ootamise ajal võrgust, edastades täitmise konteksti teisele korutiinile (rohelisele threadile). See lähenemine on sarnane sellele, et me salvestame kõige oodatuma tee labürindis järjestikku ja seejärel lisame sellele harud.
Kokkuvõttes on meil üks voog, mis käivitab TCP vastuvõtu ja edastab ümmarguse rooberiga mitmele töötajale TPC-ühenduse.
Samuti töötab iga kliendiühendus alati ühel protsessoril. See muudab selle vahemälu sõbralikumaks.
Lisaks oleme natuke täiendanud väikeste pakettide kokku kogumist üheks suureks paketiks, et vähendada süsteemi TCP-staki koormust.
Oleme parandanud tehingute puhverdamist sel määral, et Odyssey, kui säte on rakendatud, saab saata CANCEL ja ROLLBACK juhul, kui võrguühendus katkevad, st kui pole ühtegi oodatavat päringut, ütleb Odyssey andmebaasile, et pole mõtet proovida töötada selle päringuga, mis võib kulutada väärtuslikke ressursse.
Võimalusel säilitame ühendused sama kliendiga. See väldib application_name_add_host uuesti seadistamist. Kui see on võimalik, siis ei pea me seadistama diagnostikaks vajalikke parameetreid uuesti.
Töötame Yandex.Cloudi huvides. Ja kui kasutate hallatud PostgreSQLi ja teil on seadistatud ühenduse puhver, saate luua loogilise replikatsiooni väljapoole, st saate meilt lahkuda loogilise replikatsiooni kaudu. Bouncer ei edasta väljapoole loogilise replikatsiooni voogu.
See on näide loogilise replikatsiooni seadistamisest.
Lisaks on meil füüsilise replikatsiooni tugi väljapoole. Pilves on see loomulikult võimatu, kuna see annaks teie klastrile liiga palju teavet enda kohta. Kuid teie installatsioonides, kui vajate füüsilist replikatsiooni ühenduse puhvri kaudu Odyssey's, on see võimalik.
Odyssey's on täielikult ühilduv jälgimine PgBounceriga. Meil on sama konsool, mis täidab peaaegu kõiki samu käske. Kui midagi puudu on, saatke pull-request või vähemalt probleem GitHubis, teeme vajalikud käsud valmis. Kuid PgBounceri põhifunktsionaalsus on meil juba olemas.
Ja loomulikult on meil viga edasi edastamine. Tagastame vea, mille andmebaas teatas. Saate teavet, miks te andmebaasi ei pääse, mitte lihtsalt mitte, et te ei pääse sinna.
Seda funktsiooni saab välja lülitada, kui vajate 100% ühilduvust PgBounceriga. Saame käituda nagu Bouncer, lihtsalt igaks juhuks.
Arendus
Mõned sõnad Odyssey lähtekoodi kohta.
Näiteks on olemas käsud „Pause / Resume“. Need on tavaliselt mõeldud andmebaasi värskendamiseks. Kui teil on vaja värskendada Postgres'i, saate selle connection pooler'is peatada, teha pg_upgrade ja seejärel jätkata. Klientide jaoks näeb see välja nagu andmebaas lihtsalt tarduks. Selle funktsionaalsuse tõid meile kogukonna liikmed. See pole veel kokku pandud, aga varsti kõik on. (Juba on kokku pandud)
— juba on kokku pandud
Lisaks on üks uutest funktsioonidest PgBounceris SCRAM Authentication'i tugi, mille tõi meile inimene, kes ei tööta Yandex.Cloud'is. Mõlemad – see on keeruline funktsionaalsus ja oluline.
Seega on soov rääkida, millest Odyssey koosneb, äkki soovite ka natuke koodi kirjutada.
Teil on Odyssey allikas, mis toetub kahele põhiteegile. Kiwi teek on Postgres'e sõnumite protokolli rakendus. See tähendab, et Postgres'e natiivne proto 3 on standardsed sõnumid, millega fronteerid ja tagaküljed saavad vahetada. Need on rakendatud Kiwi teegis.
Machinarium teek on voogude rakendus. Selle Machinarium'i väike fragment on kirjutatud assembleris. Kuid ärge muretsege, seal on vaid 15 rida.
Odyssey'i arhitektuur. On peamine masin, kus töötavad korutatsioonid. Selles masinas toimub sissetulevate TCP-ühenduste vastuvõtmine ja jagamine töötajate vahel.
Ühes töötajas võib töötada mitme kliendi töötleja. Samuti põhivoolus töötavad konsool ja crone-ülesannete töötlemine, et eemaldada ühendused, mis pole enam alas vajalikud.
Odyssey'i testimiseks kasutatakse Postgres'i standardset testide komplekti. Käivitame simply install-check'i Bouncer'i ja Odyssey'i kaudu, saame nulldivi. Seal on mitmeid teste, mis on seotud kuupäevade vormindamisega, mis ei läbi täpselt samamoodi Bouncer'is ja Odyssey'is.
Lisaks on olemas palju draivereid, mis omavad oma testimist. Ja nende teste kasutame Odyssey'i testimiseks.
Lisaks, meie kaskadikonfiguratsiooni tõttu peame testima erinevaid kombinatsioone: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, et olla kindlad, et kui Odyssey on mõnes kaskaadi osas, töötab see ikka nii, nagu me ootame.
Kühveldused
Kasutame Odyssey't tootmises. Ja oleks ebaaus, kui ma ütleksin, et kõik lihtsalt töötab. Ei, jah, aga mitte alati. Näiteks tootmises töötas kõik lihtsalt, siis tulid meie sõbrad PostgreSQL Professional'ist ja ütlesid, et meil on mälu leke. Nad olid tõeliselt õiged, me parandasime selle. Aga see oli lihtsalt.
Siis avastasime, et connection pooleris on sissetulevad TLS-ühendused ja väljaminevad TLS-ühendused. Ja ühendustes on vajalikud kliendi sertifikaadid ja serveri sertifikaadid.
Bouncer'i ja Odyssey serveri sertifikaadid loevad oma pcache'i, kuid kliendi sertifikaate ei pea pcache'ist uuesti lugema, kuna meie skaleeritav Odyssey puutub lõpuks kokku tõukesüsteemi sertifikaadi lugemise jõudlusega. See oli meie jaoks üllatus, kuna see probleem ei ilmnenud kohe. Alguses skaleerus see lineaarselt, aga pärast 20 000 sissetulevat samal ajal ühendust ilmus see probleem.
Pluggable Authentication Method on võimalus autentida end sisseehitatud Linuxi vahenditega. PgBouncer’is on see rakendatud nii, et on eraldi lõng, mis ootab vastust PAM-ilt, ja on peamine PgBouncer'i lõng, mis teenindab praegust ühendust ja võib paluda neid PAM-i lõngas oodata.
Me ei hakanud seda rakendama ühel lihtsal põhjusel. Meil on ju palju lõngu. Miks me seda vajame?
Lõppkokkuvõttes võivad see tekitada probleeme, kuna kui teil on PAM-i autentimine ja mitte PAM-i autentimine, siis suur PAM-i autentimise laine võib oluliselt viivitada mitte PAM-i autentimise. See on üks neist asjadest, mida me ei parandanud. Kuid kui soovite selle parandada, võite sellega tegeleda.
Teine takistus oli see, et meil on üks lõng, mis vastutab kõigi sissetulevate ühenduste aktsepteerimise eest. Ja seejärel edastab need töötajate basseinile, kus toimub TLS kätlemine.
Kui teil on koherentne laine 20 000 võrguühendust, siis need kõik aktsepteeritakse. Ja kliendi poolel hakkab libpq siis aegumise arvet pidama. Tundub, et vaikimisi on seal 3 sekundi tähtaeg.
Kui nad kõik ei saa samal ajal andmebaasi sisse, siis nad ei saa andmebaasi sisse, kuna seda ei saa katta mitteeksponentsiaalse proovimisega.
Oleme otsustanud, et kopeerime siia PgBouncer'i skeemi selle kohta, et meil on TCP-ühenduste arvu vähendamine, millele me aktsepteerime.
Kui me näeme, et aktsepteerime ühendusi, kuid nad ei saa viimaks kätšmani jõuda, paneme nad järjekorda, et nad ei raiskaks keskse protsessorite ressursse. See põhjustab seda, et samaaegne kätšman ei pruugi toimuda kõikide ühenduste jaoks, mis on saabunud. Aga vähemalt keegi pääseb andmebaasi, isegi kui koormus on piisavalt suur.
Teekond
Mida sooviksime tulevikus Odyssey's näha? Mida oleme valmis ise arendama ja mida ootame kogukonnalt?
August 2019. aasta seisuga.
Nii nägi Augustis välja Odyssey teekond:
- Soovisime SCRAM ja PAM autentimist.
- Soovisime edasi lugeda faile koopia serveris.
- Sooviksime online-restarti.
- Ja võimalust serveris paus võtta.
Pool sellest teekonnast on täidetud, ja seda mitte meie poolt. Ja see on hea. Seetõttu arutame seda, mis on jäänud, ja lisame veel.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
Postgres'is, alustades 10-st, on võimalik seansi atribuutide määramine ühenduse loomisel. Saate ühenduses loetleda kõik andmebaasi hostid ja öelda, miks te andmebaasi lähete: kirjutamiseks või ainult lugemiseks. Ja draiver valib ise loendi esimesena, mis talle rohkem meeldib, mis vastab seansi atribuutide nõudmistele.
Kuid selle lähenemise probleem on see, et see ei kontrolli replikatsiooni viivitust. Teil võib olla mõni replik, mis on ebaolulises ajavahemikus teie teenusele mahajäänud. Selleks, et lukustamisloetavates päringutes kõigis replikates korralikult töötada, vajame Odyssey'st võimalust mitte töötada, kui lugemine ei ole võimalik.
Odyssey peaks perioodiliselt andmebaasi minema ja küsima replikatsiooni kaugust primaarsest. Ja kui see saavutab piirväärtuse, ei tohi uusi päringuid andmebaasi lubada, vaid öelda kliendile, et tuleb ühendused uuesti algatada ja võib-olla valida teine host päringute täitmiseks. See võimaldab andmebaasil kiiremini taastada replikatsiooni viivituse ja naasta päringutele vastamiseks.
Rakendamise tähtaegu on raske nimetada, kuna see on avatud lähtekoodiga. Kuid loodan, et mitte 2,5 aastat nagu kolleegid PgBouncerist. Seda funktsiooni oleks soovinud Odyssey's näha.
Nüüd saate luua prepared statement'i kahte pidi. Esiteks võite täita SQL-käsku, nimelt „prepared”. Selle SQL-käsku mõistmiseks peame õppima mõistma SQL-i Bouncer'i poolel. See oleks üleliigne, kuna meil on vaja terviklikku parsijat. Me ei saa analüüsida iga SQL-käsku.
Kuid proto3-l on olemas prepared statement'i tugi sõnumite protokolli tasemel. Ja see on koht, kus teave vaikeprepared statement'i loomisest jõuab struktureeritud kujul. Ja me võiksime toetada arusaama, et mingisugusel serveri ühendusel palus klient luua prepared statements. Ja isegi kui tehing on suletud, peame ikkagi säilitama serveri ja kliendi seotuse.
Kuid siin tekib dialooge erinevus, sest keegi räägib sellest, et on oluline mõista, millised täpsed prepared statements klient on loonud ja jagada serveri ühendus kõikide klientide vahel, kes on loonud selle serveri ühenduse, st need, kes on loonud sellise prepared statement'i.
Andres Freund ütles, et kui klient on juba loonud teises serveri ühenduses sellise prepared statement'i, siis looge see tema eest. Kuid tundub, et klientide asemel andmebaasis päringute täitmine on pisut vale, kuid arendaja vaatevinklist, kes kirjutab andmebaasi suhtlemise protokolli, oleks mugav, kui talle antakse lihtsalt võrguühendus, kus on selline ettevalmistatud päring.
Ja veel üks funktsioon, mille peame ellu viima. Meil on praegu PgBouncer'iga ühilduv jälgimine. Saame tagasi keskmise päringu täitmise aja. Kuid keskmine aeg on nagu keskmine temperatuur haiglas: keegi on külm, keegi soe – keskmiselt on kõik terved. See on vale.
Peame rakendama toimetuse toetust, mis tähendaks, et on aeglased päringud, mis tarbivad ressursse, ja teevad jälgimise vastuvõetavamaks.
Kõige tähtsam on saada versioon 1.0 (versioon 1.1 on juba välja antud). Asi on selles, et Odyssey on hetkel versioonis 1.0rc, st release candidate. Ja kõik takistused, mida ma loetlesin, on lahendatud just sel versioonil, välja arvatud mälu leke.
Mida tähendaks meie jaoks versioon 1.0? Me toome Odyssey oma andmebaasidele. See töötab juba praegu meie andmebaasides, kuid kui see saavutab 1 000 000 päringut sekundis, siis saame öelda, et see on versioon, mida võib nimetada 1.0-st release'iks.
Kogukonnas on mitmed inimesed palunud, et versioonis 1.0 oleks ka paus ja SCRAM. Kuid see tähendaks, et peaksime juurutama järgmise versiooni, kuna SCRAM ja paus ei ole veel ühendatud. Kuid tõenäoliselt lahendame selle küsimuse piisavalt kiiresti.
Ootan teie pull request'e. Ja mul oleks tore kuulda, millised probleemid teil Bounceriga on. Räägime neist. Võib-olla suudame rakendada mingeid funktsioone, mis on teile vajalikud.
Sellekohane osa ongi mul läbi, tahaksin teid kuulata. Aitäh!
Küsimused
Kui ma seatan oma application_name, kas see edastatakse õigesti, sealhulgas transaction poolingus Odyssey's?
Odyssey's või Bouncer'is?
Odyssey's. Bouncer'is edastatakse.
Me teeme set'i.
Ja kui mu tegelik ühendus hopib teiste ühenduste vahel, kas see edastatakse?
Teeme set'i kõigi parameetritega, mis on loetletud nimekirjas. Ma ei saa öelda, kas sellel nimekirjal on application_name. Tundub, et olen seda seal näinud. Seame kõik samad parameetrid. Ühe päringuga teeb see set kõik, mis klient on seadistanud käivitamisel.
Aitäh, Andrei, et tegid ettekande! Hea ettekande! Rõõm on näha, et Odyssey areneb iga hetkaga üha kiiremini. Soovin, et jätkaksite samas vaimus. Oleme juba pöördunud teie poole palvega, et oleks olemas multi data-source ühendus, et Odyssey saaks samal ajal ühendada erinevate andmebaasidega, st master-slave, ja pärast automaatset failover'it ühendada uue meistriga.
Jah, ma tundub, et meenutan seda arutelu. Praegu on mitu salvestusruumi. Kuid vahetuste tegemine nende vahel puudub. Peame enda poolt küsima serverilt, et see on veel elus ja mõistma, et on toimunud failover, kes kutsub esile pg_recovery. Mul on olemas standardne viis mõista, et me ei ole meesterikkes. Ja me peame kuidagi aru saama vigadest või kuidas? T. e. idee on huvitav, seda arutatakse. Kirjutage rohkem kommentaare. Kui teil on töötavad käed, kes tunnevad C, siis on see tõeliselt suurepärane.
Meie jaoks on oluline küsimus replikatsioonide skaleerimise osas, sest soovime muuta replikatiivsete klastrite vastuvõtmise arendajatele võimalikult lihtsaks. Kuid siin tahaks rohkem kommentaare, st kuidas täpselt seda teha, kuidas hästi teha.
Küsimus on samuti replikate kohta. Selgub, et teil on master ja mitu replit. Ja on selge, et replitesse tehakse ühendusi harvemini kui masterisse, kuna neil võivad olla erinevused. Te ütlesite, et andmete erinevus võib olla selline, et see ei rahulda teie äri ja te ei külastaks neid, kuni need ei replikeerita. Samuti, kui te pikka aega ei külastanud, ja siis hakkate jälle külastama, siis need andmed, mis on vajalikud, ei ole kohe kergesti kättesaadavad. St kui me pidevalt käime masteris, siis seal on vahemälu soojendatud, aga replikas vahemälu veidi mahajäänud.
Jah, see on tõsi. Pcache'is ei ole andmepunkte, mida soovite, reaalses vahemälus ei ole teavet tabelite kohta, mida soovite, plaanides ei ole parsetud päringud, üldse mitte midagi.
Ja kui teil on mõni klaster ja lisate sinna uue repliika, siis kuni see käivitub, on seal kõik halvasti, st see soojendab oma vahemälu.
Sain idee aru. Õige lähenemine oleks käivitada alguses väike protsent päringutest repliikal, mis soojendaks vahemälu. Üksikasjalikult, meil on tingimus, et ei tohi jääda masterist kauemaks kui 10 sekundit. Ja seda tingimust rakendada mitte ühes voolus, vaid järk-järgult mõnedele klientidele.
Jah, suurendada kaalu.
See on hea idee. Aga kõigepealt tuleb see välja lülitada. Esiteks tuleb välja lülituda ja siis mõtleme, kuidas sisse lülitada. See on suurepärane funktsioon, et sujuvalt sisse lülituda.
Nginx'is on selline valik aeglaselt alustada serveri klastris. Ja see suurendab koormust järk-järgult.
Jah, hea idee, proovime, kui sinna jõuame.
Allikas: habr.com
