A tradución do artigo foi elaborada expresamente para o alumnado do curso . Interesado en desenvolverse nesta dirección? Convidámoste a , onde falamos polo miúdo do programa, características do formato en liña, competencias e perspectivas profesionais que agardan aos titulados despois da formación.
PostgreSQL e configuración de coherencia de escritura específica da conexión
En Compose, tratamos con moitas bases de datos, o que nos dá a oportunidade de familiarizarnos máis coas súas funcionalidades e carencias. A medida que aprendemos a amar as funcións das novas bases de datos, ás veces comezamos a pensar o bo que sería que características similares estivesen presentes nas ferramentas máis maduras coas que estivemos traballando durante moito tempo. Unha das novas funcións que quería ver en PostgreSQL era a coherencia de escritura configurable por conexión en todo o clúster. E como se ve, xa o temos, e hoxe queremos compartir con vós información de como podedes utilizalo.
Por que o necesito?
Como debe comportarse o clúster depende da súa aplicación. Tome, por exemplo, unha aplicación de pago de facturas. Necesitarás unha coherencia do XNUMX % en todo o clúster, polo que terás que activar as confirmacións síncronas para que a túa base de datos agarde a que se fagan todos os cambios. Non obstante, se a túa aplicación é unha rede social de rápido crecemento, probablemente preferirás unha resposta rápida máis que unha coherencia do XNUMX%. Para conseguilo, pode usar commits asíncronos no seu clúster.
Cumprir compromiso
Ten que facer compensacións entre a coherencia dos datos e o rendemento. PostgreSQL afástase da coherencia porque a configuración predeterminada é entón previsible e sen sorpresas inesperadas. Agora vexamos os compromisos.
Compensación 1: rendemento
Se o clúster PostgreSQL non require coherencia, pode executarse de forma asíncrona. A escritura realízase ao líder do clúster e as actualizacións enviaranse ás súas réplicas uns milisegundos máis tarde. Cando un clúster PostgreSQL require coherencia, debe executarse de forma sincronizada. A escritura farase ao líder do clúster, que enviará unha actualización ás réplicas e agardará a confirmación de que cada unha escribiu antes de enviar a confirmación ao cliente que iniciou a escritura de que tivo éxito. A diferenza práctica entre estes enfoques é que o método asíncrono require dous saltos de rede, mentres que o método síncrono require catro.
Compensación 2: coherencia
O resultado en caso de fracaso dun líder nestes dous enfoques tamén será diferente. Se o traballo realízase de forma asíncrona, se se produce tal erro, as réplicas non comprometerán todos os rexistros. Canto se perderá? Depende da propia aplicación e da eficacia da replicación. A replicación de composición evitará que unha réplica se converta nun líder se a cantidade de información nela é 1 MB menos que no líder, é dicir, se poderían perder ata 1 MB de rexistros durante a operación asíncrona.
Isto non ocorre no modo sincrónico. Se o líder falla, todas as réplicas actualízanse, xa que calquera escritura confirmada no líder debe confirmarse nas réplicas. Isto é a coherencia.
O comportamento sincrónico ten sentido nunha aplicación de facturación onde a coherencia ten unha clara vantaxe na compensación entre coherencia e rendemento. O máis importante para tal aplicación son os datos válidos. Pense agora nunha rede social na que a principal tarefa é manter a atención do usuario respondendo ás solicitudes o máis rápido posible. Neste caso, o rendemento con menos saltos de rede e menos espera para as confirmacións será unha prioridade. Non obstante, o compromiso entre rendemento e consistencia non é o único no que tes que pensar.
Intercambio 3: fallos
É moi importante comprender como se comporta un clúster durante un fallo. Considere unha situación na que fallan unha ou máis réplicas. Cando as confirmacións se procesan de forma asíncrona, o líder seguirá funcionando, é dicir, acepta e procesa as escrituras, sen esperar a que falten réplicas. Cando as réplicas regresan ao clúster, atópanse ao líder. Coa replicación síncrona, se as réplicas non responden, entón o líder non terá opción e seguirá esperando a confirmación da confirmación ata que a réplica volva ao clúster e poida aceptar e confirmar a escritura.
Unha conexión por transacción?
Cada aplicación necesita un tipo diferente de combinación de consistencia e rendemento. A non ser que, por suposto, sexa a nosa aplicación de pago de facturas, que imaxinamos que é completamente coherente, ou a nosa case efémera aplicación de redes sociais. En todos os demais casos, haberá momentos nos que algunhas operacións deben ser sincrónicas e outras asíncronas. Quizais non queiras que o sistema agarde ata que se comprometa unha mensaxe enviada ao chat, pero se se procesa un pago na mesma aplicación, terás que esperar.
Todas estas decisións, por suposto, son tomadas polo desenvolvedor da aplicación. Tomar as decisións correctas sobre cando utilizar cada enfoque axudarache a sacar o máximo proveito do teu clúster. É importante que o programador poida cambiar entre eles a nivel de SQL para conexións e transaccións.
Garantir o control na práctica
Por defecto, PostgreSQL proporciona coherencia. Isto está controlado polo parámetro do servidor synchronous_commit. Por defecto está en posición on, pero ten outras tres opcións: local, remote_write ou off.
Ao configurar o parámetro para off todos os commits sincrónicos detéñense, incluso no sistema local. O parámetro local especifica o modo síncrono para o sistema local, pero as escrituras nas réplicas realízanse de forma asíncrona. Remote_write vai aínda máis alá: as escrituras nas réplicas realízanse de forma asíncrona, pero devólvense cando a réplica aceptou a escritura pero non a escribiu no disco.
Considerando o abano de opcións dispoñibles, escollemos un comportamento e, tendo en conta que on – son gravacións sincrónicas, escolleremos nós local para commits asíncronos a través da rede, mentres que os commits locais se deixan sincrónicos.
Agora, dirémosche como configuralo nun momento, pero imaxina que o configuramos synchronous_commit в local para o servidor. Preguntámonos se era posible cambiar o parámetro synchronous_commit sobre a marcha, e resultou que non só é posible, hai incluso dúas formas de facelo. O primeiro é configurar a sesión da túa conexión do seguinte xeito:
SET SESSION synchronous_commit TO ON;
// Your writes go hereTodas as escrituras posteriores na sesión recoñecerán as escrituras nas réplicas antes de devolver un resultado positivo ao cliente conectado. A menos que, por suposto, cambies a configuración synchronous_commit de novo. Podes omitir parte SESSION no comando porque estará no valor predeterminado.
O segundo método é bo cando só quere asegurarse de obter a replicación sincrónica para unha única transacción. En moitas bases de datos de xeración NoSQL non existe o concepto de transaccións, pero si en PostgreSQL. Neste caso, comeza unha transacción e despois configura synchronous_commit в on antes de executar a entrada para a transacción. COMMIT confirmará a transacción usando calquera valor de parámetro synchronous_commit, que foi definido nese momento, aínda que o mellor é configurar a variable por adiantado para asegurarse de que outros desenvolvedores entendan que as escrituras non son asíncronas.
BEGIN;
SET LOCAL synchronous_commit TO ON;
// Your writes go here
COMMIT; Todas as transaccións confirmaranse agora como escritas nas réplicas antes de que a base de datos devolva unha resposta positiva ao cliente conectado.
Configuración de PostgreSQL
Antes disto, imaxinamos un sistema PostgreSQL con synchronous_commit, instalado en local. Para que isto sexa realista no lado do servidor, terás que establecer dúas opcións de configuración do servidor. Un parámetro máis synchronous_standby_names entrará en vigor cando synchronous_commit estará dentro on. Determina cales son as réplicas aptas para as commits síncronas e establecerémolas *, o que significará que todas as réplicas están implicadas. Estes valores adoitan configurarse en engadindo:
synchronous_commit = local
synchronous_standby_names='*'Ao establecer o parámetro synchronous_commit en significado local, creamos un sistema onde os discos locais permanecen sincrónicos, pero as confirmacións de réplicas de rede son asíncronas por defecto. A non ser que, por suposto, decidamos facer estas commits sincrónicas, como se mostra arriba.
Se estiveches seguindo o desenvolvemento , quizais teñas notado algúns cambios recentes (, ), que permitiu aos usuarios de Governor probar estes parámetros e supervisar a súa coherencia.
Unhas palabras máis...
Hai só unha semana, diríache que é imposible afinar PostgreSQL tan finamente. Foi entón cando Kurt, membro do equipo da plataforma Compose, insistiu en que existía tal oportunidade. Calmou as miñas obxeccións e atopouse na documentación de PostgreSQL :
Esta configuración pódese cambiar en calquera momento. O comportamento de calquera transacción está determinado pola configuración en vigor no momento da confirmación. Polo tanto, é posible e útil que algunhas transaccións se comprometan de forma sincrónica e para outras de forma asíncrona. Por exemplo, para forzar un multistatement transacción para facer commits de forma asíncrona cando o valor predeterminado do parámetro é oposto, establécese SET LOCAL synchronous_commit TO OFF nunha transacción.
Con esta pequena modificación no ficheiro de configuración, demos aos usuarios control sobre a súa coherencia e rendemento.
Fonte: www.habr.com