La traducción del artículo fue preparada específicamente para estudiantes del curso. "Base de datos". ¿Interesado en desarrollarse en esta dirección? Te invitamos a Dia abierto, donde hablamos en detalle sobre el programa, las características del formato online, las competencias y las perspectivas profesionales que esperan a los graduados después de la formación.

PostgreSQL y configuraciones de coherencia de escritura específicas de la conexión
En Compose trabajamos con muchas bases de datos, lo que nos brinda la oportunidad de familiarizarnos más con sus funcionalidades y deficiencias. A medida que aprendemos a amar las características de las nuevas bases de datos, a veces comenzamos a pensar en lo bueno que sería si características similares estuvieran presentes en las herramientas más maduras con las que hemos estado trabajando durante mucho tiempo. Una de las nuevas características que quería ver en PostgreSQL era la coherencia de escritura configurable por conexión en todo el clúster. Y resulta que ya lo tenemos, y hoy queremos compartir contigo información sobre cómo puedes usarlo.

¿Por qué necesito esto?

El comportamiento del clúster depende de su aplicación. Tomemos, por ejemplo, una aplicación de pago de facturas. Necesitará un XNUMX % de coherencia en todo el clúster, por lo que deberá habilitar las confirmaciones sincrónicas para que su base de datos espere a que se realicen todos los cambios. Sin embargo, si su aplicación es una red social de rápido crecimiento, probablemente prefiera una respuesta rápida a una coherencia del XNUMX%. Para lograr esto, puede utilizar confirmaciones asincrónicas en su clúster.

Cumplir con el compromiso

Debe hacer concesiones entre la coherencia de los datos y el rendimiento. PostgreSQL se aleja de la coherencia porque la configuración predeterminada es entonces predecible y sin sorpresas inesperadas. Ahora veamos los compromisos.

Compensación 1: Rendimiento

Si el clúster de PostgreSQL no requiere coherencia, puede ejecutarse de forma asincrónica. La escritura se realiza en el líder del clúster y las actualizaciones se enviarán a sus réplicas unos milisegundos más tarde. Cuando un clúster de PostgreSQL requiere coherencia, debe ejecutarse de forma sincrónica. La escritura se realizará al líder del clúster, que enviará una actualización a las réplicas y esperará la confirmación de que cada una escribió antes de enviar la confirmación al cliente que inició la escritura de que fue exitosa. La diferencia práctica entre estos enfoques es que el método asincrónico requiere dos saltos de red, mientras que el método síncrono requiere cuatro.

Compensación 2: consistencia

El resultado en caso de que el líder falle en estos dos enfoques también será diferente. Si el trabajo se realiza de forma asincrónica, si se produce dicho error, las réplicas no confirmarán todos los registros. ¿Cuánto se perderá? Depende de la aplicación en sí y de la eficiencia de la replicación. La replicación compuesta evitará que una réplica se convierta en líder si la cantidad de información que contiene es 1 MB menor que la del líder, es decir, se podrían perder hasta 1 MB de registros durante la operación asincrónica.

Esto no sucede en modo síncrono. Si el líder falla, todas las réplicas se actualizan, ya que cualquier escritura confirmada en el líder debe confirmarse en las réplicas. Esto es coherencia.

El comportamiento sincrónico tiene sentido en una aplicación de facturación donde la coherencia tiene una clara ventaja en el equilibrio entre coherencia y rendimiento. Lo más importante para una aplicación de este tipo son los datos válidos. Ahora piense en una red social en la que la tarea principal es mantener la atención del usuario respondiendo a las solicitudes lo más rápido posible. En este caso, la prioridad será el rendimiento con menos saltos de red y menos espera para las confirmaciones. Sin embargo, la compensación entre rendimiento y consistencia no es la única en la que hay que pensar.

Compensación 3: fallas

Es muy importante comprender cómo se comporta un clúster durante una falla. Considere una situación en la que fallan una o más réplicas. Cuando las confirmaciones se procesan de forma asincrónica, el líder seguirá funcionando, es decir, aceptará y procesará escrituras, sin esperar a que falten réplicas. Cuando las réplicas regresan al grupo, alcanzan al líder. Con la replicación sincrónica, si las réplicas no responden, entonces el líder no tendrá otra opción y continuará esperando la confirmación de la confirmación hasta que la réplica regrese al clúster y pueda aceptar y confirmar la escritura.

¿Una conexión por transacción?

Cada aplicación necesita un tipo diferente de combinación de coherencia y rendimiento. A menos, por supuesto, que sea nuestra aplicación de pago de facturas, que imaginamos completamente consistente, o nuestra casi efímera aplicación de redes sociales. En todos los demás casos, habrá ocasiones en las que algunas operaciones deberán ser sincrónicas y otras asincrónicas. Es posible que no quieras que el sistema espere hasta que se confirme un mensaje enviado al chat, pero si se procesa un pago en la misma aplicación, entonces tendrás que esperar.

