Andrei Borodin räägib oma kõnes, kuidas nad võtsid ühenduste kogumi loomisel arvesse PgBounceri skaleerimise kogemust. , kuidas nad selle tootmises kasutusele võtsid. Lisaks arutleme, milliseid basseini funktsioone sooviksime uutes versioonides näha: meie jaoks on oluline mitte ainult oma vajaduste katmine, vaid kasutajate kogukonna arendamine. .
Video:
Tere kõigile! Minu nimi on Andrew.
Yandexis arendan avatud lähtekoodiga andmebaase. Ja täna on meil teema ühenduste kogumi ühenduste kohta.
Kui tead, kuidas vene keeles ühenduse poolerit helistada, siis ütle mulle. Ma tõesti tahan leida head tehnilist terminit, mis tuleks tehnilises kirjanduses paika panna.
Teema on üsna keeruline, kuna paljudes andmebaasides on ühenduste koguja sisse ehitatud ja te ei pea sellest isegi teadma. Mõned sätted on loomulikult kõikjal, kuid Postgres see ei tööta. Ja paralleelselt (HighLoad++ 2019) on Nikolai Samokhvalovi aruanne päringute seadistamise kohta Postgresis. Ja ma saan aru, et siia on tulnud inimesi, kes on päringud juba suurepäraselt konfigureerinud ja need on inimesed, kes seisavad silmitsi harvemate süsteemiprobleemidega, mis on seotud võrgu, ressursside kasutamisega. Ja mõnes kohas võib see olla üsna keeruline selles mõttes, et probleemid pole ilmsed.
Yandexil on Postgres. Paljud Yandexi teenused asuvad Yandex.Cloudis. Ja meil on mitu petabaiti andmeid, mis genereerivad Postgresis vähemalt miljon päringut sekundis.
Ja pakume kõigi teenuste jaoks üsna tüüpilist klastrit - see on sõlme peamine esmane sõlm, tavalised kaks koopiat (sünkroonne ja asünkroonne), varundamine, koopia lugemistaotluste skaleerimine.
Iga klastri sõlm on Postgres, millele lisaks Postgresile ja monitooringusüsteemidele on paigaldatud ka ühenduste koguja. Ühenduspoolerit kasutatakse tarastamiseks ja selle põhiotstarbeks.
Mis on ühenduse ühendaja peamine eesmärk?
Postgres võtab andmebaasiga töötamiseks kasutusele protsessimudeli. See tähendab, et üks ühendus on üks protsess, üks Postgresi taustaprogramm. Ja selles taustaprogrammis on palju erinevaid vahemälu, mida on erinevate ühenduste jaoks üsna kulukas teha.
Samuti on Postgresi koodis massiiv nimega procArray. See sisaldab põhiandmeid võrguühenduste kohta. Ja peaaegu kõik procArray töötlemisalgoritmid on lineaarse keerukusega, need läbivad kogu võrguühenduste massiivi. See on üsna kiire tsükkel, kuid suurema sissetuleva võrguühenduse korral lähevad asjad veidi kallimaks. Ja kui asjad lähevad veidi kallimaks, maksate suure hulga võrguühenduste eest väga kõrget hinda.
Võimalikud on 3 lähenemisviisi:
- Rakenduse poolel.
- Andmebaasi poolel.
- Ja vahel, st kõikvõimalikud kombinatsioonid.
Kahjuks on sisseehitatud basseiner praegu väljatöötamisel. Seda teevad enamasti PostgreSQL Professionali sõbrad. Millal see ilmub, on raske ennustada. Ja tegelikult on meil arhitekti valikul kaks lahendust. Need on rakendusepoolne kogum ja puhverserveri kogum.
Rakendusepoolne bassein on lihtsaim viis. Ja peaaegu kõik kliendidraiverid pakuvad teile võimalust: esitada miljoneid oma ühendusi koodis mõnekümnete ühendustena andmebaasiga.
Probleem on selles, et teatud hetkel soovite taustaprogrammi skaleerida, soovite selle juurutada paljudes virtuaalsetes masinates.
Siis saad ikka aru, et sul on veel mitu saadavuse tsooni, mitu andmekeskust. Ja kliendipoolne koondamisviis toob kaasa suuri numbreid. Suured on umbes 10 000 ühendust. See on serv, mis võib hästi töötada.
Kui me räägime puhverserveritest, siis on kaks poolitajat, kes saavad teha palju asju. Nad ei ole ainult pooldajad. Need on poolerid + lahedam funktsionaalsus. See и .
Kuid kahjuks ei vaja kõik seda lisafunktsiooni. Ja see toob kaasa asjaolu, et poolerid toetavad ainult seansside ühendamist, st ühte sissetulevat klienti ja ühte väljaminevat klienti andmebaasi.
See ei ole meie ülesannete jaoks eriti sobiv, seetõttu kasutame PgBouncerit, mis rakendab tehingute ühendamist, st serveriühendused kaardistatakse kliendiühendustega ainult tehingu ajaks.
Ja meie koormusel – see on tõsi. Kuid on mitmeid probleeme.
Probleemid algavad siis, kui soovite seanssi diagnoosida, kuna kõik sissetulevad ühendused on kohalikud. Kõik tulid loopbackiga ja millegipärast muutub seansi jälgimine keeruliseks.
Muidugi võite kasutada rakenduse_nimi_add_host. See on Bounceri kõrvalviis IP-aadressi lisamiseks rakenduse_nimi. Kuid rakenduse_nimi määrab lisaühendus.
Sellel diagrammil, kus kollane joon on tegelikud päringud ja sinine joon andmebaasi lendavad taotlused. Ja see erinevus on just rakenduse_nimi seadistus, mida on vaja ainult jälgimiseks, kuid see pole üldse tasuta.
Lisaks ei saa Bouncer piirata ühte kogumit, st andmebaasiühenduste arvu kasutaja kohta andmebaasi kohta.
Milleni see viib? Sul on laaditud teenus, mis on kirjutatud C ++ keeles ja kuskil läheduses väike teenus sõlmes, mis ei tee baasile midagi valesti, kuid selle draiver läheb hulluks. See avab 20 000 ühendust ja kõik muu jääb ootama. Isegi teie kood on õige.
Muidugi kirjutasime Bouncerile väikese plaastri, mis lisas selle sätte, st piiras klientide kogumist.
Seda oleks võimalik teha Postgresi poolel ehk piirata rollid andmebaasis ühenduste arvuga.
Kuid siis kaotate võime mõista, miks teil pole serveriga ühendusi. PgBouncer ei viska ühenduse viga, vaid tagastab alati sama info. Ja te ei saa aru: võib-olla on teie parool muutunud, võib-olla läks andmebaas lihtsalt alla, võib-olla on midagi valesti. Kuid diagnoosi pole. Kui seanssi ei saa luua, ei saa te teada, miks seda teha ei saa.
Teatud hetkel vaatad rakenduse graafikuid ja näed, et rakendus ei tööta.
Vaadake ülaosa ja vaadake, et Bouncer on ühe keermega. See on pöördepunkt teenuse elus. Saate aru, et valmistusite pooleteise aastaga andmebaasi skaleerima ja teil on vaja koondurit skaleerida.
Oleme jõudnud järeldusele, et vajame rohkem PgBouncereid.
Bouncer on veidi lapitud.
Ja nad tegid selle nii, et TCP-pordi taaskasutamise abil saab mitu põrgatajat kasvatada. Ja juba operatsioonisüsteem edastab sissetulevad TCP-ühendused nende vahel automaatselt ümberringi.
See on klientide jaoks läbipaistev, st tundub, et teil on üks väljaviskaja, kuid töötavate väljaviskajate vahel on tühikäiguühendused killustatud.
Ja mingil hetkel võite märgata, et need 3 põrgatajat söövad igaüks 100% oma tuuma ära. Teil on vaja üsna palju põrgajaid. Miks?
Kuna teil on TLS. Teil on krüpteeritud ühendus. Ja kui võrdlete Postgresi TLS-iga ja ilma, avastate, et loodud ühenduste arv väheneb peaaegu kahe suurusjärgu võrra, kui krüptimine on lubatud, kuna TLS-i käepigistus kulutab protsessori ressursse.
Ja ülaosas näete üsna palju krüptograafilisi funktsioone, mis käivitatakse sissetulevate ühenduste laine ajal. Kuna meie esmane saab vahetada saadavustsoonide vahel, on sissetulevate ühenduste laine üsna tüüpiline olukord. See tähendab, et millegipärast ei olnud vana esmane saadaval, kogu koormus saadeti teise andmekeskusesse. Kõik nad tulevad korraga TLS-ile tere ütlema.
Ja suur hulk TLS-i käepigistust ei pruugi Bouncerit juba tervitada, vaid pigistab kurku. Sissetulevate ühenduste laine võib aegumise tõttu muutuda summutuks. Kui proovite baasi uuesti ilma eksponentsiaalse tagasilöögita, ei tule need sidusa lainega ikka ja jälle tagasi.
Siin on näide 16 PgBouncerist, mis laadivad 16% 100 tuuma.
Oleme jõudnud kaskaadse PgBounceri juurde. See on parim konfiguratsioon, mida saame oma põrkekoormusega saavutada. Meie välised tagasilöögid teenindavad TCP-käepigistust ja sisemised tagasilöögid tõeliseks ühendamiseks, et väliseid ühendusi mitte oluliselt killustada.
Selles konfiguratsioonis on võimalik pehme taaskäivitamine. Saate kõik need 18 põrgatajat ükshaaval taaskäivitada. Kuid sellise konfiguratsiooni säilitamine on üsna keeruline. Süsteemiadministraatorid, DevOps ja inimesed, kes selle serveri eest tegelikult vastutavad, ei ole selle skeemiga eriti rahul.
Näib, et kõiki meie täiustusi saab edendada avatud lähtekoodiga, kuid Bouncer ei toeta seda eriti hästi. Näiteks võimalus käitada mitut PgBouncerit samas pordis võeti kasutusele kuu aega tagasi. Selle funktsiooniga tõmbamistaotlus esitati paar aastat tagasi.
Või veel üks näide. Postgresis saate töötava päringu tühistada, saates saladuse teisele ühendusele ilma täiendava autentimiseta. Kuid mõned kliendid saadavad lihtsalt TCP-lähtestamise, st katkestavad võrguühenduse. Mida Bouncer sellega peale hakkab? Ta ei tee midagi. See jätkab taotluse täitmist. Kui olete saanud tohutul hulgal ühendusi, mis on väikeste päringutega aluse pannud, siis lihtsalt Bounceri ühenduse katkestamisest ei piisa, peate täitma ka need taotlused, mis andmebaasis töötavad.
See on paigatud ja probleem ei ole ikka veel Bounceri ülesvoolu liidetud.
Ja nii jõudsimegi järeldusele, et vajame oma ühenduste basseinerit, mida arendatakse, lapitakse, milles on võimalik kiiresti probleeme parandada ja mis loomulikult peab olema mitme lõimega.
Peamiseks ülesandeks seadsime mitmelõimestamise. Peame suutma hästi toime tulla sissetulevate TLS-ühenduste lainega.
Selleks tuli välja töötada eraldi raamatukogu nimega Machinarium, mis on mõeldud võrguühenduse masinaolekute kirjeldamiseks jadakoodina. Kui vaatate libpq lähtekoodi, näete üsna keerulisi kõnesid, mis võivad teile tagastada tulemuse ja öelda: "Helista mulle veidi hiljem. Praegu on mul IO praegu, aga kui IO läbi läheb, on mul protsessoril koormus. Ja see on mitmetasandiline skeem. Võrgu interaktsiooni kirjeldab tavaliselt olekumasin. Väga palju reegleid nagu "Kui varem sain paketi päise suurusega N, siis nüüd ootan N baiti", "Kui saatsin SYNC paketi, siis nüüd ootan tulemuste metaandmetega paketti." Selgub, et see on üsna keeruline intuitiivne kood, justkui oleks labürint muudetud reaskannimiseks. Tegime nii, et olekumasina asemel kirjeldab programmeerija peamist interaktsiooni teed tavalise imperatiivkoodi kujul. Just sellesse kohustuslikku koodi peate sisestama kohad, kus täitmisjada tuleb võrgust andmete ootamisega katkestada, edastades täitmiskonteksti teisele korutiinile (roheline lõime). Selline lähenemine sarnaneb sellega, et kirjutame rägastikus järjest üles kõige oodatuima tee ja seejärel lisame sellele harud.
Selle tulemusena on meil üks lõim, mis paneb TCP-d aktsepteerima ja ringhäälingu kaudu edastama TPC-ühenduse paljudele töötajatele.
Sellisel juhul töötab iga kliendiühendus alati ühel protsessoril. Ja see võimaldab teil muuta selle vahemälusõbralikuks.
Ja pealegi oleme süsteemi TCP-pinu mahalaadimiseks veidi täiustanud väikeste pakettide kogumist üheks suureks paketiks.
Lisaks oleme täiustanud tehingute ühendamist selles mõttes, et Odyssey saab konfigureerimisel saata CANCEL ja ROLLBACK võrguühenduse tõrke korral, st kui keegi päringut ei oota, ütleb Odyssey andmebaasile, et ärge proovige seda täita. taotlus, mis võib raisata väärtuslikke ressursse.
Ja võimalusel hoiame sidemeid sama kliendiga. See väldib rakenduse_nimi_add_host uuesti installimist. Võimaluse korral ei ole meil täiendavat diagnostikaks vajalike parameetrite lähtestamist.
Töötame Yandex.Cloudi huvides. Ja kui kasutate hallatud PostgreSQL-i ja teil on installitud ühenduse koguja, saate luua loogilise replikatsiooni väljapoole, st jätta meile soovi korral loogilise replikatsiooni abil. Väljaviskaja väljaspool voolu loogilise replikatsiooni ei anna.
See on näide loogilise replikatsiooni seadistamisest.
Lisaks on meil tugi füüsilisele replikatsioonile väljapoole. Pilves on see muidugi võimatu, sest siis annab klaster sulle enda kohta liiga palju infot. Kuid teie installides on see võimalik, kui vajate füüsilist replikatsiooni Odyssey ühenduse reservi kaudu.
Odysseyl on täielikult ühilduv jälgimine PgBounceriga. Meil on sama konsool, mis täidab peaaegu kõiki samu käske. Kui midagi on puudu, saatke tõmbamistaotlus või vähemalt probleem GitHubis, täidame vajalikud käsud. Kuid meil on juba PgBounceri konsooli põhifunktsioonid.
Ja loomulikult on meil vigade edastamine. Tagastame baasi teatatud vea. Saad infot, miks sa pole baasis, mitte ainult, et sa ei ole seal.
See funktsioon on keelatud, kui vajate 100% ühilduvust PgBounceriga. Võime igaks juhuks käituda nagu Bouncer.
Areng
Paar sõna Odyssey lähtekoodi kohta.
Näiteks on käsud "Pause / Jätka". Tavaliselt kasutatakse neid andmebaasi uuendamiseks. Kui teil on vaja Postgresi uuendada, saate selle ühenduse reservi peatada, teha pg_upgrade ja seejärel jätkata. Ja kliendi poolelt tundub, et andmebaas lihtsalt aeglustus. Selle funktsiooni tõid meieni kogukonna inimesed. Ta pole veel surnud, kuid varsti on kõik. (juba surnud)
- juba surnud
Lisaks on PgBounceris üheks uueks funktsiooniks SCRAM Authentication tugi, mille tõi meieni samuti inimene, kes Yandex.Cloudis ei tööta. Mõlemad on keeruka funktsionaalsusega ja olulised.
Seetõttu tahaksin teile rääkida, millest Odyssey on tehtud, juhuks, kui soovite ka nüüd koodi kirjutada.
Teil on algne Odyssey baas, mis tugineb kahele peamisele teegile. Kiwi raamatukogu on Postgresi sõnumiprotokolli rakendus. See tähendab, et Postgresi native proto 3 on standardsed sõnumid, mida esi- ja taustaprogrammid saavad vahetada. Neid rakendatakse Kiwi raamatukogus.
Machinarium'i teek on lõime rakendusteek. Väike fragment sellest Machinariumist on kirjutatud assembleris. Kuid ärge muretsege, seal on ainult 15 rida.
Odüsseia arhitektuur. Seal on põhimasin, mis töötab korutiinidega. See masin võtab vastu sissetulevaid TCP-ühendusi ja jaotab töötajate vahel.
Ühe töötaja piires võib töötada mitme kliendi töötleja. Ja ka põhilõimes keerleb konsool ja crone'i ülesannete töötlemine, et eemaldada ühendused, mida basseinis enam ei vajata.
Odyssey'd testitakse standardse Postgresi testikomplekti abil. Käivitame lihtsalt install-checki läbi Bounceri ja Odyssey kaudu saame null div. Kuupäeva vormindamisega on seotud mitu testi, mis ebaõnnestuvad Bounceris ja Odysseys täpselt samamoodi.
Lisaks on palju draivereid, millel on oma testimine. Ja me kasutame nende teste Odyssey testimiseks.
Lisaks peame meie kaskaadkonfiguratsiooni tõttu testima erinevaid komplekte: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey, et olla kindlad, et kui Odyssey on kaskaadi mõnes osas, töötab see ka ootuspäraselt .
Rake
Tootmises kasutame Odysseyt. Ja poleks aus, kui ma ütleksin, et kõik lihtsalt töötab. Ei, st jah, aga mitte alati. Näiteks tootmises kõik lihtsalt töötas, siis tulid meie sõbrad PostgreSQL Professionalist ja ütlesid, et meil on mäluleke. Need tõesti olid, me parandasime need ära. Aga see oli lihtne.
Seejärel leidsime, et ühenduste kogumisseadmel on sissetulevad TLS-ühendused ja väljaminevad TLS-ühendused. Ja ühendused vajavad kliendisertifikaate ja serverisertifikaate.
Bounceri ja Odyssey serveri sertifikaadid loetakse uuesti pc-vahemälu abil, kuid kliendisertifikaate ei ole vaja pc-vahemälust uuesti lugeda, sest meie skaleeritav Odyssey sõltub lõpuks selle sertifikaadi lugemise süsteemi jõudlusest. See tuli meile üllatusena, sest ta ei puhanud kohe välja. Alguses skaleeris see lineaarselt ja pärast 20 000 sissetulevat samaaegset ühendust avaldus see probleem.
Ühendatav autentimismeetod on võimalus autentida sisseehitatud Luux tööriistadega. PgBounceris on see rakendatud nii, et PAM-ilt vastust ootab eraldi lõim ja PgBounceri põhilõim, mis teenindab praegust ühendust ja võib paluda neil PAM-i lõimes elada.
Me ei rakendanud seda ühel lihtsal põhjusel. Meil on palju vooge. Miks me seda vajame?
Selle tulemusena võib see tekitada probleeme, kuna kui teil on PAM-autentimine ja mitte-PAM-autentimine, võib suur PAM-autentimise laine oluliselt edasi lükata mitte-PAM-autentimist. See on üks neist asjadest, mida me pole parandanud. Aga kui soovite seda parandada, saate seda teha.
Teine reha oli sellega, et meil on üks niit, mis võtab vastu kõik sissetulevad ühendused. Ja siis viiakse nad üle töötajate basseini, kus toimub TLS-i käepigistus.
Selle tulemusel, kui teil on 20 000 võrguühenduse sidus laine, võetakse need kõik vastu. Ja kliendi poolel hakkab libpq teatama ajalõppudest. Vaikimisi on see umbes 3 sekundit.
Kui nad ei saa kõik korraga baasi siseneda, siis nad ei saa ka baasi siseneda, sest seda kõike saab katta mitteeksponentsiaalse korduskatsega.
Kopeerisime siia lõpuks PgBounceri skeemi, nii et saame vastuvõetavate TCP-ühenduste arvu piirata.
Kui näeme, et võtame ühendust, aga neil pole lõpuks aega kätleda, paneme nad järjekorda, et nad protsessori ressursse ei tarbiks. See toob kaasa asjaolu, et kõigi saabunud ühenduste puhul ei pruugita üheaegset käepigistust sooritada. Aga vähemalt keegi siseneb andmebaasi, isegi kui koormus on piisavalt tugev.
Tegevuskava
Mida tahaksid tulevikus Odyssey's näha? Mida oleme valmis ise arendama ja mida ootame kogukonnalt?
Augustiks 2019.
Odyssey teekaart nägi augustis välja selline:
- Tahtsime SCRAM-i ja PAM-i autentimist.
- Tahtsime lugemistaotlused ooterežiimile edastada.
- Soovin võrgus taaskäivitamist.
- Ja serveris peatamise võimalus.
Pool sellest teekaardist on tehtud ja mitte meie. Ja see on hea. Nii et arutame, mis on jäänud, ja lisame veel.
? Meil on koopiad, mis ilma taotlusi täitmata lihtsalt soojendavad õhku. Vajame neid tõrkevahetuse ja ümberlülituse pakkumiseks. Kui mõnes andmekeskuses peaks tekkima probleeme, tahaksin need mõne kasuliku tööga hõivata. Kuna me ei saa samu keskprotsessoreid, sama mälu erinevalt konfigureerida, kuna replikatsioon muidu ei tööta.
Põhimõtteliselt on Postgres alates 10-st võimalik ühenduse loomisel määrata session_attrs. Saate loetleda kõik ühenduses olevad andmebaasi hostid ja öelda, miks te andmebaasi lähete: kirjutage või ainult lugemiseks. Ja draiver ise valib loendist esimese hosti, mis talle kõige rohkem meeldib ja mis vastab session_attrs nõuetele.
Kuid selle lähenemisviisi probleem on see, et see ei kontrolli replikatsiooni viivitust. Teil võib olla mõni koopia, mis on teie teenuse jaoks vastuvõetamatu aja pärast maha jäänud. Selleks, et koopial lugemistaotlusi täisfunktsionaalselt täita, peame Odyssey's toetama võimalust mitte töötada, kui seda pole võimalik lugeda.
Odyssey peab aeg-ajalt andmebaasi minema ja küsima replikatsiooni kaugust esmasest. Ja kui see on jõudnud piirini, ärge laske andmebaasi uusi päringuid, öelge kliendile, et peate ühendused uuesti algatama ja võimalusel valige päringute täitmiseks mõni muu host. See võimaldab andmebaasil replikatsiooni viivituse kiiresti taastada ja uuesti päringuga vastata.
Rakenduskuupäevi on raske nimetada, kuna tegemist on avatud lähtekoodiga. Aga ma loodan, et mitte 2,5 aastat nagu kolleegid PgBouncerist. See on omadus, mida ma Odyssey's näha tahaksin.
. Nüüd saate koostada koostatud avalduse kahel viisil. Esiteks saate käivitada SQL-i käsu, nimelt "valmistatud". Selle SQL-käsu mõistmiseks peame õppima, kuidas SQL-i põrgataja poolel mõista. See oleks liigne, sest see on liigne, kuna vajame kogu parserit. Me ei saa sõeluda iga SQL-käsku.
Kuid proto3-s on sõnumiprotokolli tasemel ettevalmistatud avaldus. Ja see on koht, kus teave, et koostatud avaldust luuakse, tuleb struktureeritud kujul. Ja me võiksime toetada arusaama, et mõnel serveriühendusel palus klient koostada ettevalmistatud väljavõtted. Ja isegi kui tehing on suletud, peame ikkagi hoidma serveri ja kliendi ühenduses.
Kuid siin tekib dialoogis lahknevus, sest keegi ütleb, et peate aru saama, millised koostatud väljavõtted klient lõi, ja jagama serveriühendust kõigi klientide vahel, kes selle serveriühenduse lõid, st kes sellise koostatud väljavõtte lõi.
Andres Freund ütles, et kui teie juurde tuli klient, kes on juba mõnes teises serveriühenduses sellise koostatud väljavõtte loonud, siis loo see talle. Aga tundub, et kliendi asemel andmebaasis päringuid teha on natuke vale, aga andmebaasiga suhtlemise protokolli kirjutava arendaja seisukohalt oleks mugav, kui talle lihtsalt võrguühendus antakse kellel on selline ettevalmistatud taotlus.
Ja veel üks funktsioon, mida peame rakendama. Meil on nüüd PgBounceriga ühilduv jälgimine. Saame tagastada päringu keskmise täitmise aja. Kuid keskmine aeg on keskmine temperatuur haiglas: kellelgi on külm, kellelgi soe – keskmiselt on kõik terved. See ei ole tõsi.
Peame juurutama protsentiilide toe, mis viitaks aeglastele päringutele, mis kulutavad ressursse ja muudaks jälgimise vastuvõetavamaks.
Kõige tähtsam on see, et ma tahan versiooni 1.0 (versioon 1.1 on juba välja antud). Fakt on see, et nüüd on Odyssey versioon 1.0rc, st väljalaskekandidaat. Ja kõik rehad, mis ma loetlesin, parandati täpselt sama versiooniga, välja arvatud mäluleke.
Mida versioon 1.0 meie jaoks tähendab? Veeretame Odyssey oma baasidesse. See juba töötab meie andmebaasides, kuid kui see jõuab punktini 1 000 000 päringut sekundis, siis võime öelda, et see on väljalaskeversioon ja see on versioon, mida võib nimetada 1.0-ks.
Mitmed kogukonna liikmed on palunud versioonis 1.0 rohkem pausi ja SCRAM-i. Kuid see tähendab, et peame järgmise versiooni tootmisse laskma, sest ei SCRAM-i ega pausi pole veel ühendatud. Kuid tõenäoliselt lahendatakse see probleem üsna kiiresti.
Ootan teie tõmbetaotlust. Ja ma tahaksin ka kuulda, millised probleemid teil Bounceriga on. Arutame neid. Võib-olla saame rakendada mõnda teile vajalikku funktsiooni.
Sellega ma lõpetan. Tahaksin teilt kuulda. Aitäh!
küsimused
Kui panen oma rakenduse_nime, kas see visatakse õigesti, sealhulgas Odyssey tehingute ühendamisel?
Odyssey või Bouncer?
Odüsseias. Väljaviskaja visatakse.
Teeme komplekti.
Ja kui minu tegelik ühendus hüppab üle teiste ühenduste, kas see edastatakse?
Koostame kõigi loetletud parameetrite komplekti. Ma ei saa öelda, kas rakenduse_nimi on selles loendis. Tundub, et ta nägi teda seal. Seadistame kõik samad parameetrid. Ühe taotlusega teeb komplekt kõik, mis klient käivitamise ajal installis.
Aitäh Andreile raporti eest! Hea aruanne! Mul on hea meel, et Odyssey areneb iga minutiga aina kiiremini. Tahaks samamoodi jätkata. Oleme juba palunud teil luua mitme andmeallika ühenduse, et Odyssey saaks samaaegselt ühenduda erinevate andmebaasidega, st alam-ülemaga, ja seejärel pärast tõrkesiiret automaatselt uue ülemseadmega ühenduse luua.
Jah, ma nagu mäletan seda arutelu. Nüüd on seal mitu hoidlat. Kuid nende vahel pole ümberlülitumist. Meie poolel peame küsima serverilt, kas see on endiselt elus, ja mõistma, et on toimunud tõrkevahetus, kes kutsub pg_recovery. Mul on standardne viis aru saada, et me ei tulnud meistri juurde. Ja me peame vigadest kuidagi aru saama või kuidas? See tähendab, et idee on huvitav, seda arutatakse. Kirjutage rohkem kommentaare. Kui teil on C-d tundvad töötavad käed, on see üldiselt suurepärane.
Meile pakub huvi ka koopiate skaleerimise küsimus, sest tahame teha paljundatud klastrite kasutuselevõtu rakenduste arendajatele võimalikult lihtsaks. Aga siin tahaks rohkem kommentaare ehk kuidas seda teha, kuidas hästi teha.
Küsimus on ka koopiate kohta. Selgub, et teil on kapten ja mitu koopiat. Ja selge on see, et nad käivad ühenduste jaoks harvemini replica kui masteri juures, sest neil võib vahe olla. Ütlesite, et andmete erinevus võib olla selline, et teie ettevõte ei rahulda ja te ei lähe sinna enne, kui see on paljundatud. Samal ajal, kui te ei käinud seal pikka aega ja hakkasite siis minema, pole vajalikud andmed kohe saadaval. See tähendab, et kui läheme pidevalt masteri juurde, soojendatakse vahemälu seal üles ja vahemälu on koopias veidi tagapool.
Jah, see on tõsi. Pcache'is ei ole soovitud andmeplokke, reaalses vahemälus pole teavet soovitud tabelite kohta, plaanides pole parsitud päringuid, üldse mitte midagi.
Ja kui teil on mingi klaster ja lisate sinna uue koopia, siis kui see käivitub, on selles kõik halvasti, st see suurendab vahemälu.
Sain ideest aru. Õige lähenemine oleks käivitada esmalt koopias väike protsent päringuid, mis soojendaks vahemälu. Jämedalt öeldes on meil tingimus, et me ei tohi meistrist maha jääda rohkem kui 10 sekundit. Ja see tingimus ei tohiks olla ühe lainega, vaid mõne kliendi jaoks sujuvalt.
Jah, tõsta kaalu.
See on hea mõte. Kuid kõigepealt peate selle sulgemise rakendama. Kõigepealt peame välja lülitama ja siis mõtleme, kuidas sisse lülitada. See on suurepärane funktsioon sujuvaks sisselülitamiseks.
nginxil on see valik slowly start serveri klastris. Ja ta kogub järk-järgult koormust.
Jah, suurepärane idee, proovime seda, kui selleni jõuame.
Allikas: www.habr.com