En esta publicación de blog, nos sumergimos en los aspectos prácticos de la configuración de Streaming Replication (SR) en PostgreSQL. La replicación de transmisión es el bloque de construcción fundamental para lograr una alta disponibilidad en su hosting de PostgreSQL y se produce mediante la ejecución de una configuración maestro-esclavo.

Terminología maestro-esclavo

Servidor maestro/principal

• El servidor que puede aceptar escrituras.
• También llamado servidor de lectura/escritura.

Servidor secundario/en espera

• Un servidor donde los datos se mantienen sincronizados con el maestro de forma continua.
• También llamado servidor de respaldo o réplica.
• Un servidor en espera tibio es aquel al que no se puede conectar hasta que se promueva a servidor maestro.
• Por el contrario, un servidor en espera activo puede aceptar conexiones y atender consultas de solo lectura. Durante el resto de esta discusión, nos centraremos únicamente en los servidores de espera activos.

Los datos se escriben en el servidor maestro y se propagan a los servidores esclavos. En caso de que haya un problema con el servidor maestro existente, uno de los servidores esclavos se hará cargo y continuará realizando escrituras para garantizar la disponibilidad del sistema.

Replicación basada en envío WAL

¿Qué es WAL?

• WAL significa registro de escritura anticipada.
• Es un archivo de registro donde se escriben todas las modificaciones a la base de datos antes de que se apliquen/escriban en los archivos de datos.
• WAL se utiliza para la recuperación después de un bloqueo de la base de datos, lo que garantiza la integridad de los datos.
• WAL se utiliza en sistemas de bases de datos para lograr atomicidad y durabilidad.

¿Cómo se utiliza WAL para la replicación?

Los registros de registro de escritura anticipada se utilizan para mantener los datos sincronizados entre los servidores de la base de datos. Esto se logra de dos maneras:

Envío de registros basado en archivos

• Los archivos de registro WAL se envían desde el maestro a los servidores en espera para mantener los datos sincronizados.
• El maestro puede copiar directamente los registros en el almacenamiento del servidor en espera o puede compartir el almacenamiento con los servidores en espera.
• Un archivo de registro WAL puede contener hasta 16 MB de datos.
• El archivo WAL se envía solo después de alcanzar ese umbral.
• Esto provocará un retraso en la replicación y también aumentará las posibilidades de perder datos si el maestro falla y los registros no se archivan

Transmisión de registros WAL

• Los servidores de bases de datos transmiten fragmentos de registros WAL para mantener los datos sincronizados.
• El servidor en espera se conecta al maestro para recibir los fragmentos WAL.
• Los registros WAL se transmiten a medida que se generan.
• La transmisión de registros WAL no necesita esperar a que se llene el archivo WAL.
• Esto permite que un servidor en espera se mantenga más actualizado de lo que es posible con el envío de registros basado en archivos.
• De forma predeterminada, la replicación de transmisión es asíncrona, aunque también admite la replicación síncrona.

Ambos métodos tienen sus pros y sus contras. El envío basado en archivos permite la recuperación en un momento dado y el archivado continuo, mientras que la transmisión garantiza la disponibilidad inmediata de los datos en los servidores en espera. Sin embargo, puede configurar PostgreSQL para usar ambos métodos al mismo tiempo y disfrutar de los beneficios. En este blog, nos concentramos principalmente en la replicación de transmisión para lograr la alta disponibilidad de PostgreSQL.

¿Cómo configurar la replicación de transmisión?

Configurar la replicación de transmisión en PostgreSQL es muy simple. Suponiendo que PostgreSQL ya esté instalado en todos los servidores, puede seguir estos pasos para comenzar:

Configuración en el Nodo Maestro

• Inicialice la base de datos en el nodo principal mediante la utilidad initdb.
• Cree un rol/usuario con privilegios de replicación ejecutando el siguiente comando. Después de ejecutar el comando, puede verificarlo ejecutando \du para enumerarlos en psql.
  •   CREAR USUARIO REPLICACIÓN INICIO DE SESIÓN CONTRASEÑA CIFRADA ’’;
• Configure las propiedades relacionadas con la replicación de transmisión en el archivo de configuración principal de PostgreSQL (postgresql.conf):
  

  # Los valores posibles son replica|minimal|logical nivel_wal =número de réplica requerido para la función pg_rewind cuando el modo de espera no está sincronizado con el maestro wal_log_hints =on# establece el número máximo de conexiones simultáneas desde los servidores en espera. max_wal_senders =3 # El siguiente parámetro se usa para decirle al maestro que mantenga la cantidad mínima de # segmentos de registros WAL para que no se eliminen antes de que el modo de espera los consuma. # cada segmento es 16 MB wal_keep_segmentos =8 # El siguiente parámetro habilita la conexión de solo lectura en el nodo cuando está # en función de espera. Esto se ignora cuando el servidor se ejecuta como maestro. hot_standby =encendido