Todas estas decisiones, por supuesto, las toma el desarrollador de la aplicación. Tomar las decisiones correctas sobre cuándo utilizar cada enfoque le ayudará a aprovechar al máximo su clúster. Es importante que el desarrollador pueda alternar entre ellos a nivel de SQL para conexiones y transacciones.

Garantizar el control en la práctica

De forma predeterminada, PostgreSQL proporciona coherencia. Esto está controlado por el parámetro del servidor. synchronous_commit. Por defecto está en posición on, pero tiene otras tres opciones: local, remote_write o off.

Al configurar el parámetro en off todas las confirmaciones sincrónicas se detienen, incluso en el sistema local. El parámetro local especifica el modo síncrono para el sistema local, pero las escrituras en las réplicas se realizan de forma asíncrona. Remote_write va aún más lejos: las escrituras en las réplicas se realizan de forma asíncrona, pero se devuelven cuando la réplica ha aceptado la escritura pero no la ha escrito en el disco.

Al considerar la gama de opciones disponibles, elegimos un comportamiento y, teniendo en cuenta que on – estas son grabaciones sincrónicas, elegiremos local para confirmaciones asincrónicas a través de la red, dejando las confirmaciones locales sincrónicas.

Ahora, le diremos cómo configurar esto en un momento, pero imagine que configuramos synchronous_commit в local para el servidor. Nos preguntamos si era posible cambiar el parámetro. synchronous_commit sobre la marcha, y resultó que no sólo es posible, sino que incluso hay dos formas de hacerlo. La primera es configurar la sesión de tu conexión de la siguiente manera:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

Todas las escrituras posteriores en la sesión acusarán recibo de las escrituras en las réplicas antes de devolver un resultado positivo al cliente conectado. A menos, por supuesto, que cambies la configuración. synchronous_commit de nuevo. Puedes omitir parte SESSION en el comando porque estará en el valor predeterminado.

El segundo método es bueno cuando solo desea asegurarse de obtener una replicación sincrónica para una sola transacción. En muchas bases de datos de generación NoSQL el concepto de transacciones no existe, pero sí en PostgreSQL. En este caso, inicia una transacción y luego configura synchronous_commit в on antes de ejecutar la entrada de la transacción. COMMIT confirmará la transacción utilizando cualquier valor de parámetro synchronous_commit, que se configuró en ese momento, aunque es mejor configurar la variable por adelantado para asegurarse de que otros desarrolladores comprendan que las escrituras no son asincrónicas.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

Todas las confirmaciones de transacciones ahora se confirmarán como escritas en las réplicas antes de que la base de datos devuelva una respuesta positiva al cliente conectado.

Configuración de PostgreSQL

Antes de esto, imaginamos un sistema PostgreSQL con synchronous_commit, instalado en local. Para que esto sea realista en el lado del servidor, deberá establecer dos opciones de configuración del servidor. Un parámetro más synchronous_standby_names se hará realidad cuando synchronous_commit Estará en on. Determina qué réplicas son elegibles para confirmaciones sincrónicas y lo configuraremos en *, lo que significará que todas las réplicas están involucradas. Estos valores generalmente se configuran en archivo de configuración añadiendo:

synchronous_commit = local  
synchronous_standby_names='*'

Al configurar el parámetro synchronous_commit en significado local, creamos un sistema donde los discos locales permanecen sincrónicos, pero las confirmaciones de réplicas de red son asíncronas de forma predeterminada. A menos, por supuesto, que decidamos hacer que estas confirmaciones sean sincrónicas, como se muestra arriba.

Si has estado siguiendo el desarrollo Proyecto gobernador, вы могли заметить некоторые недавние изменения (1, 2), lo que permitió a los usuarios de Governor probar estos parámetros y monitorear su consistencia.

Unas palabras más...

Hace apenas una semana, les habría dicho que es imposible ajustar PostgreSQL con tanta precisión. Fue entonces cuando Kurt, miembro del equipo de la plataforma Compose, insistió en que existía esa oportunidad. Calmó mis objeciones y encontró en la documentación de PostgreSQL el siguiente:

Esta configuración se puede cambiar en cualquier momento. El comportamiento de cualquier transacción está determinado por la configuración vigente en el momento de la confirmación. Por lo tanto, es posible y útil que algunas transacciones se confirmen de forma sincrónica y otras de forma asincrónica. Por ejemplo, para obligar a uno multistatement transacción para realizar confirmaciones de forma asincrónica cuando el valor predeterminado del parámetro es opuesto, establezca SET LOCAL synchronous_commit TO OFF en una transacción.

Con esta pequeña modificación al archivo de configuración, les dimos a los usuarios control sobre su coherencia y rendimiento.

Fuente: habr.com