No seu informe, Andrey Borodin contarache como tiveron en conta a experiencia de escalar PgBouncer á hora de deseñar o agrupador de conexións , mentres o lanzaron á produción. Ademais, comentaremos cales son as funcións do tirador que nos gustaría ver nas novas versións: é importante para nós non só satisfacer as nosas necesidades, senón desenvolver a comunidade de usuarios. .
Vídeo:
Ola a todos! Chámome Andrés.
En Yandex, desenvolvo bases de datos de código aberto. E hoxe temos un tema sobre as conexións do pool de conexións.
Se sabes como chamar ao pool de conexións en ruso, dime. Realmente quero atopar un bo termo técnico que debería establecerse na literatura técnica.
O tema é bastante complicado, porque en moitas bases de datos o agrupador de conexións está incorporado e nin sequera necesitas saber diso. Por suposto, hai algunhas opcións en todas partes, pero en Postgres non funciona así. E paralelamente (en HighLoad++ 2019) hai un informe de Nikolai Samokhvalov sobre a configuración de consultas en Postgres. E, segundo teño entendido, chegou aquí xente que xa tiña configuradas as súas consultas perfectamente, e trátase de persoas que se enfrontan a problemas máis raros do sistema relacionados coa rede e coa utilización dos recursos. E nalgúns lugares podería ser bastante difícil no sentido de que os problemas non son obvios.
Yandex ten Postgres. Moitos servizos de Yandex viven en Yandex.Cloud. E temos varios petabytes de datos que xeran polo menos un millón de solicitudes por segundo en Postgres.
E proporcionamos un clúster bastante estándar para todos os servizos: este é o nodo principal principal do nodo, as dúas réplicas habituais (sincrónica e asincrónica), copia de seguridade, escalado das solicitudes de lectura na réplica.
Cada nodo do clúster é Postgres, no que, ademais de Postgres e os sistemas de monitorización, tamén se instala un agrupador de conexións. Conexión pooler úsase para cercado e para o seu propósito principal.
Cal é o propósito principal do pool de conexións?
Postgres adopta un modelo de proceso cando traballa cunha base de datos. Isto significa que unha conexión é un proceso, un backend de Postgres. E neste backend hai moitos cachés diferentes, que son bastante caros para facer diferentes para diferentes conexións.
Ademais, o código de Postgres ten unha matriz chamada procArray. Contén datos básicos sobre as conexións de rede. E case todos os algoritmos de procesamento de procArray teñen unha complexidade lineal; execútanse por toda a matriz de conexións de rede. É un ciclo bastante rápido, pero con máis conexións de rede entrantes as cousas son un pouco máis caras. E cando as cousas se encarecen un pouco, podes acabar pagando un prezo moi alto por moitas conexións de rede.
Hai 3 enfoques posibles:
- No lado da aplicación.
- No lado da base de datos.
- E entre, é dicir, todo tipo de combinacións.
Desafortunadamente, o pool incorporado está actualmente en desenvolvemento. Os nosos amigos de PostgreSQL Professional fan isto principalmente. Cando aparecerá é difícil de prever. E de feito, temos dúas solucións para que o arquitecto elixa. Estes son un grupo de aplicacións e un grupo de proxy.
A piscina do lado da aplicación é o xeito máis sinxelo. E case todos os controladores de clientes ofrécenche un xeito: presentar millóns das túas conexións en código como varias ducias de conexións á base de datos.
O problema que xorde é que nun momento determinado quere escalar o backend, quere implantalo en moitas máquinas virtuais.
Entón dás conta de que tes varias zonas de dispoñibilidade máis, varios centros de datos. E o enfoque de posta en común do lado do cliente leva a un número maior. As grandes son unhas 10 conexións. Este é o bordo que pode funcionar normalmente.
Se falamos de proxy poolers, entón hai dous poolers que poden facer moitas cousas. Non son só poolers. Son poolers + funcionalidade máis interesante. Isto и .
Pero, desafortunadamente, non todos necesitan esta funcionalidade adicional. E leva ao feito de que os agrupadores só admiten a agrupación de sesións, é dicir, un cliente entrante, un cliente saínte á base de datos.
Isto non é moi axeitado para os nosos propósitos, polo que usamos PgBouncer, que implementa a agrupación de transaccións, é dicir, as conexións do servidor coinciden coas conexións do cliente só durante a duración da transacción.
E na nosa carga de traballo, isto é certo. Pero hai algúns problemas.
Os problemas comezan cando queres diagnosticar unha sesión, porque todas as túas conexións entrantes son locais. Todos viñeron cun loopback e, dalgún xeito, faise difícil rastrexar a sesión.
Por suposto que podes usar nome_aplicación_engadir_host. Esta é unha forma no lado de Bouncer de engadir un enderezo IP a application_name. Pero nome_aplicación establécese mediante unha conexión adicional.
Neste gráfico, onde a liña amarela son as solicitudes reais, e onde a azul son as solicitudes que voan á base de datos. E esta diferenza é precisamente a instalación de nome_aplicación, que só se necesita para o rastrexo, pero non é para nada gratuíto.
Ademais, en Bouncer non pode limitar un grupo, é dicir, o número de conexións de base de datos por usuario específico, por base de datos específica.
A que leva isto? Tes un servizo cargado escrito en C++ e nalgún lugar preto dun pequeno servizo nun nodo que non fai nada terrible coa base de datos, pero o seu controlador vólvese tolo. Abre 20 conexións e todo o demais esperará. Incluso o teu código é normal.
Por suposto, escribimos un pequeno parche para Bouncer que engadiu esta configuración, é dicir, limitaba os clientes ao grupo.
Sería posible facelo no lado de Postgres, é dicir, limitar os roles na base de datos polo número de conexións.
Pero entón perdes a capacidade de entender por que non tes conexións co servidor. PgBouncer non arroxa un erro de conexión, sempre devolve a mesma información. E non podes entender: quizais o teu contrasinal cambiou, quizais a base de datos só se perda, quizais algo estea mal. Pero non hai diagnóstico. Se non se pode establecer unha sesión, non saberás por que non se pode establecer.
Nun momento determinado, miras os gráficos da aplicación e ves que a aplicación non funciona.
Mira a parte superior e mira que Bouncer ten un só fío. Este é un punto de inflexión na vida do servizo. Tes conta de que te estabas preparando para escalar a base de datos nun ano e medio e necesitas escalar o pooler.
Chegamos á conclusión de que necesitamos máis PgBouncers.
Bouncer foi un pouco remendado.
E fixérono para que se puidesen criar varios Bouncers reutilizando o porto TCP. E o sistema operativo transfire automaticamente as conexións TCP entrantes entre elas mediante round-robin.
Isto é transparente para os clientes, o que significa que parece que tes un Bouncer, pero tes unha fragmentación de conexións inactivas entre Bouncers en execución.
E nun momento determinado podes notar que estes 3 Bouncers comen cada un o seu núcleo ao 100%. Necesitas bastantes Bouncers. Por que?
Porque tes TLS. Tes unha conexión cifrada. E se comparas Postgres con e sen TLS, descubrirás que o número de conexións establecidas cae en case dúas ordes de magnitude co cifrado activado, porque o protocolo de conexión TLS consome recursos da CPU.
E na parte superior podes ver bastantes funcións criptográficas que se executan cando hai unha onda de conexións entrantes. Dado que o noso principal pode cambiar entre as zonas de dispoñibilidade, unha onda de conexións entrantes é unha situación bastante típica. É dicir, por algún motivo o antigo primario non estaba dispoñible, toda a carga foi enviada a outro centro de datos. Todos virán a saudar a TLS ao mesmo tempo.
E un gran número de apretón de mans TLS xa non pode saudar a Bouncer, pero apertará a súa gorxa. Debido ao tempo de espera, a onda de conexións entrantes pode quedar sen amortiguación. Se tentas de novo á base sen retroceso exponencial, non chegarán unha e outra vez nunha onda coherente.
Aquí tes un exemplo de 16 PgBouncers que cargan 16 núcleos ao 100%.
Chegamos á fervenza PgBouncer. Esta é a mellor configuración que se pode conseguir na nosa carga con Bouncer. Os nosos Bouncer externos utilízanse para o enlace TCP e os Bouncer internos para a posta en común real, para non fragmentar demasiado as conexións externas.
Nesta configuración, é posible un reinicio suave. Podes reiniciar todos estes 18 Bouncers un por un. Pero manter tal configuración é bastante difícil. Os administradores de sistemas, DevOps e as persoas que son realmente responsables deste servidor non estarán moi satisfeitos con este arranxo.
Parece que todas as nosas melloras poden ser promovidas a código aberto, pero Bouncer non está moi ben apoiado. Por exemplo, a capacidade de executar varios PgBouncers nun porto comprometeuse hai un mes. Hai varios anos houbo unha solicitude de extracción con esta función.
Ou un exemplo máis. En Postgres, pode cancelar unha solicitude en curso enviando o segredo a unha conexión diferente sen unha autenticación innecesaria. Pero algúns clientes simplemente envían un restablecemento TCP, é dicir, rompen a conexión de rede. Que fará Bouncer? Non fará nada. Seguirá executando a solicitude. Se recibiu un gran número de conexións que crearon unha base de datos con pequenas solicitudes, simplemente desconectar a conexión de Bouncer non será suficiente; tamén debe completar as solicitudes que se están executando na base de datos.
Fixouse un parche e este problema aínda non se fusionou coa auga ascendente de Bouncer.
E así chegamos á conclusión de que necesitamos o noso propio agrupador de conexións, que será desenvolvido, parcheado, no que os problemas poidan ser corrixidos rapidamente e que, por suposto, debe ser multifío.
Definimos o multithreading como tarefa principal. Debemos ser capaces de manexar ben a onda de conexións TLS entrantes.
Para iso, tivemos que desenvolver unha biblioteca separada chamada Machinarium, que está deseñada para describir os estados da máquina dunha conexión de rede como código secuencial. Se miras o código fonte de libpq, verás unhas chamadas bastante complexas que che poden devolver un resultado e dicir: "Chámame máis tarde. Agora mesmo teño IO por agora, pero cando o IO desapareza, terei unha carga no procesador. E este é un esquema de varios niveis. A comunicación de rede é normalmente descrita por unha máquina de estado. Moitas regras como "Se anteriormente recibín un encabezado de paquete de tamaño N, agora estou esperando por N bytes", "Se enviei un paquete SYNC, agora estou esperando por un paquete con metadatos de resultado". O resultado é un código bastante difícil e contraintuitivo, coma se o labirinto fose convertido en exploración de liña. Fixémolo para que, en lugar dunha máquina de estado, o programador describa o camiño principal de interacción en forma de código imperativo común. É só que neste código imperativo cómpre inserir lugares nos que se debe interromper a secuencia de execución esperando os datos da rede, pasando o contexto de execución a outra corrutina (fío verde). Este enfoque é semellante ao feito de que anotamos o camiño máis esperado no labirinto seguido e despois engadimos ramas.
Como resultado, temos un fío que acepta TCP e round-robin pasa a conexión TPC a moitos traballadores.
Neste caso, cada conexión de cliente sempre se executa nun procesador. E isto permíteche facelo compatible coa memoria caché.
Ademais, melloramos lixeiramente a colección de pequenos paquetes nun paquete grande para aliviar a pila TCP do sistema.
Ademais, melloramos a agrupación transaccional no sentido de que Odyssey, cando está configurado, pode enviar CANCEL e ROLLBACK en caso de falla de conexión á rede, é dicir, se ninguén está agardando unha solicitude, Odyssey dirá á base de datos que non intente facelo. cumprir a solicitude que pode malgastar recursos preciosos.
E sempre que sexa posible, mantemos conexións co mesmo cliente. Isto evita ter que reinstalar application_name_add_host. Se isto é posible, non temos que restablecer adicionalmente os parámetros necesarios para o diagnóstico.
Traballamos nos intereses de Yandex.Cloud. E se usas PostgreSQL xestionado e tes instalado un agrupador de conexións, podes crear unha replicación lóxica cara a fóra, é dicir, deixarnos, se queres, usando a replicación lóxica. Bouncer non liberará o fluxo de replicación lóxica fóra.
Este é un exemplo de configuración da replicación lóxica.
Ademais, temos soporte para a replicación física cara a fóra. Na nube, por suposto, isto é imposible, porque entón o clúster darache demasiada información sobre si mesmo. Pero nas túas instalacións, se necesitas replicación física a través do agrupador de conexións en Odyssey, isto é posible.
Odyssey ten un seguimento totalmente compatible con PgBouncer. Temos a mesma consola que executa case todos os mesmos comandos. Se falta algo, envía unha solicitude de extracción, ou polo menos un problema en GitHub, e completaremos os comandos necesarios. Pero xa temos a funcionalidade principal da consola PgBouncer.
E, por suposto, temos o reenvío de erros. Devolveremos o erro informado pola base de datos. Recibirás información sobre por que non estás incluído na base de datos, e non só de que non estás incluído nela.
Esta función está desactivada no caso de que necesites compatibilidade ao 100 % con PgBouncer. Podemos comportarnos do mesmo xeito que Bouncer, só para estar seguros.
Desenvolvemento
Algunhas palabras sobre o código fonte Odyssey.
Por exemplo, hai comandos "Pausa / Reanudar". Normalmente úsanse para actualizar a base de datos. Se precisas actualizar Postgres, podes pausar no conxunto de conexións, facer pg_upgrade e, a continuación, continuar. E desde o lado do cliente, parecerá que a base de datos simplemente estivese a ralentizar. Esta funcionalidade foinos presentada por persoas da comunidade. Aínda non está conxelada, pero pronto estará todo. (Xa conxelado)
- xa conxelado
Ademais, unha das novas funcións de PgBouncer é o soporte para a autenticación SCRAM, que tamén nos trouxo unha persoa que non traballa en Yandex.Cloud. Ambos teñen unha funcionalidade complexa e importante.
Por iso, gustaríame dicirvos de que está feita Odisea, por se tamén queredes escribir un pequeno código agora.
Tes a base de fontes Odyssey, que depende de dúas bibliotecas principais. A biblioteca Kiwi é unha implementación do protocolo de mensaxes Postgres. É dicir, o proto 3 nativo de Postgres é mensaxes estándar que os front-ends e os back-ends poden intercambiar. Están implementados na biblioteca Kiwi.
A biblioteca Machinarium é unha biblioteca de implementación de fíos. Un pequeno fragmento deste Machinarium está escrito en linguaxe ensamblador. Pero non te alarmes, só hai 15 liñas.
Odisea arquitectura. Hai unha máquina principal na que se están executando as corrutinas. Esta máquina implementa aceptar conexións TCP entrantes e distribuílas entre os traballadores.
Un manejador de varios clientes pode traballar dentro dun mesmo traballador. O fío principal tamén executa a consola e o procesamento de tarefas crone para eliminar conexións que xa non son necesarias no pool.
Odyssey é probado usando a suite de probas estándar de Postgres. Acabamos de executar a comprobación de instalación a través de Bouncer e a través de Odyssey, obtemos un div nulo. Hai varias probas relacionadas co formato de data que non pasan exactamente o mesmo en Bouncer e en Odyssey.
Ademais, hai moitos condutores que teñen as súas propias probas. E usamos as súas probas para probar a Odisea.
Ademais, debido á nosa configuración en cascada, temos que probar varios paquetes: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey para estar seguros de que se Odyssey acabou nalgunha das partes da cascada, tamén aínda funciona. como esperamos.
Rake
Usamos Odyssey na produción. E non sería xusto que dixese que todo funciona. Non, é dicir, si, pero non sempre. Por exemplo, na produción todo funcionou, entón os nosos amigos de PostgreSQL Professional viñeron e dixeron que tiñamos unha fuga de memoria. Realmente o foron, corrixímolos. Pero era sinxelo.
Despois descubrimos que o agrupador de conexións ten conexións TLS de entrada e conexións TLS de saída. E as conexións requiren certificados de cliente e certificados de servidor.
Os certificados do servidor Bouncer e Odyssey son reledos polo seu pcache, pero os certificados do cliente non precisan ser reledos desde pcache, porque o noso escalable Odyssey atópase finalmente co rendemento do sistema de ler este certificado. Isto foinos unha sorpresa, porque non tardou en resistir. Nun principio escalou de forma lineal, pero despois de 20 conexións simultáneas entrantes este problema mostrouse.
O método de autenticación conectable é a capacidade de autenticarse usando ferramentas integradas de Lunux. En PgBouncer está implementado de tal xeito que hai un fío separado para esperar unha resposta de PAM e hai un fío principal de PgBouncer que dá servizo á conexión actual e pode pedirlles que vivan no fío PAM.
Non implementamos isto por un simple motivo. Temos moitos fíos. Por que necesitamos isto?
En última instancia, isto pode crear problemas xa que se tes unha autenticación PAM e unha autenticación non PAM, unha gran onda de autenticación PAM pode atrasar significativamente a autenticación non PAM. Esta é unha desas cousas que non solucionamos. Pero se queres solucionalo, podes facelo.
Outro rake foi que temos un fío que acepta todas as conexións entrantes. E despois transfírense ao grupo de traballadores, onde terá lugar o apretón de mans TLS.
En definitiva, se tes unha onda coherente de 20 conexións de rede, todas elas serán aceptadas. E no lado do cliente, libpq comezará a informar de tempo de espera. Por defecto, parece que son 000 segundos.
Se todos eles non poden entrar na base de datos ao mesmo tempo, entón non poden entrar na base de datos, porque todo isto pode cubrirse mediante un reintento non exponencial.
Chegamos á conclusión de que copiamos o esquema de PgBouncer aquí co feito de que limitamos o número de conexións TCP ás que aceptamos.
Se vemos que estamos aceptando conexións, pero finalmente non teñen tempo para estreitar as mans, poñémolas nunha cola para que non desperdicien recursos da CPU. Isto leva ao feito de que non se realice un apretón de mans simultáneo para todas as conexións que chegaron. Pero polo menos alguén entrará na base de datos, aínda que a carga sexa bastante pesada.
Roadmap
Que che gustaría ver no futuro en Odisea? Que estamos preparados para desenvolvernos e que esperamos da comunidade?
A partir de agosto de 2019.
Así era a folla de ruta de Odyssey en agosto:
- Queriamos autenticación SCRAM e PAM.
- Queriamos reenviar as solicitudes de lectura ao modo de espera.
- Gustaríame un reinicio en liña.
- E a posibilidade de facer unha pausa no servidor.
A metade desta folla de ruta foi completada, e non por nós. E isto é bo. Entón, imos discutir o que queda e engadir máis.
? Temos réplicas que simplemente quentarán o aire sen executar solicitudes. Precisamos deles para proporcionar conmutación e conmutación. En caso de problemas nalgún dos centros de datos, gustaríame ocupalos cun traballo útil. Porque non podemos configurar os mesmos procesadores centrais, a mesma memoria de forma diferente, porque se non a replicación non funcionará.
En principio, en Postgres, a partir de 10, é posible especificar session_attrs ao conectarse. Podes enumerar todos os servidores de base de datos da conexión e dicir por que vas á base de datos: só escribir ou ler. E o propio condutor seleccionará o primeiro host da lista que máis lle guste, que cumpra os requisitos de session_attrs.
Pero o problema con este enfoque é que non controla o atraso de replicación. É posible que teñas algunha réplica que quedou atrás durante un tempo inaceptable para o teu servizo. Para permitir a execución completa de consultas de lectura nunha réplica, esencialmente necesitamos admitir a capacidade de Odyssey para non executarse cando non se pode ler.
Odyssey debe ir á base de datos de cando en vez e pedir a distancia de replicación do principal. E se alcanzou o valor límite, non permita novas solicitudes na base de datos, dille ao cliente que ten que reiniciar as conexións e, posiblemente, seleccione outro host para executar as solicitudes. Isto permitirá que a base de datos restaure rapidamente o atraso de replicación e regrese de novo para responder cunha solicitude.
É difícil dar un prazo de execución, porque é de código aberto. Pero, espero, non 2,5 anos como os meus compañeiros de PgBouncer. Esta é a función que me gustaría ver na Odisea.
. Agora podes crear unha declaración preparada de dúas formas. En primeiro lugar, pode executar o comando SQL, é dicir, "preparado". Para comprender este comando SQL, necesitamos aprender a entender o SQL no lado de Bouncer. Isto sería un exceso, porque é excesivo, xa que necesitamos todo o analizador. Non podemos analizar todos os comandos SQL.
Pero hai unha declaración preparada a nivel de protocolo de mensaxes en proto3. E este é o lugar no que a información que se está a crear unha declaración preparada chega de forma estruturada. E poderiamos apoiar a comprensión de que nalgunha conexión de servidor o cliente pediu crear declaracións preparadas. E aínda que a transacción estea pechada, aínda necesitamos manter a conectividade entre o servidor e o cliente.
Pero aquí xorde unha discrepancia no diálogo, porque alguén di que cómpre comprender que tipo de declaracións preparadas creou o cliente e compartir a conexión do servidor entre todos os clientes que crearon esta conexión do servidor, é dicir, quen creou tal declaración preparada.
Andres Freund dixo que se che chega un cliente que xa creou unha declaración preparada noutra conexión de servidor, créaa para el. Pero parece un pouco mal executar consultas na base de datos en lugar do cliente, pero desde o punto de vista do programador que escribe o protocolo para interactuar coa base de datos, sería conveniente que simplemente se lle dese unha conexión de rede na que hai unha consulta tan preparada.
E unha característica máis que debemos implementar. Agora temos monitorización compatible con PgBouncer. Podemos devolver o tempo medio de execución da consulta. Pero o tempo medio é a temperatura media no hospital: algúns están fríos, outros quentes; de media, todos están sans. Non é certo.
Necesitamos implementar soporte para percentiles que indicarían que hai consultas lentas que desperdician recursos e fan máis aceptable o seguimento.
O máis importante é que quero a versión 1.0 (a versión 1.1 xa foi lanzada). O caso é que Odyssey está agora na versión 1.0rc, é dicir, candidato á versión. E todos os problemas que enumerei foron solucionados exactamente coa mesma versión, excepto a fuga de memoria.
Que significará para nós a versión 1.0? Estamos a lanzar Odyssey ás nosas bases. Xa se está a executar nas nosas bases de datos, pero cando chega ao punto de 1 de solicitudes por segundo, podemos dicir que esta é a versión de lanzamento e esta é unha versión que se pode chamar 000.
Varias persoas da comunidade pediron que a versión 1.0 inclúa pausa e SCRAM. Pero isto significará que teremos que lanzar a próxima versión á produción, porque aínda non se eliminaron nin SCRAM nin pausa. Pero, o máis probable é que este problema se resolva con bastante rapidez.
Estou esperando a túa solicitude de extracción. Tamén me gustaría saber que problemas tes con Bouncer. Comentemos. Quizais poidamos implementar algunhas funcións que necesites.
Este é o final da miña parte, gustaríame escoitarte. Grazas!
preguntas
Se defino o meu propio nome_aplicación, reenviarase correctamente, incluso na agrupación de transaccións en Odyssey?
Odisea ou Bouncer?
Na Odisea. En Bouncer lánzase.
Faremos un conxunto.
E se a miña conexión real salta a outras conexións, transmitirase?
Faremos un conxunto de todos os parámetros que aparecen na lista. Non podo dicir se nome_aplicación está nesta lista. Creo que o vin alí. Estableceremos todos os mesmos parámetros. Cunha solicitude, o conxunto fará todo o que instalou o cliente durante o inicio.
Grazas, Andrey, pola reportaxe! Boa reportaxe! Alégrome de que Odyssey se desenvolva cada minuto máis e máis rápido. Quero seguir así. Xa lle pedimos que teña unha conexión de fontes de datos múltiple para que Odyssey poida conectarse a diferentes bases de datos simultaneamente, é dicir, un escravo mestre, e despois conectarse automaticamente a un novo mestre despois da conmutación por fallo.
Si, paréceme lembrar esta discusión. Agora hai varios almacéns. Pero non hai cambio entre eles. Pola nosa banda, debemos enquisar ao servidor que aínda está vivo e entender que se produciu unha falla, quen chamará a pg_recovery. Teño unha forma estándar de entender que non chegamos ao mestre. E debemos entender dalgún xeito dos erros ou que? É dicir, a idea é interesante, está a discutirse. Escribe máis comentarios. Se tes traballadores que coñecen C, é xenial.
O tema do escalado entre réplicas tamén nos interesa, porque queremos que a adopción de clústeres replicados sexa o máis sinxela posible para os desenvolvedores de aplicacións. Pero aquí gustaríame máis comentarios, é dicir, exactamente como facelo, como facelo ben.
A pregunta tamén é sobre as réplicas. Resulta que tes un mestre e varias réplicas. E está claro que van á réplica con menos frecuencia que ao mestre para as conexións, porque poden ter diferenzas. Dixeches que a diferenza nos datos pode ser tal que non satisfará o teu negocio e que non irás ata que non se replique. Ao mesmo tempo, se non foi alí durante moito tempo e despois comezou a ir, entón os datos necesarios non estarán dispoñibles inmediatamente. É dicir, se imos constantemente ao mestre, entón a caché alí quéntase, pero na réplica a caché queda un pouco atrasada.
Si é certo. O pcache non terá os bloques de datos que desexa, a caché real non terá información sobre as táboas que quere, os plans non terán consultas analizadas, non haberá nada.
E cando tes algún tipo de clúster e engades alí unha nova réplica, mentres comeza, todo está mal nel, é dicir, aumenta a súa caché.
Eu teño a idea. O enfoque correcto sería executar primeiro unha pequena porcentaxe de consultas na réplica, o que quentaría a caché. En liñas xerais, temos a condición de que debemos estar por detrás do mestre en non máis de 10 segundos. E esta condición non está incluída nunha onda, pero sen problemas para algúns clientes.
Si, aumenta o peso.
Esta é unha boa idea. Pero primeiro necesitamos implementar este peche. Primeiro necesitamos apagar e despois pensaremos como acender. Esta é unha excelente función para activala sen problemas.
Nginx ten esta opción slowly start nun clúster para o servidor. E aumenta gradualmente a carga.
Si, xenial idea, probarémolo cando o poñamos.
Fonte: www.habr.com