• Agregue una entrada de replicación en el archivo pg_hba.conf para permitir conexiones de replicación entre los servidores:
  

  # Permitir conexiones de replicación desde localhost, # por un usuario con el privilegio de replicación. # TIPO    BASE DE DATOS    USUARIO    DIRECCIÓN    MÉTODO host    replicación    repl_user    IPaddress (CIDR)    md5

• Reinicie el servicio de PostgreSQL en el nodo maestro para que los cambios surtan efecto.

Configuración en los nodos en espera

• Cree la copia de seguridad base del nodo maestro con la utilidad pg_basebackup y utilícela como punto de partida para la copia de seguridad.
  

  # Explicación de algunas opciones utilizadas para la utilidad pg_basebackup # La opción -X se utiliza para incluir los archivos de registro de transacciones necesarios (archivos WAL) en la # copia de seguridad. Cuando especifica la transmisión, esto abrirá una segunda conexión con el servidor # y comenzará a transmitir el registro de transacciones al mismo tiempo que ejecuta la copia de seguridad. # -c es la opción del punto de control. Configurarlo en rápido obligará a que el punto de control # se cree pronto. # -W obliga a pg_basebackup a solicitar una contraseña antes de conectarse # a una base de datos. pg_basebackup -D  -h -X flujo -c rápido -U usuario_repl -W

• Cree el archivo de configuración de replicación si no está presente (se crea automáticamente si se proporciona la opción -R en pg_basebackup):
  

  # Especifica si iniciar el servidor como un modo de espera En la replicación de transmisión, # este parámetro debe estar activado. standby_mode =‘on’# Especifica una cadena de conexión que se utiliza para que el servidor en espera se conecte # con el principal/principal. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Especifica la recuperación a una línea de tiempo particular. El valor predeterminado es recuperar a lo largo de la # misma línea de tiempo que estaba vigente cuando se realizó la copia de seguridad base. # Al establecer esto en la última recuperación se recupera la última línea de tiempo encontrada # en el archivo, que es útil en un servidor en espera. recovery_target_timeline ='más reciente'

• Iniciar el modo de espera.

La configuración en espera debe realizarse en todos los servidores en espera. Una vez que se realiza la configuración y se inicia un modo de espera, se conectará al maestro y comenzará a transmitir registros. Esto configurará la replicación y se puede verificar ejecutando la instrucción SQL "SELECT * FROM pg_stat_replication; “.

De forma predeterminada, la replicación de transmisión es asíncrona. Si desea hacerlo síncrono, puede configurarlo usando los siguientes parámetros:

Confirmación_sincrónica debe estar activado para la replicación síncrona y este es el valor predeterminado. PostgreSQL proporciona opciones muy flexibles para la confirmación sincrónica y se puede configurar a nivel de usuario/base de datos. Los valores válidos son los siguientes:

• Desactivado – La confirmación de la transacción se confirma ante el cliente incluso antes de que el registro de la transacción se vacíe realmente en el archivo de registro WAL en ese nodo.
• Locales –  La confirmación de la transacción se reconoce al cliente solo después de que el registro de la transacción se vacíe en el archivo de registro WAL en ese nodo.
• Escritura_remota – La confirmación de la transacción se confirma para el cliente solo después de que los servidores especificados por synchronous_standby_names confirmen que el registro de la transacción se escribió en la memoria caché del disco, pero no necesariamente después de vaciarlo en el archivo de registro WAL.
• Activado – La confirmación de la transacción se confirma para el cliente solo después de que los servidores especificados por synchronous_standby_names confirmen que el registro de la transacción se vacía en el archivo de registro WAL.
• Aplicación_remota – La confirmación de la transacción se confirma para el cliente solo después de que los servidores especificados por synchronous_standby_names confirmen que el registro de la transacción se vacía en el archivo de registro WAL y se aplica a la base de datos.

Configurar synchronous_commit en desactivado o local en el modo de replicación síncrona hará que funcione como asíncrono y puede ayudarlo a lograr un mejor rendimiento de escritura. Sin embargo, esto tendrá un mayor riesgo de pérdida de datos y retrasos en la lectura en los servidores en espera. Si se establece en aplicación_remota, garantizará la disponibilidad inmediata de los datos en los servidores en espera, pero el rendimiento de escritura puede degradarse, ya que debe aplicarse en todos los servidores en espera mencionados.

Puede habilitar el modo de archivo si planea usar el archivo continuo y la recuperación de un punto en el tiempo. Si bien no es obligatorio para la replicación de transmisión, habilitar el modo de archivo tiene beneficios adicionales. Si el modo de archivo no está activado, debemos usar las ranuras de replicación función o asegúrese de que wal_keep_segments el valor se establece lo suficientemente alto en función de la carga.

Consulte esta excelente presentación para obtener más detalles sobre la alta disponibilidad en PostgreSQL. En nuestra próxima publicación de blog, le presentaremos el mundo de las herramientas que se utilizan para administrar la alta disponibilidad de PostgreSQL mediante la replicación de transmisión.