I f\u00e6llesskabet har folk spurgt om st\u00f8tte til prepared statement.<\/a><\/noindex>. Du kan nu oprette prepared statements p\u00e5 to m\u00e5der. For det f\u00f8rste kan du udf\u00f8re SQL-kommandoen, nemlig \"prepared\". For at forst\u00e5 denne SQL-kommando, skal vi l\u00e6re at forst\u00e5 SQL fra Bouncer-siden. Det ville v\u00e6re overkill, fordi vi har brug for en fuld parser. Vi kan ikke parse hver SQL-kommando. <\/p>\n<\/p>\n
Men der er prepared statements p\u00e5 niveauet for meddelelsesprotokol p\u00e5 proto3. Og det er her, informationen om, at der oprettes et prepared statement, kommer i struktureret form. Vi kunne st\u00f8tte forst\u00e5elsen af, at en klient har bedt om at oprette prepared statements p\u00e5 en eller anden serverforbindelse. Og selvom transaktionen er afsluttet, skal vi stadig opretholde sammenh\u00e6ngen mellem serveren og klienten. <\/p>\n
<\/p>\n
Men her opst\u00e5r der et misforhold i dialogen, fordi nogen siger, at det er n\u00f8dvendigt at forst\u00e5, hvilken pr\u00e6cist prepared statement klienten har oprettet, og at dele serverforbindelsen mellem alle klienter, der har oprettet denne serverforbindelse, dvs. hvilke der har oprettet et s\u00e5dant prepared statement. <\/p>\n
<\/p>\n
Andres Freund sagde, at hvis en klient kommer til dig, som allerede har oprettet et s\u00e5dant prepared statement i en anden serverforbindelse, s\u00e5 opret det for ham. Men det virker lidt forkert at udf\u00f8re foresp\u00f8rgsler i databasen i stedet for klienten, men set fra en udviklers perspektiv, der skriver protokollen for interaktion med databasen, ville det v\u00e6re praktisk, hvis han bare fik en netv\u00e6rksforbindelse, hvor der var en s\u00e5dan forberedt foresp\u00f8rgsel. <\/p>\n
<\/p>\n
<\/p>\n
Og endnu en funktion, som vi skal implementere. Vi har nu overv\u00e5gning, der er kompatibel med PgBouncer. Vi kan returnere den gennemsnitlige udf\u00f8relsestid for foresp\u00f8rgslen. Men den gennemsnitlige tid er som gennemsnitstemperaturen p\u00e5 hospitalet: nogen er kolde, nogen er varme \u2013 i gennemsnit er alle raske. Det er ikke sandt. <\/p>\n
<\/p>\n
Vi skal implementere st\u00f8tte til percentiler, som ville angive, at der er langsomme foresp\u00f8rgsler, der forbruger ressourcer, og g\u00f8re overv\u00e5gningen mere acceptabel. <\/p>\n
<\/p>\n
<\/p>\n
Det vigtigste er, at vi \u00f8nsker version 1.0 (Version 1.1 er allerede udgivet). Faktisk er Odyssey i \u00f8jeblikket i version 1.0rc, dvs. release candidate. Og alle de problemer, jeg har n\u00e6vnt, blev l\u00f8st med netop den version, bortset fra memory leak. <\/p>\n
<\/p>\n
Hvad betyder version 1.0 for os? Vi ruller Odyssey ud p\u00e5 vores databaser. Det fungerer allerede nu p\u00e5 vores systemer, men n\u00e5r det n\u00e5r 1.000.000 foresp\u00f8rgsler i sekundet, kan vi sige, at det er en release-version, og det er den version, der kan kaldes 1.0. <\/p>\n
<\/p>\n
I f\u00e6llesskabet har flere bedt om, at version 1.0 ogs\u00e5 inkluderer pause og SCRAM. Men det vil betyde, at vi skal rulle den n\u00e6ste version ud i produktion, fordi hverken SCRAM eller pause er blevet merged endnu. Men det er sandsynligvis et sp\u00f8rgsm\u00e5l, der vil blive l\u00f8st hurtigt. <\/p>\n
<\/p>\n
<\/p>\n
Jeg venter p\u00e5 dine pull requests. Og jeg vil ogs\u00e5 gerne h\u00f8re, hvilke problemer du har med Bouncer. Lad os diskutere dem. M\u00e5ske kan vi implementere nogle funktioner, som du har brug for. <\/p>\n
<\/p>\n
Nu er min del slut, jeg vil gerne h\u00f8re fra dig. Tak!<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l<\/p>\n
<\/p>\n
Hvis jeg angiver application_name, vil det korrekt blive videregivet, ogs\u00e5 i transaction pooling i Odyssey?<\/em><\/p>\n<\/p>\n
I Odyssey eller i Bouncer?<\/p>\n
<\/p>\n
I Odyssey. I Bouncer bliver det videregivet.<\/em> <\/p>\n<\/p>\n
Vi vil lave et s\u00e6t. <\/p>\n
<\/p>\n
Og hvis min faktiske forbindelse hopper mellem andre forbindelser, vil den s\u00e5 blive videregivet?<\/em><\/p>\n<\/p>\n
Vi vil lave et s\u00e6t af alle parametre, der er angivet i listen. Jeg kan ikke sige, om application_name er i denne liste. Jeg mener, jeg har set det der. Vi vil stille alle de samme parametre op. Med \u00e9n foresp\u00f8rgsel vil s\u00e6ttet g\u00f8re alt det, der var indstillet af klienten ved opstart. <\/p>\n
<\/p>\n
Tak, Andrey, for pr\u00e6sentationen! God pr\u00e6sentation! Jeg er glad for, at Odyssey udvikler sig hurtigere for hver minut. Jeg \u00f8nsker, at det forts\u00e6tter s\u00e5dan. Vi har allerede kontaktet jer med en foresp\u00f8rgsel om at have multi data-source forbindelse, s\u00e5 Odyssey kan tilsluttes samtidig til forskellige databaser, dvs. master-slave, og derefter automatisk skifte til den nye master efter failover.<\/em> <\/p>\n<\/p>\n
Ja, jeg mener, jeg husker denne diskussion. Der er nu flere lagre. Men der er ikke nogen skift imellem dem. Vi skal p\u00e5 vores side sp\u00f8rge serveren, om den stadig er aktiv og forst\u00e5, at der er sket en failover, hvem der vil kalde pg_recovery. Jeg har en standardmetode til at forst\u00e5, at vi ikke er kommet til masteren. Og skal vi forst\u00e5 noget fra fejlene, eller hvordan? Dvs. ideen er interessant, den diskuteres. Skriv flere kommentarer. Hvis du har aktive h\u00e6nder, der kender C, ville det v\u00e6re fantastisk. <\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5let om skalering via replikaer interesserer os ogs\u00e5, fordi vi \u00f8nsker at g\u00f8re adoptionen af replikerede klynger s\u00e5 enkel som muligt for applikationsudviklerne. Men her ville jeg gerne have mere kommentarer, alts\u00e5 hvordan det pr\u00e6cist g\u00f8res, og hvordan man g\u00f8r det godt. <\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5let handler ogs\u00e5 om replikaer. Det viser sig, at I har en master og flere replikaer. Og det er klart, at der forbindes sj\u00e6ldnere til en replika end til masteren, fordi der kan v\u00e6re forskelle. I har sagt, at forskellene i data kan v\u00e6re s\u00e5dan, at det ikke vil opfylde jeres forretning, og I vil ikke tage til den, f\u00f8r den er blevet replikeret. Hvis I har v\u00e6ret lidt l\u00e6nge v\u00e6k, og s\u00e5 begyndt at forbinde igen, s\u00e5 vil de data, I har brug for, ikke v\u00e6re tilg\u00e6ngelige med det samme. Det vil sige, at hvis vi konstant forbinder til masteren, s\u00e5 er cachen der varm, mens cachen i replikaen er lidt bagud.<\/em> <\/p>\n<\/p>\n
Ja, det er rigtigt. I pcache vil der ikke v\u00e6re de data, som I \u00f8nsker, i real cache vil der ikke v\u00e6re information om de tabeller, som I \u00f8nsker, i planerne vil der ikke v\u00e6re parsede foresp\u00f8rgsler, overhovedet ingenting vil v\u00e6re der. <\/p>\n
<\/p>\n
Og n\u00e5r I har en eller anden klynge, og I tilf\u00f8jer en ny replika til den, s\u00e5 mens den starter op, er den i en d\u00e5rlig tilstand, alts\u00e5 den opbygger sin cache.<\/em> <\/p>\n<\/p>\n
Jeg forstod ideen. Den rigtige tilgang ville v\u00e6re at k\u00f8re en lille procentdel af foresp\u00f8rgslerne f\u00f8rst til replikaen for at varme cachen op. Groft sagt, vi har en betingelse om, at vi ikke m\u00e5 v\u00e6re mere end 10 sekunder bagud i forhold til masteren. Og denne betingelse skal ikke aktiveres i \u00e9n b\u00f8lge, men gradvist for nogle kunder. <\/p>\n
<\/p>\n
Ja, \u00f8ge v\u00e6gten.<\/em><\/p>\n<\/p>\n
Det er en god id\u00e9. Men f\u00f8rst skal vi implementere denne frakobling. F\u00f8rst skal vi koble fra, og s\u00e5 t\u00e6nker vi over, hvordan vi kobler til igen. Det er en fremragende funktion, at vi kan koble til gradvist.<\/p>\n
<\/p>\n
I nginx er der en s\u00e5dan mulighed slowly start<\/code> i klyngen til serveren. Og den \u00f8ger gradvist belastningen.<\/em> <\/p>\n<\/p>\n
Ja, fantastisk id\u00e9, vi pr\u00f8ver, n\u00e5r vi n\u00e5r dertil.<\/p>\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043d\u0434\u0440\u0435\u0439 \u0411\u043e\u0440\u043e\u0434\u0438\u043d \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442, \u043a\u0430\u043a \u043e\u043d\u0438 \u0443\u0447\u043b\u0438 \u043e\u043f\u044b\u0442 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f PgBouncer \u043f\u0440\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438 \u043f\u0443\u043b\u0435\u0440\u0430 \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u0439 Odyssey, \u043a\u0430\u043a \u0432\u044b\u043a\u0430\u0442\u044b\u0432\u0430\u043b\u0438 \u0435\u0433\u043e \u0432 production. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043e\u0431\u0441\u0443\u0434\u0438\u043c \u043a\u0430\u043a\u0438\u0435 \u0444\u0443\u043d\u043a\u0446\u0438\u0438 \u043f\u0443\u043b\u0435\u0440\u0430 \u0445\u043e\u0442\u0435\u043b\u043e\u0441\u044c \u0431\u044b \u0432\u0438\u0434\u0435\u0442\u044c \u0432 \u043d\u043e\u0432\u044b\u0445 \u0432\u0435\u0440\u0441\u0438\u044f\u0445: \u043d\u0430\u043c \u0432\u0430\u0436\u043d\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0437\u0430\u043a\u0440\u044b\u0432\u0430\u0442\u044c \u0441\u0432\u043e\u0438 \u043f\u043e\u0442\u0440\u0435\u0431\u043d\u043e\u0441\u0442\u0438, \u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u043e \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u041e\u0434\u0438\u0441\u0441\u0435\u044f. \u0412\u0438\u0434\u0435\u043e: \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043d\u0434\u0440\u0435\u0439. \u0412 \u042f\u043d\u0434\u0435\u043a\u0441\u0435 \u044f \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0441\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96516,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96515","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\ud83e\udd47Windows](\"\/wp-content\/uploads\/2020\/10\/6c445191705a4c96939cd094bc457a53.jpg\")
<\/p>\n