Aastatel räägib Andrei Borodin, kuidas nad arvestasid PgBounceri skaleerimise kogemust ühenduste puhvertelligeerimise kavandamisel. , kuidas nad seda tootmisse tõid. Lisaks arutame, milliseid funktsioone puhvertelligeerimisel sooviksime näha uutes versioonides: meile on oluline mitte ainult katta oma vajadusi, vaid ka arendada kasutajate kogukonda. .
Video:
Tere kõigile! Minu nimi on Andrei.
Yandexis töötan avatud lähtekoodiga andmebaaside arendamisega. Ja täna on meil teema ühenduste puhvertelligeerimise kohta.
Kui teate, kuidas nimetada ühenduste puhvertelligeerijat eesti keeles, palun öelge mulle. Ma tahaksin väga leida head tehnilist terminit, mis peaks saama püsivaks tehnilises kirjanduses.
Teema on üsna keeruline, sest paljuski on andmebaasides ühendus-ettevõtja sisseehitatud ja sellest ei pea isegi teadma. Muidugi on igas kohas teatud seadeid, kuid Postgreses see nii ei toimi. Ja samal ajal (HighLoad++ 2019) toimub Nikolai Samokhvalovi ettekande esitamine Postgresse päringute seadistamisest. Ja ma saan aru, et siia tulid inimesed, kes on juba päringud ideaalselt seadistanud, ja need on inimesed, kes seisavad silmitsi haruldasemate süsteemsete probleemidega, mis on seotud võrguga, ressursside kasutamisega. Ja kohati võis see olla üsna keeruline, kuna probleemid ei olnud ilmne.
Yandexis on Postgres. Yandexi pilves asuvad paljude Yandexi teenused. Ja meil on mitu petabaiti andmeid, mis genereerivad Postgreses mitte vähem kui miljon päringut sekundis.
Ja me pakume kõigile teenustele piisavalt tavalist klastrit – see on peamine primaarne sõlme, tavalised kaks koopiat (sünkroonne ja asünkroonne), varundamine, lugemispäringute skaleerimine koopial.
Iga klastrisõlm on Postgres, millel on lisaks Postgresale ja süsteemimonitorimisele veel ühendus-ettevõtja. Ühendus-ettevõtjat kasutatakse fence'imiseks ja oma põhiotstarbel.
Mis on connection pooleri põhifunktsioon?
Postgresis kasutatakse andmebaasi tööks protsessimudelit. See tähendab, et iga ühendus on üks protsess, üks Postgresi tagumine pool. Sellest tagumisest poolest on väga palju erinevaid vahemälusid, mille loomine erinevatele ühendustele on suhteliselt kulukas.
Lisaks on Postgresi koodis massiiv, mida nimetatakse procArray. See sisaldab olulisi andmeid võrguühenduste kohta. Peaaegu kõik procArray töötlemise algoritmid on lineaarsed, nad skaneerivad kogu võrguühenduste massiivi. See on üsna kiire tsükkel, kuid suure arvu sissetulevate võrguühenduste korral muutub see natuke kallimaks. Ja kui kõik muutub pisut kallimaks, võib lõpuks väga paljude võrguühenduste tõttu hind olla äärmiselt kõrge.
Eksisteerib 3 võimalikku lähenemisviisi:
- Rakenduse küljelt.
- Andmebaasi küljelt.
- Ja nende vahel, st igasuguste kombinatsioonide näol.
Kahjuks on sisseehitatud pooler praegu arenduses. Meie sõbrad PostgreSQL Professional firmas tegelevad selle peamiselt. Kuidas ja millal see valmis saab, on raske ennustada. Tegelikult on arhitektil kaks valikut: see on rakenduse pooler ja proxy pooler.
Rakenduse pooler on kõige lihtsam lahendus. Peaaegu kõik kliendijuhid pakuvad teile võimalust: tuhanded teie ühendused koodis esitada mõne kümne ühendusena andmebaasi.
Küsimus on selles, et mingil hetkel soovite oma tagapinda skaala, soovite selle käivitada paljude virtuaalmasinate peal.
Siis saate aru, et teil on mitmeid saadavusalasid, mitu andmekeskust. Klientide poolel juhtimine toob kaasa suuri numbreid. Suured – need on umbes 10 000 ühendust. See on piir, kus see võib normaalselt töötada.
Kui räägime proxy pooleritest, siis on kaks poolerit, mis oskavad palju asju. Nad ei ole ainult poolerid. Nad on poolerid + veel suurepärane funktsionaalsus. See on ja .
Kahjuks ei ole see lisafunktsionaalsus kõigile vajalik. See viib selleni, et poolerid toetavad ainult seansi kogumist, st ühe sisenemise klient, üks väljumise klient andmebaasi.
Meie vajaduste jaoks sobib see aga halvasti, seega kasutame PgBouncerit, mis rakendab tehingute kogumist, st serveri ühendused vastavad kliendi ühendustele ainult tehingu ajaks.
Ja meie koormuse puhul - see on tõsi. Kuid on mitmeid probleeme.
Probleemid algavad, kui soovite seanssi tõrkeotsinguks, kuna kõik sisenemised on kohalikud. Kõik tulid loopback'ilt ja seansi jälgimine muutub keeruliseks.
Loomulikult saate kasutada application_name_add_host. See on Bounceri külgpoolsest viisist, kuidas lisada IP-aadress application_name'i. Kuid application_name'i seadmine nõuab lisahüüd.
Sellel graafikul, kus kollane joon näitab tegelikke päringuid ja sinine näitab päringuid, mis andmebaasi sisenevad. See erinevus ongi application_name'i seadmine, mis on vajalik ainult jälgimiseks, kuid see ei ole tasuta.
Lisaks ei saa Bounceris ühtegi basseinilimiiti seada, st ühenduste arvu andmebaasiga teatud kasutaja, teatud andmebaasi jaoks.
Millele see viib? Teie käes on koormatud teenus, mis on kirjutatud C++-s ja kusagil läheduses väike teenus Node'is, mis ei tee andmebaasi osas midagi hullu, kuid selle draiver läheb hulluks. Ta avab 20 000 ühendust ja kõik muu ootab. Teie kood on isegi normaalne.
Muidugi, me kirjutasime väikese plaastri Bouncerile, mis lisas selle seadistuse, st piirduse klientide jaoks basseinis.
Seda oleks saanud teha ka Postgresi poolel, st piirata andmebaasi rollide ühenduste arvu.
Aga siis kaotate võimaluse aru saada, miks teil pole serveriga ühendusi. PgBouncer ei edasta ühenduse viga, ta tagastab alati sama teabe. Ja te ei saa aru: äkki on teie parool muutunud, äkki lihtsalt andmebaas on maas, ehk on midagi valesti. Kuid diagnostika puudub. Kui seanssi ei saa luua, ei saa te teada, miks see ei õnnestu.
Teatud hetkel vaatate rakenduse graafikuid ja näete, et rakendus ei tööta.
Vaadake tippu ja näete, et Bouncer on ühesuunaline. See on pöördepunkt teenuse elus. Te mõistate, et olete valmistunud andmebaasi skaleerimiseks poolteise aasta pärast, kuid nüüd peate skaleerima poolerit.
Oleme jõudnud järeldusele, et meil on vaja rohkem PgBouncer'eid.
Veidi parandasime Bouncerit.
Ja tegime nii, et mitu Bouncerit saavad tõusta, kasutades TCP-porti taaskasutamist. Ja operatsioonisüsteem suunab sisenevad TCP-ühendused nende vahel automaatselt round-robin meetodil.
See on klientidele läbipainev, st kõik näeb välja nagu teil oleks üks Bouncer, kuid teil on idle-ühenduste fragmenteerimine nende käitatavate Bouncerite vahel.
Ja mingil hetkel võite märgata, et need 3 Bouncerit kasutavad igaüks oma protsessorituuma 100% ulatuses. Teil on vaja üsna palju Bouncerite. Miks?
Sest teil on TLS. Teil on krüpteeritud ühendus. Ja kui proovida Postgres'i TLS-i ja TLSita, leiate, et loodud ühenduste arv langeb peaaegu kahe järjestusega kui krüpteering on sisse lülitatud, sest TLS handshake tarbib protsessori ressursse.
Ja võite tipust näha üsna palju krüptograafilisi funktsioone, mis toimivad sissetulevate ühenduste laine ajal. Kuna meie primaarne server võib vahetuda kättesaadavuse tsoonide vahel, siis sissetulevate ühenduste laine on üsna tavaline olukord. See tähendab, et mingil põhjusel oli vana primaarne server kätte saamatu ja kogu koormus saadeti teise andmekeskusesse. Kõik nad tulevad üheaegselt TSL-iga tervitama.
Ja suur hulk TLS käepigistust võib mitte enam Bounceriga tervitada, vaid pigem selle kaudu takistada. Ajaülekatkestuse tõttu võib sissetulevate ühenduste laine muutuda katkematuks. Kui teil on andmebaasi uuendamine ilma eksponentsiaalse tagasilanguseta, siis nad ei tule järjestikku ühte ja sama koormaga.
Siin on näide 16 PgBouncerist, mis koormavad 16 tuuma 100% ulatuses.
Me oleme jõudnud kaskaadi PgBouncerisse. See on parim konfiguratsioon, mille me saame saavutada meie koormuse puhul Bounceriga. Välimised Bouncerid teenivad TCP käsitlemiseks, samas kui sisemised Bouncerid teenivad tegeliku ühenduse haldamiseks, et mitte liiga palju fragmenteerida välimisi ühendusi.
Sellise konfiguratsiooniga on võimalik sujuv restart. Saate restardida kõik need 18 Bouncerit ükshaaval. Kuid sellise konfiguratsiooni säilitamine on üsna keeruline. Süsteemiadministraatorid, DevOps ja inimesed, kes vastutavad selle serveri eest, ei ole sellise skeemi üle väga rõõmsad.
Tundub, et võiksime kõik meie täiustused edastada avatud allikatesse, kuid Bouncer ei saa kuigi head tuge. Näiteks võimalus käivitada mitu PgBouncerit ühel pordil commititi kuu aega tagasi. Ja pull request selle funktsiooni osas oli tehtud juba mitu aastat tagasi.
Või veel üks näide. Postgreses saate tühistada käimasoleva päringu, saates salaja teise ühenduse kaudu ilma täiendava autentimiseta. Kuid mõned kliendid saadavad lihtsalt TCP-reset, st katkestavad võrguühenduse. Mida siis Bouncer teeb? Ta ei tee midagi. Ta jätkab päringu täitmist. Kui teil on tulnud tohutul hulgal ühendusi, mis väikeste päringutega andmebaasi üle koormavad, siis lihtsalt ühenduse katkestamine Bounceriga ei piisa, on vaja lõpetada ka need päringud, mis andmebaasis töötavad.
See probleem on parandatud, kuid seda ei ole endiselt upstream Bouncerisse mergeeritud.
Nii oleme jõudnud selle järelduseni, et meil on vaja oma connection poolerit, mis arendab, patch‘ib ja mille kaudu saame kiiresti probleeme lahendada ning mis peab olema loomulikult ka mitme lõimega.
Mitme lõimega töö on meie peamine ülesanne. Peame hästi toime tulema suurte sissetulevate TLS-ühenduste vooluga.
Selleks pidime me välja töötama eraldi raamatukogu, mille nimi on Machinarium. See on mõeldud masinaseisundite kirjeldamiseks võrguühenduse seeria koodina. Kui vaatate libpq lähtekoodi, näete üsna keerulisi kõnesid, mis võivad teile tagastada tulemuse ja öelda: "Kutsu mind hiljem tagasi. Praegu on mul IO, kuid kui IO on möödas, ootab mind protsessori koormus." Ja see on mitme tasandi skeem. Võrguinteraktsiooni kirjeldatakse tavaliselt seisundimasinana. Paljusid reegleid, nagu "Kui olen varem saanud N suurusega paketi päise, siis nüüd ootan N baiti" või "Kui saatsin SYNC paketi, siis nüüd ootan tulemuse metainfot paketti". Saame üsna keerulise, vastupidi intuitiivse koodi, nagu oleks labürint muudetud sirgeks maapinnaks. Me tegime nii, et seab mitte masinaseisund, vaid programmeerija kirjeldab põhiühendusteed ülesandena tavalise imperatiivse koodina. Lihtsalt peab selle imperatiivse koodi sisse lisama kohti, kus täitmise järjekord tuleks katkestada ning oodata andmeid võrgust, andes täitmise konteksti teisele korutatiivse (roheline niit) protsessile. See lähenemine sarnaneb sellele, et me kirjutame kõige oodatud tee labürindis järjestikku üles ja seejärel lisame sellele harud.
Lõpuks on meil üks voog, mis teostab TCP accept’i ja ringhargneb mitme töötlusprotsessi vahel TPC-ühenduse.
Samuti töötab iga kliendi ühendus alati ühel protsessoril. See muudab selle cache-friendly.
Lisaks oleme natuke täiendanud väikeste pakettide kogumist suureks paketiks, et leevendada süsteemi TCP-stack’i koormust.
Oleme ka parandanud tehingute puulimist, nii et Odyssey, kui seade on aktiveeritud, võib saata CANCEL ja ROLLBACK, kui võrguühendus katkeb, st kui keegi ei oota päringut, ütleb Odyssey andmebaasile, et see ei pingutaks selle päringu täitmisega, mis võib kasutada väärtuslikke ressursse.
Ja võimalusel säilitame ühendused sama kliendiga. See võimaldab mitte uuesti seadistada application_name_add_host'i. Kui see on võimalik, siis ei ole meil lisaseadistuste vajadust, mis on vajalikud diagnostikaks.
Me töötame Yandex.Cloudi huvides. Kui te kasutate managed PostgreSQL ja teil on seadistatud connection pooler, saate luua loogilise replikatsiooni väljapoole, ehk siis lahkuda meist, kui soovite, loogilise replikatsiooni abil. Bouncer ei väljastada loogilise replikatsiooni voogu väljapoole.
See on näide loogilise replikatsiooni seadistamisest.
Lisaks on meil füüsilise replikatsiooni tugi väljapoole. Pilves on see loomulikult võimatu, kuna see tähendaks, et teie klaster annaks endast liiga palju teavet. Kuid teie installatsioonides, kui vajate füüsilist replikatsiooni läbi connection pooleri 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 jääb puudu, saatke pull request või vähemalt issue GitHubis, et saaksime vajalikke käske täiendada. Kuid PgBounceri konsooli põhifunktsioonid on meil juba olemas.
Ja muidugi on meil ka vigade edastamine. Tagastame selle vea, mille andis andmebaas. Saate teavet, miks te ei pääse andmebaasi, mitte lihtsalt, et te sinna ei pääse.
See võimalus lülitatakse välja, kui teil on vaja 100%-list ühilduvust PgBounceriga. Me saame käituda nagu Bouncer, lihtsalt ettevaatusabinõuks.
Arendus
Mõned sõnad Odyssey allika kohta.
Näiteks on olemas käsud „Pause / Resume“. Neid kasutatakse tavaliselt andmebaasi värskendamiseks. Kui soovite Postgresit uuendada, saate selle connection pooleris pausile panna, teostada pg_upgrade, seejärel jätkata. Klientide poolelt näeb see välja nagu andmebaas lihtsalt peatuks. Selle funktsionaalsuse tõid meieni kogukonna liikmed. See ei ole veel liidetud, kuid varsti on kõik korras. (Juba on liidetud)
— juba on liidetud
Lisaks, üks uus funktsioon PgBounceris on SCRAM autentimise tugi, mille tõi meieni inimene, kes ei tööta Yandex.Cloudis. Mõlemad on keerulised funktsionaalsused ja olulised.
Seetõttu tahan rääkida, millest Odyssey koosneb, äkki soovite ka natuke koodi kirjutada.
Teie käsutuses on algne Odyssey baaskood, mis toetub kahe põhiraamatukogu. Kiwi raamatukogu on Postgresi sõnumiprotokolli rakendus. See tähendab, et Postgresi natiivne proto 3 on standardsed sõnumid, millega front-end ja back-end saavad vahetada. Need on rakendatud Kiwi raamatukogus.
Machinarium raamatukogu on voogude rakendamise raamatukogu. Väike fragment sellest Machinariumist on kirjutatud assembleris. Kuid ärge kartke, seal on vaid 15 rida.
Odyssey arhitektuur. On olemas peamine masin, kus töötavad coroutines. Selles masinas teostatakse sissetulevate TCP-ühenduste vastuvõtmine ja jaotamine töötajatele.
Ühes töötajas võib töötada mitme kliendi töötlija. Samuti peamisest lõngast töötavad konsool ja crone-ülesannete täitmine, mis eemaldavad ühendused, mida enam ei vajata poolis.
Odyssey testimiseks kasutatakse Postgresi standardset testikomplekti. Lihtsalt käivitame install-check'i Bounceri ja Odyssey kaudu, saame nulldiv'i. Seal on mõned testid, mis on seotud kuupäevade vormindamisega, ei arvestata absoluutselt samamoodi Bounceris ja Odyssey's.
Lisaks on palju draivereid, millel on oma testimine. Kasutame nende teste Odyssey testimiseks.
Samuti peame meie kaskaadsete konfiguratsioonide tõttu katsetama erinevaid kombinatsioone: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, et olla kindel, et kui Odyssey on mõnes kaskaadi osas, töötab see endiselt nagu me ootame.
Raud
Kasutame Odyssey't tootmises. Ei oleks õiglane öelda, et kõik lihtsalt töötab. Jah, kuid mitte alati. Näiteks tootmises töötas kõik lihtsalt, kuni meie sõbrad PostgreSQL Professional'ist ütlesid, et meil on mäluleke. Need olid tõepoolest olemas, me parandasime need. Kuid see oli lihtsalt.
Siis avastasime, et connection pooleris on sissetulevad TLS-ühendused ja väljaminevad TLS-ühendused. Ja ühendustes on vajalikud kliendi ja serveri sertifikaadid.
Bouncer ja Odyssey serveri sertifikaadid loevad neid pcache'ist, kuid kliendi sertifikaate pcache'ist lugema ei pea, kuna meie skaleeritav Odyssey põrkab lõpuks vastu selle sertifikaadi süsteemset lugemisvõimet. See oli meile üllatus, kuna ta ei põrganud kohe. Alguses kasvas see lineaarselt, kuid pärast 20 000 sissetulevat samal ajal ühendust ilmus see probleem.
Pluggable Authentication Method on võimalus autentida end sisseehituslike Linuxi vahenditega. PgBounceris on see niimoodi teostatud, et on eraldi teema PAM'i vastuse ootamiseks ja on peamine PgBounceri teema, mis teenindab praegust ühendust ja saab paluda neil PAM'i teemas elada.
Me ei hakkanud seda teostama ühe lihtsa põhjuse tõttu. Meil on ju palju teemasid. Miks me seda vajame?
Lõppkokkuvõttes võib see tekitada probleeme, kuna kui teil on PAM-autentimine ja mitte-PAM-autentimine, võib suur PAM-autentimise voog oluliselt viivitada mitte-PAM-autentimist. See on üks neist asjadest, mida me ei parandanud. Kuid kui soovite seda parandada, võite sellega tegeleda.
Veel on olnud probleeme seoses ühe vooga, mis aktsepteerib kõiki sisenemisühendusi. Seejärel edastatakse need töötlejate rühmale, kus toimub TLS käepigistus.
Seetõttu, kui teil on koherentne laine 20 000 võrguühendust, siis need kõik aktsepteeritakse. Klientide poolel hakkab libpq loendama aegumisi. Oletan, et vaikimisi on seal 3 sekundit.
Kui nad ei saa kõik korraga andmebaasi siseneda, siis nad ei pääse andmebaasi, kuna seda kõike ei saa katmata jätta mitteeksponentsiaalse katsetamise tõttu.
Oleme jõudnud järeldusele, et oleme siin õppinud PgBounceri skeemi, rakendades TCP-ühenduste aktsepteerimise arvule piiramist.
Kui me märkame, et aktsepteerime ühendusi, aga nad ei suuda lõpuks ühenduda, siis paneme nad järjekorda, et nad ei raiskaks keskprotsessori ressursse. See tähendab, et samal ajal ei pruugi kõik ühendused käepigistust saada. Kuid vähemalt keegi pääseb andmebaasi, isegi kui koormus on piisavalt suur.
Roadmap
Mida sooviksime tulevikus Odyssey's näha? Mida me oleme valmis ise arendama ja mida ootame kogukonnalt?
August 2019.
Nii nägid välja Odyssey teekaardid augustis:
- Soovisime SCRAM ja PAM autentimist.
- Soovisime suunata lugemis запросid standby peale.
- Sooviksime online-taaskäivitust.
- Ja võimalust teha serveris paus.
Pool sellest teekaardist on täidetud, millest ei vastuta meie. Ja see on hea. Niisiis, arutame, mis on jäänud ja lisame veel.
? У нас есть реплики, которые без выполнения запросов будут просто греть воздух. Они нам необходимы для обеспечения failover и switchover. В случае проблем в одном из дата-центре хотелось бы их занять какой-то полезной работой. Потому что те же самые центральные процессоры, ту же самую память мы не можем сконфигурировать по-другому, потому что иначе не будет работать репликация.
Põhimõtteliselt on Postgresis alates kümnendast versioonist võimalik ühenduse loomisel määrata ka session_attrs. Võite ühenduses loetleda kõik andmebaasi hostid ja öelda, miks te andmebaasi lähenete: kirjutamiseks või ainult lugemiseks. Ja draiver valib ise esimesena loetletud hosti, mis talle rohkem meeldib ja mis täidab session_attrs nõudeid.
Aga selle lähenemise probleem on see, et see ei kontrolli replikatsiooni viivitust. Teil võib olla mingi replikatsioon, mis on viibinud teie teenuse jaoks vastuvõetamatult kaua. Selleks, et täita täielikult lugemis запросide töötlemist replikas, peame põhimõtteliselt Odyssey's võimaldama mitte töötada, kui lugemine ei ole võimalik.
Odyssey peab aeg-ajalt andmebaasi minema ja küsima replikatsiooni kaugust primaarse andmebaasist. Ja kui see on saavutanud kriitilise taseme, ei tohi uusi päringuid andmebaasi lubada, vaid tuleb öelda kliendile, et ühendused tuleb uuesti algatada ja võib-olla valida teine host päringute täitmiseks. See võimaldab andmebaasil kiiremini taastada replikatsiooni viivituse ja taas vastata päringutele.
Raskusi ajakavade määramisel, kuna see on avatud lähtekoodiga. Kuid loodan, et mitte 2,5 aastat nagu kolleegidel PgBounceris. Selle funktsiooni sooviksin näha Odyssey's.
Praegu saate luua prepared statement'e kahe meetodi kaudu. Esiteks, saate täita SQL-käsku, nimelt "prepared". Selle SQL-käsku mõistmiseks peame õppima SQL-i mõistma Bounceri poolelt. See oleks liialdus, kuna me vajame täis parserit. Me ei saa pärida iga SQL-käsku.
Kuid protokolli sõnumite tasandil on olemas ettevalmistatud päring. See on koht, kus teave selle kohta, et luuakse ettevalmistatud päring, tuleb struktureeritud vormis. Me võiksime toetada arusaamist, et mingis serveriühenduses palus klient luua ettevalmistatud päringud. Ja isegi juhul, kui tehing on suletud, peame endiselt hoidma serveri ja kliendi vahelist sidusust.
Kuid siin tekib dialoogis lahknevus, sest keegi räägib sellest, et on vaja mõista, milliseid ettevalmistatud päringuid klient on loonud ja jagada serveriühendust kõigi klientide vahel, kes on selle serveriühenduse loonud, st kes on loonud sellise ettevalmistatud päringu.
Andres Freund ütles, et kui teie juurde tuleb klient, kes on juba loonud teises serveriühenduses sellise ettevalmistatud päringu, siis looge see tema jaoks. Kuid tundub, et see on veidi vale sooritada päringud andmebaasis kliendi eest, kuid arendaja, kes kirjutab andmebaasiga suhtlemise protokolli, jaoks oleks mugav, kui talle lihtsalt antakse võrguühendus, kus see ettevalmistatud päring on olemas.
Ja veel üks funktsioon, mida peame ellu viima. Meil on praegu PgBounceriga ühilduv jälgimise süsteem. Saame tagastada 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.
Me peame rakendama toetust protsentidele, mis näitavad, et on olemas aeglased päringud, mis tarbivad ressursse, ning teevad jälgimise vastuvõetavamaks.
Kõige tähtsam on, et soovime versiooni 1.0 (versioon 1.1 on juba välja antud). Probleem on selles, et Odyssey on hetkel versioonis 1.0rc, see tähendab väljaandmise kandidaat. Kõik probleemid, mida ma loetlesin, on parandatud just selle versiooniga, välja arvatud mäluleke.
Mida tähendab meile versioon 1.0? Me viime Odyssey oma andmebaasidesse. See töötab juba praegu meie andmebaasides, kuid kui see saavutab 1 000 000 päringut sekundis, siis võime öelda, et see on väljaandmise versioon ning seda saab nimetada 1.0-ks.
Kogukonnas on mitmed inimesed palunud, et versioonis 1.0 oleksid ka paus ja SCRAM. Kuid see tähendaks, et peame järgmise versiooni tootmisse viima, sest ei SCRAM ega paus pole siiani ühendatud. Tõenäoliselt lahendatakse see küsimus piisavalt kiiresti.
Ootan teie pull request'e. Samuti tahaksin kuulda, millised probleemid teil Bounceriga on. Arutame neid. Võib-olla suudame rakendada mõningaid funktsioone, mis teile vajalikud on.
Sellega minu osa lõppeb, tahan teid kuulata. Aitäh!
Küsimused
Kui ma oma application_name'i panen, kas see liikub õigesti edasi, sealhulgas transaction pooling'is Odyssey's?
Odyssey's või Bouncer'is?
Odyssey's. Bouncer'is liigub see edasi.
Me teeme set'i.
Ja kui mu tegelik ühendus hüppab teiste ühenduste vahel, kas see liigub edasi?
Teeme set'i kõikide parameetritega, mis on loendis. Ma ei saa öelda, kas selles loendis on application_name. Tundub, et olen seda seal näinud. SeSetting kõik need samad parameetrid. Ühe päringuga teeb see kõik, mis klient oli seadistanud käivitamisel.
Aitäh, Andrei, et esitlus oli! Hea esitlus! Mul on hea meel, et Odyssey areneb iga minutiga üha kiiremini. Soovin teile jätkuvat edu. Oleme juba teie poole pöördunud palvega, et meil oleks multi data-source ühendus, et Odyssey saaks korraga ühendada erinevate andmebaasidega, st master-slave ja siis automaatselt pärast failoverit ühendada uue meistriga.
Jah, ma arvan, et mäletan seda arutelu. Praegu on mitmeid salvestusruume. Kuid nende vahel ei ole vahetamist. Me peame oma poolel küsima serverilt, kas see on ikka elus ja mõistma, et failover on juhtunud, kes kutsub esile pg_recovery. Mul on standardne viis, et mõista, et me ei ole meistris. Ja me peame kuidagi vigadest aru saama, eks? St idee on huvitav, seda arutatakse. Kirjutage rohkem kommentaare. Kui teil on õigerahvast, kes tunnevad C-d, siis on see tõeliselt suurepärane.
Meid huvitab ka replikatsiooniga seotud skaleerimine, sest me tahame teha replikatsiooniklastrite adopteerimise arendajatele võimalikult lihtsaks. Aga siinkohal sooviksime rohkem kommentaare, st kuidas täpselt teha ja kuidas hästi teha.
Küsimus puudutab ka replikaate. Tundub, et teil on üks põhi ja mitu replikat. On selge, et replikad saavad vähem ühendusi kui põhi, kuna andmed võivad erineda. Te mainisite, et andmete erinevused võivad olla sellised, et need ei rahulda teie äri vajadusi ja te ei kasuta neid enne, kui need on täielikult replikeeritud. Kui teil on olnud pikem periood, mil te ei kasutanud replikat, ja siis hakkate taas kasutama, siis ei pruugi vajalikud andmed kohe kergesti kätte saada. Ehk siis, kui me pidevalt kasutame põhi, on seal vahemälu soojendatud, samas kui replikas on vahemälu veidi aeglasem.
Jah, see on tõsi. pcache'is ei ole andmeplokke, mida te soovite, real cache'is ei ole teavet tabelite kohta, mida te soovite, plaanides ei ole analüüsitud päringuid, üldse mitte midagi ei ole.
Ja kui teil on mõni klaster ja lisate sinna uue repliika, siis kuni see käivitub, on seal kõik halb, st see suurendab oma vahemälu.
Ma sain mõtte kätte. Õige lähenemine oleks käivitada alguses väike protsent päringutest replikale, et soojendada vahemälu. Tõeliselt öeldes, meil on tingimus, et me ei tohi mahajääda rohkem kui 10 sekundi võrra masterist. Ja seda tingimust tuleks rakendada mitte ühe laines, vaid sujuvalt mõne kliendi jaoks.
Jah, suurendada kaalu.
See on hea idee. Kuid kõigepealt tuleb see väljalülitamine ellu viia. Alguses tuleb välja lülituda ja siis mõtleme, kuidas sisse lülituda. See on suurepärane funktsioon, et sujuvalt sisse lülituda.
Nginx'is on selline valik. sujuvalt alustada serveri klastris. Ja see suurendab järk-järgult koormust.
Jah, suurepärane idee, proovime, kui me selleni jõuame.
Allikas: habr.com
