En la seva xerrada, Andrey Borodin us explicarà com van tenir en compte l'experiència de l'escalat de PgBouncer a l'hora de dissenyar un agrupador de connexions , com ho van desplegar en producció. A més, parlarem de quines funcions del pool ens agradaria veure en les noves versions: per a nosaltres és important no només cobrir les nostres necessitats, sinó desenvolupar la comunitat d'usuaris. .
Vídeo:
Hola a tots! Em dic Andreu.
A Yandex, estic desenvolupant bases de dades de codi obert. I avui tenim un tema sobre les connexions del pooler de connexions.
Si sabeu com trucar a l'agrupador de connexions en rus, digueu-m'ho. Tinc moltes ganes de trobar un bon terme tècnic que s'hagi d'establir a la literatura tècnica.
El tema és força complicat, perquè en moltes bases de dades l'agrupador de connexions està integrat i ni tan sols cal saber-ne. Alguns paràmetres, per descomptat, estan a tot arreu, però a Postgres això no funciona. I en paral·lel (a HighLoad++ 2019) hi ha un informe de Nikolai Samokhvalov sobre la configuració de consultes a Postgres. I entenc que aquí ha vingut gent que ja ha configurat les peticions perfectament, i es tracta de persones que s'enfronten a problemes més rars del sistema relacionats amb la xarxa, l'ús dels recursos. I en alguns llocs pot ser força difícil en el sentit que els problemes no són evidents.
Yandex té Postgres. Molts serveis Yandex viuen a Yandex.Cloud. I tenim diversos petabytes de dades que generen almenys un milió de sol·licituds per segon a Postgres.
I proporcionem un clúster bastant típic per a tots els serveis: aquest és el node principal principal del node, les dues rèpliques habituals (sincrònica i asíncrona), còpia de seguretat, escala de sol·licituds de lectura a la rèplica.
Cada node del clúster és Postgres, on, a més de Postgres i sistemes de monitorització, també s'instal·la un agrupador de connexions. Connection pooler s'utilitza per a tanques i per al seu propòsit principal.
Quin és l'objectiu principal d'un agrupador de connexions?
Postgres adopta un model de procés per treballar amb una base de dades. Això vol dir que una connexió és un procés, un backend de Postgres. I hi ha molts cachés diferents en aquest backend, que són bastant cars de fer diferents per a diferents connexions.
A més, hi ha una matriu al codi Postgres anomenada procArray. Conté dades bàsiques sobre les connexions de xarxa. I gairebé tots els algorismes de processament procArray tenen complexitat lineal, s'executen a través de tota la sèrie de connexions de xarxa. És un cicle força ràpid, però amb més connexions de xarxa entrants, les coses es fan una mica més cares. I quan les coses es fan una mica més cares, acabeu pagant un preu molt alt per un gran nombre de connexions de xarxa.
Hi ha 3 enfocaments possibles:
- Al costat de l'aplicació.
- Al costat de la base de dades.
- I entre, és a dir, totes les combinacions possibles.
Malauradament, el pool integrat està actualment en desenvolupament. Els amics de PostgreSQL Professional ho fan sobretot. Quan apareixerà és difícil de predir. I de fet, tenim dues solucions per a l'elecció d'un arquitecte. Aquests són el conjunt de l'aplicació i el grup de proxy.
La piscina del costat de l'aplicació és la manera més fàcil. I gairebé tots els controladors de client us ofereixen una manera: representar milions de connexions al codi com unes desenes de connexions a la base de dades.
Hi ha un problema amb el fet que en un moment determinat voleu escalar el backend, voleu desplegar-lo a moltes màquines virtuals.
Llavors encara us adoneu que teniu diverses zones de disponibilitat més, diversos centres de dades. I l'enfocament d'agrupació del client condueix a grans números. Les grans són unes 10 connexions. Aquesta és una vora que pot funcionar bé.
Si parlem de proxy poolers, hi ha dos poolers que poden fer moltes coses. No només són poolers. Són agrupadors + una funcionalitat més interessant. Això и .
Però, malauradament, no tothom necessita aquesta funcionalitat addicional. I porta al fet que els agrupadors només admeten l'agrupació de sessions, és a dir, un client entrant, un client sortint a la base de dades.
Això no és molt adequat per a les nostres tasques, de manera que utilitzem PgBouncer, que implementa l'agrupació de transaccions, és a dir, les connexions de servidor es mapegen a connexions de client només durant la durada de la transacció.
I en la nostra càrrega - és cert. Però hi ha diversos problemes.
Els problemes comencen quan voleu diagnosticar una sessió, perquè totes les connexions entrants són locals. Tothom va venir amb loopback i d'alguna manera es fa difícil rastrejar la sessió.
Per descomptat, podeu utilitzar application_name_add_host. Aquesta és la manera lateral de Bouncer per afegir una adreça IP al nom_aplicació. Però nom_aplicació s'estableix mitjançant una connexió addicional.
En aquest gràfic, on la línia groga són les sol·licituds reals, i on la línia blava són les peticions que volen a la base de dades. I aquesta diferència és precisament la configuració de nom_aplicació, que només es necessita per al rastreig, però no és gens gratuït.
A més, Bouncer no pot limitar un grup, és a dir, el nombre de connexions de base de dades per usuari i per base de dades.
A què comporta això? Teniu un servei carregat escrit en C ++ i a prop d'un petit servei en un node que no fa res amb la base, però el seu controlador es torna boig. Obre 20 connexions i tota la resta esperarà. Fins i tot el teu codi és correcte.
Per descomptat, vam escriure un petit pedaç per a Bouncer que va afegir aquesta configuració, és a dir, limitant els clients a la piscina.
Seria possible fer-ho al costat de Postgres, és a dir, limitar els rols de la base de dades al nombre de connexions.
Però aleshores perds la capacitat d'entendre per què no tens connexions amb el servidor. PgBouncer no llança cap error de connexió, sempre retorna la mateixa informació. I no ho podeu entendre: potser la vostra contrasenya ha canviat, potser la base de dades acaba de fallar, potser alguna cosa no funciona. Però no hi ha cap diagnòstic. Si la sessió no es pot establir, no sabràs per què no es pot fer.
En un moment determinat, mires els gràfics de l'aplicació i veus que l'aplicació no funciona.
Mireu la part superior i comproveu que Bouncer té un sol fil. Aquest és un punt d'inflexió en la vida del servei. Enteneu que us estaveu preparant per escalar la base de dades en un any i mig, i heu d'escalar el agrupador.
Hem arribat a la conclusió que necessitem més PgBouncers.
El goril ha estat lleugerament pegat.
I ho van fer perquè es puguin aixecar diversos Bouncers amb la reutilització del port TCP. I ja el sistema operatiu transfereix automàticament les connexions TCP entrants entre elles mitjançant round-robin'om.
Això és transparent per als clients, és a dir, sembla que teniu un Bouncer, però teniu una fragmentació de connexions inactives entre Bouncers en execució.
I en algun moment, podeu notar que aquests 3 Bouncers mengen cadascun el seu nucli al 100%. Necessites uns quants Bouncers. Per què?
Perquè tens TLS. Tens una connexió xifrada. I si feu una comparativa de Postgres amb i sense TLS, trobareu que el nombre de connexions establertes disminueix gairebé dos ordres de magnitud amb el xifratge habilitat, perquè l'enllaç de TLS consumeix recursos de la CPU.
I a la part superior, podeu veure unes quantes funcions criptogràfiques que s'executen durant una onada de connexions entrants. Com que la nostra principal pot canviar entre zones de disponibilitat, una onada de connexions entrants és una situació força típica. És a dir, per algun motiu, l'antiga primària no estava disponible, tota la càrrega es va enviar a un altre centre de dades. Tots vindran a saludar a TLS alhora.
I un gran nombre d'encaixades de mans TLS potser no saluden a Bouncer, però li estrenyen la gola. Una onada de connexions entrants pot quedar sense amortiment a causa del temps d'espera. Si torneu a intentar a la base sense un retrocés exponencial, no tornaran una i altra vegada en una onada coherent.
Aquí teniu un exemple de 16 PgBouncers que carreguen 16 nuclis al 100%.
Hem arribat al PgBouncer en cascada. Aquesta és la millor configuració que podem aconseguir amb la nostra càrrega Bouncer. Els nostres Bouncers externs serveixen per a l'enllaç TCP i els interns serveixen per a l'agrupació real, per tal de no fragmentar molt les connexions externes.
En aquesta configuració, és possible un reinici suau. Podeu reiniciar tots aquests 18 Bouncers un per un. Però mantenir aquesta configuració és bastant difícil. Els administradors del sistema, DevOps i les persones que són realment responsables d'aquest servidor no estaran molt contents amb aquest esquema.
Sembla que totes les nostres millores es poden promoure en codi obert, però Bouncer no és molt compatible. Per exemple, la possibilitat d'executar diversos PgBouncers al mateix port es va comprometre fa un mes. Una sol·licitud d'extracció amb aquesta funció va ser fa uns anys.
O un exemple més. A Postgres, podeu cancel·lar una sol·licitud en execució enviant el secret a una altra connexió sense l'autenticació addicional. Però alguns clients simplement envien un restabliment TCP, és a dir, trenquen la connexió de xarxa. Què farà Bouncer amb això? No farà res. Continuarà executant la sol·licitud. Si heu rebut un gran nombre de connexions que han posat la base amb petites sol·licituds, no n'hi haurà prou amb desconnectar la connexió del Bouncer, també haureu de completar les sol·licituds que s'estan executant a la base de dades.
Això s'ha corregit i el problema encara no s'ha fusionat amb Bouncer aigües amunt.
I així vam arribar a la conclusió que necessitem el nostre propi agrupador de connexions, que estarà desenvolupat, pegat, en el qual serà possible solucionar ràpidament els problemes i que, per descomptat, ha de ser multifil.
Vam establir el multithreading com a tasca principal. Hem de ser capaços de gestionar bé l'onada de connexions TLS entrants.
Per fer-ho, vam haver de desenvolupar una biblioteca separada anomenada Machinarium, que està dissenyada per descriure els estats de la màquina d'una connexió de xarxa com a codi de sèrie. Si mireu el codi font de libpq, veureu trucades força complexes que us poden retornar un resultat i dir: "Truca'm una mica més tard. Ara mateix tinc IO de moment, però quan passa l'IO, tinc una càrrega al processador. I aquest és un esquema multinivell. La interacció amb la xarxa la descriu normalment una màquina d'estats. Moltes regles com "Si anteriorment he rebut una capçalera de paquet de mida N, ara estic esperant N bytes", "Si he enviat un paquet SYNC, ara estic esperant un paquet amb metadades del resultat". El resultat és un codi contraintuïtiu força difícil, com si el laberint es convertís en una exploració de línies. Hem fet que en lloc d'una màquina d'estats, el programador descrigui la ruta d'interacció principal en forma de codi imperatiu ordinari. Només en aquest codi imperatiu, cal inserir llocs on s'ha d'interrompre la seqüència d'execució esperant dades de la xarxa, passant el context d'execució a una altra corrutina (fil verd). Aquest enfocament és similar al fet que anotem el camí més esperat al laberint en una fila i, després, hi afegim branques.
Com a resultat, tenim un fil que fa que un TCP accepti i round-robin passa una connexió TPC a molts treballadors.
En aquest cas, cada connexió de client sempre s'executa en un processador. I això us permet fer-lo compatible amb la memòria cau.
I, a més, hem millorat lleugerament la col·lecció de paquets petits en un paquet gran per tal de descarregar la pila TCP del sistema.
A més, hem millorat l'agrupació transaccional en el sentit que Odyssey, quan està configurat, pot enviar CANCEL·LA i ROLLBACK en cas d'error de connexió a la xarxa, és a dir, si ningú no està esperant la sol·licitud, Odyssey dirà a la base de dades que no ho intenti complir. la petició que pot malbaratar recursos preciosos.
I sempre que és possible, mantenim les connexions amb el mateix client. Això evita haver de reinstal·lar app_name_add_host. Si és possible, no tenim un restabliment addicional dels paràmetres necessaris per al diagnòstic.
Treballem en els interessos de Yandex.Cloud. I si utilitzeu PostgreSQL gestionat i teniu instal·lat un agrupador de connexions, podeu crear una rèplica lògica cap a l'exterior, és a dir, deixar-nos si voleu, mitjançant la rèplica lògica. Bouncer fora del flux de replicació lògica no donarà.
Aquest és un exemple de configuració de la replicació lògica.
A més, tenim suport per a la replicació física cap a l'exterior. Al núvol, és clar, és impossible, perquè aleshores el clúster us donarà massa informació sobre si mateix. Però a les vostres instal·lacions, si necessiteu una rèplica física mitjançant un agrupador de connexions a Odyssey, és possible.
Odyssey té un monitoratge totalment compatible amb PgBouncer. Tenim la mateixa consola que executa gairebé totes les mateixes ordres. Si falta alguna cosa, envieu una sol·licitud d'extracció, o almenys un problema a GitHub, completarem les ordres necessàries. Però ja tenim la funcionalitat principal de la consola PgBouncer.
I, per descomptat, tenim errors de reenviament. Tornarem l'error informat per la base. Obtindreu informació per què no esteu a la base, no només que no hi esteu.
Aquesta funció està desactivada en cas que necessiteu una compatibilitat al 100% amb PgBouncer. Ens podem comportar com Bouncer, per si de cas.
Desenvolupament
Unes paraules sobre el codi font Odyssey.
Per exemple, hi ha ordres "Pausa / Reprèn". Normalment s'utilitzen per actualitzar la base de dades. Si necessiteu actualitzar Postgres, podeu aturar-lo al agrupador de connexions, fer una pg_upgrade i reprendre. I des del costat del client, semblarà que la base de dades s'està alentint. Aquesta funcionalitat ens la van oferir persones de la comunitat. Encara no ha mort, però aviat tot serà. (ja mort)
-ja mort
A més, una de les novetats de PgBouncer és el suport d'autenticació SCRAM, que també ens va oferir una persona que no treballa a Yandex.Cloud. Tots dos tenen una funcionalitat complexa i importants.
Per tant, m'agradaria dir-vos de què està feta Odyssey, per si també voleu escriure algun codi ara.
Teniu la base original Odyssey, que es basa en dues biblioteques principals. La biblioteca Kiwi és una implementació del protocol de missatges Postgres. És a dir, el proto 3 natiu de Postgres és missatges estàndard que les interfícies i els backends poden intercanviar. Estan implementats a la biblioteca Kiwi.
La biblioteca Machinarium és una biblioteca d'implementació de fils. Un petit fragment d'aquest Machinarium està escrit en assemblador. Però no et preocupis, només hi ha 15 línies.
Arquitectura Odissea. Hi ha una màquina principal que executa corrutines. Aquesta màquina implementa l'acceptació de connexions TCP entrants i la distribució entre els treballadors.
Dins d'un treballador, pot treballar un gestor de diversos clients. I també al fil principal, la consola i el processament de tasques crone per eliminar connexions que ja no són necessàries a la piscina estan girant.
Odyssey es prova amb la suite de proves estàndard de Postgres. Acabem d'executar la comprovació d'instal·lació mitjançant Bouncer i mitjançant Odyssey, obtenim un div nul. Hi ha diverses proves relacionades amb el format de la data que fallen exactament igual a Bouncer i Odyssey.
A més, hi ha molts conductors que tenen les seves pròpies proves. I fem servir les seves proves per provar Odyssey.
A més, a causa de la nostra configuració en cascada, hem de provar diferents paquets: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey per tal d'assegurar-nos que si Odyssey es troba en alguna de les parts de la cascada, també funciona com a esperat.
Rake
Utilitzem Odyssey en la producció. I no seria just que digués que tot funciona. No, és a dir, sí, però no sempre. Per exemple, a la producció tot va funcionar, després van venir els nostres amics de PostgreSQL Professional i van dir que teníem una fuga de memòria. Realment ho eren, els hem arreglat. Però era senzill.
Aleshores vam trobar que l'agrupador de connexions té connexions TLS entrants i connexions TLS sortints. I les connexions necessiten certificats de client i certificats de servidor.
Els certificats de servidor Bouncer i Odyssey són relegits per pcache, però els certificats de client no cal que es rellegin des de pcache, perquè la nostra escalable Odyssey es basa finalment en el rendiment del sistema de llegir aquest certificat. Això ens va sorprendre, perquè no va descansar immediatament. Al principi es va escalar de manera lineal i, després de 20 connexions simultànies entrants, aquest problema es va manifestar.
El mètode d'autenticació connectable és la capacitat d'autenticar-se amb eines de lunux integrades. A PgBouncer, s'implementa de tal manera que hi ha un fil separat que espera una resposta de PAM i hi ha un fil principal de PgBouncer que serveix a la connexió actual i els pot demanar que visquin al fil PAM.
No ho vam implementar per una raó senzilla. Tenim molts corrents. Per què ho necessitem?
Com a resultat, això pot crear problemes perquè si teniu autenticació PAM i autenticació no PAM, una gran onada d'autenticació PAM pot retardar significativament l'autenticació no PAM. És una d'aquestes coses que no hem arreglat. Però si voleu arreglar-ho, podeu fer-ho.
Un altre rasclet va ser el fet que tenim un fil que accepta totes les connexions entrants. I després es transfereixen al grup de treballadors, on es farà l'encaix de mans TLS.
Com a resultat, si teniu una onada coherent de 20 connexions de xarxa, totes s'acceptaran. I al costat del client, libpq començarà a informar de temps d'espera. De manera predeterminada, hi ha 000 segons.
Si no poden entrar tots a la base al mateix temps, no poden entrar a la base, perquè tot això es pot cobrir amb un nou intent no exponencial.
Hem acabat copiant l'esquema PgBouncer aquí per tal de poder limitar el nombre de connexions TCP que acceptem.
Si veiem que acceptem connexions, però al final no tenen temps per encaixar les mans, les posem a la cua perquè no consumeixin recursos de CPU. Això fa que no es realitzi una encaixada de mans simultània per a totes les connexions que han arribat. Però almenys algú entrarà a la base de dades, encara que la càrrega sigui prou forta.
Full de ruta
Què t'agradaria veure en el futur a Odissea? Què estem preparats per desenvolupar-nos i què esperem de la comunitat?
Per a l'agost de 2019.
Aquest és el que semblava el full de ruta de l'Odissea a l'agost:
- Volíem l'autenticació SCRAM i PAM.
- Volíem reenviar les sol·licituds de lectura al mode d'espera.
- M'agradaria reiniciar en línia.
- I la possibilitat de fer una pausa al servidor.
La meitat d'aquest full de ruta està fet, i no nosaltres. I això és bo. Així que parlem del que queda i afegim més.
? Tenim rèpliques que, sense atendre les peticions, simplement escalfaran l'aire. Necessitem que proporcionin failover i commutació. En cas de problemes en algun dels centres de dades, m'agradaria ocupar-los amb una feina útil. Com que no podem configurar els mateixos processadors centrals, la mateixa memòria d'una manera diferent, perquè la replicació no funcionarà d'una altra manera.
En principi, a Postgres, a partir de 10, és possible especificar session_attrs en connectar-se. Podeu llistar tots els amfitrions de la base de dades de la connexió i dir per què aneu a la base de dades: escriviu o només lectura. I el propi conductor triarà el primer amfitrió de la llista que més li agradi, que compleix els requisits de session_attrs.
Però el problema d'aquest enfocament és que no controla el retard de replicació. És possible que tingueu algun tipus de rèplica que estigui enrere per un temps inacceptable per al vostre servei. Per tal d'executar amb totes les funcions de sol·licituds de lectura en una rèplica, de fet, hem de donar suport a Odyssey amb la capacitat de no funcionar quan és impossible de llegir.
Odyssey ha d'anar a la base de dades de tant en tant i demanar la distància de rèplica des de la primària. I si ha arribat al límit, no deixeu que entrin noves sol·licituds a la base de dades, digueu al client que heu de reiniciar les connexions i, possiblement, seleccioneu un altre host per executar les peticions. Això permetrà que la base de dades recuperi ràpidament el retard de replicació i torni de nou per respondre amb una consulta.
És difícil anomenar les dates d'implementació, perquè és de codi obert. Però, espero, no 2,5 anys com els companys de PgBouncer. Aquesta és la funció que m'agradaria veure a Odyssey.
. Ara podeu crear una declaració preparada de dues maneres. Primer, podeu executar una ordre SQL, és a dir, "preparat". Per entendre aquesta ordre SQL, hem d'aprendre a entendre SQL al costat de Bouncer. Això seria excessiu perquè és excessiu, ja que necessitem l'analitzador sencer. No podem analitzar totes les ordres SQL.
Però hi ha una declaració preparada a nivell de protocol de missatge a proto3. I aquest és el lloc on la informació que s'està creant la declaració preparada arriba de forma estructurada. I podríem donar suport a la comprensió que en alguna connexió de servidor el client va demanar que creés declaracions preparades. I encara que la transacció estigui tancada, encara hem de mantenir el servidor i el client connectats.
Però aquí hi ha una discrepància en el diàleg, perquè algú diu que cal entendre quines declaracions preparades va crear el client i compartir la connexió al servidor entre tots els clients que van crear aquesta connexió al servidor, és a dir, qui va crear aquesta declaració preparada.
Andres Freund va dir que si us va acudir un client que ja havia creat una declaració preparada en una altra connexió de servidor, creeu-la per a ell. Però sembla una mica incorrecte executar consultes a la base de dades en lloc del client, però des del punt de vista d'un desenvolupador que escriu un protocol per interactuar amb la base de dades, seria convenient que se li donés simplement una connexió de xarxa. que té una sol·licitud tan preparada.
I una característica més que hem d'implementar. Ara tenim monitorització compatible amb PgBouncer. Podem retornar el temps mitjà d'execució de la consulta. Però el temps mitjà és la temperatura mitjana a l'hospital: algú té fred, algú té calor; de mitjana, tothom està sans. No és cert.
Hem d'implementar suport per a percentils, la qual cosa indicaria que hi ha sol·licituds lentes que consumeixen recursos i faria més acceptable el seguiment.
El més important és que vull la versió 1.0 (la versió 1.1 ja s'ha publicat). El fet és que ara Odyssey està a la versió 1.0rc, és a dir, candidat al llançament. I tot el rastell que vaig enumerar es va arreglar exactament amb la mateixa versió, excepte la fuga de memòria.
Què significarà per a nosaltres la versió 1.0? Estem desplegant l'Odissea a les nostres bases. Ja s'està executant a les nostres bases de dades, però quan arriba al punt de les 1 de sol·licituds per segon, podem dir que es tracta d'una versió de llançament i aquesta és una versió que es pot anomenar 000.
Diverses persones de la comunitat han demanat més pausa i SCRAM a la versió 1.0. Però això significarà que haurem de llançar la següent versió a producció, perquè encara no s'han fusionat ni SCRAM ni la pausa. Però, molt probablement, aquest problema es resoldrà amb força rapidesa.
Estic esperant la teva sol·licitud d'extracció. I també m'agradaria saber quins problemes teniu amb Bouncer. Parlem d'ells. Potser podem implementar algunes funcions que necessiteu.
Això conclou la meva part, m'agradaria saber de vosaltres. Gràcies!
Les vostres preguntes
Si poso el meu nom_aplicació, es passarà correctament, inclòs en l'agrupació de transaccions a Odyssey?
Odissea o Bouncer?
A l'Odissea. El Bouncer és llançat.
Farem un conjunt.
I si la meva connexió real salta sobre altres connexions, es transmetrà?
Farem un conjunt de tots els paràmetres que s'enumeren. No puc saber si nom_aplicació està en aquesta llista. Sembla que el va veure allà. Establirem tots els mateixos paràmetres. Amb una sol·licitud, el conjunt farà tot el que va instal·lar el client durant l'inici.
Gràcies Andrei pel reportatge! Bon reportatge! M'alegro que Odyssey es desenvolupi cada minut més ràpidament. M'agradaria seguir igual. Ja us hem demanat que tingueu una connexió de fonts múltiples de dades perquè l'Odyssey pugui connectar-se a diferents bases de dades alhora, és a dir, al mestre esclau, i després connectar-se automàticament al nou mestre després d'una migració per error.
Sí, em sembla que recordo aquella discussió. Ara hi ha diversos magatzems. Però no hi ha cap canvi entre ells. Per la nostra banda, hem de consultar al servidor que encara està viu i entendre que s'ha produït una fallada, que cridarà a pg_recovery. Tinc una manera estàndard d'entendre que no vam venir al mestre. I hem d'entendre d'alguna manera dels errors o com? És a dir, la idea és interessant, s'està discutint. Escriu més comentaris. Si teniu mans treballadores que coneixen C, això és generalment meravellós.
El tema de l'escala entre rèpliques també ens interessa, perquè volem que l'adopció de clústers replicats sigui el més senzilla possible per als desenvolupadors d'aplicacions. Però aquí voldria més comentaris, és a dir, com fer-ho, com fer-ho bé.
La pregunta també és sobre les rèpliques. Resulta que tens un mestre i diverses rèpliques. I és evident que van a la rèplica menys sovint que al mestre per connexions, perquè poden tenir una diferència. Vas dir que la diferència de dades pot ser tal que el teu negoci no et satisfarà i que no hi aniràs fins que no es repliqui. Al mateix temps, si no hi vau anar durant molt de temps i després vau començar a anar-hi, les dades que necessiteu no estaran disponibles immediatament. És a dir, si anem constantment al mestre, llavors la memòria cau s'escalfa allà i la memòria cau queda una mica endarrerida a la rèplica.
Sí, és veritat. No hi haurà blocs de dades a pcache que vulgueu, a la memòria cau real no hi haurà informació sobre les taules que vulgueu, no hi haurà consultes analitzades als plans, res de res.
I quan teniu algun tipus de clúster i hi afegiu una rèplica nova, aleshores, mentre comença, tot està dolent, és a dir, fa créixer la seva memòria cau.
Vaig entendre la idea. L'enfocament correcte seria executar primer un petit percentatge de consultes a la rèplica, cosa que escalfaria la memòria cau. A grans trets, tenim la condició que no hem d'estar a més de 10 segons del mestre. I aquesta condició no s'ha d'incloure en una sola onada, sinó sense problemes per a alguns clients.
Sí, augmenta de pes.
Aquesta és una bona idea. Però primer heu d'implementar aquest tancament. Primer hem d'apagar-lo i després pensarem com s'encén. Aquesta és una característica fantàstica per activar-se sense problemes.
nginx té aquesta opció slowly start al clúster per al servidor. I a poc a poc va augmentant la càrrega.
Sí, genial idea, ho provarem quan arribem a això.
Font: www.habr.com