Especifica el número máximo de conexiones concurrentes desde servidores en espera o clientes de copia de seguridad base en streaming (es decir, el número máximo de procesos WAL sender ejecutándose simultáneamente). El valor predeterminado es 10. El valor 0 significa que la replicación está desactivada. La desconexión abrupta de un cliente de streaming podría dejar una ranura de conexión huérfana hasta que se alcance un tiempo de espera, por lo que este parámetro debe establecerse ligeramente por encima del número máximo de clientes esperados para que los clientes desconectados puedan reconectarse inmediatamente. Este parámetro solo se puede establecer al inicio del servidor. Además, wal_level debe estar configurado en replica o superior para permitir conexiones desde servidores en espera.

Al ejecutar un servidor en espera (standby), debes establecer este parámetro en el mismo valor o en uno superior al del servidor primario. De lo contrario, no se permitirán consultas en el servidor en espera.

Especifica el número máximo de ranuras de replicación (replication slots) (consulta la Section 26.2.6) que el servidor puede soportar. El valor predeterminado es 10. Este parámetro solo se puede establecer al inicio del servidor. Establecerlo en un valor inferior al número de ranuras de replicación existentes actualmente evitará que el servidor se inicie. Además, wal_level debe estar configurado en replica o superior para permitir el uso de ranuras de replicación.

Especifica el tamaño mínimo de los archivos del WAL pasados conservados en el directorio pg_wal, en caso de que un servidor en espera necesite obtenerlos para la replicación en streaming. Si un servidor en espera conectado al servidor emisor se retrasa por más de wal_keep_size megabytes, el servidor emisor podría eliminar un segmento del WAL que aún necesita el standby, en cuyo caso la conexión de replicación finalizará. Como resultado, las conexiones aguas abajo también fallarán eventualmente. (Sin embargo, el servidor en espera puede recuperarse obteniendo el segmento del archivo, si el archivado del WAL está en uso).

Esto establece únicamente el tamaño mínimo de los segmentos retenidos en pg_wal; el sistema podría necesitar retener más segmentos para el archivado del WAL o para recuperarse de un checkpoint. Si wal_keep_size es cero (el valor predeterminado), el sistema no conserva ningún segmento adicional para fines de standby, por lo que el número de segmentos del WAL antiguos disponibles para los servidores en espera es una función de la ubicación del checkpoint anterior y del estado del archivado del WAL. Si este valor se especifica sin unidades, se toma como megabytes. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica el tamaño máximo de los archivos del WAL que las ranuras de replicación tienen permitido retener en el directorio pg_wal en el momento del checkpoint. Si max_slot_wal_keep_size es -1 (el valor predeterminado), las ranuras de replicación pueden retener una cantidad ilimitada de archivos del WAL. De lo contrario, si el restart_lsn de una ranura de replicación se retrasa con respecto al LSN actual en más del tamaño especificado, el servidor en espera que utiliza la ranura puede dejar de continuar con la replicación debido a la eliminación de los archivos del WAL requeridos. Puedes ver la disponibilidad del WAL de las ranuras de replicación en pg_replication_slots. Si este valor se especifica sin unidades, se toma como megabytes. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Invalida las ranuras de replicación que hayan permanecido inactivas (no utilizadas por una conexión de replicación) durante más tiempo que esta duración. Si este valor se especifica sin unidades, se toma como segundos. Un valor de cero (el valor predeterminado) desactiva el mecanismo de invalidación por tiempo de espera de inactividad. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

La invalidación de ranuras debido al tiempo de espera de inactividad ocurre durante el checkpoint. Debido a que los checkpoints ocurren a intervalos de checkpoint_timeout, puede haber cierto retraso entre el momento en que se superó el valor de idle_replication_slot_timeout y el momento en que se activa la invalidación de la ranura en el siguiente checkpoint. Para evitar tales retrasos, los usuarios pueden forzar un checkpoint para invalidar rápidamente las ranuras inactivas. La duración de la inactividad de la ranura se calcula utilizando el valor de pg_replication_slots.inactive_since de la ranura.

Ten en cuenta que el mecanismo de invalidación por tiempo de espera de inactividad no es aplicable para las ranuras que no reservan WAL o para las ranuras en el servidor en espera que se están sincronizando desde el servidor primario (es decir, las ranuras en espera que tienen el valor pg_replication_slots.synced como true). Las ranuras sincronizadas siempre se consideran inactivas porque no realizan decodificación lógica para producir cambios.

Termina las conexiones de replicación que estén inactivas durante más tiempo que esta cantidad de tiempo. Esto es útil para que el servidor emisor detecte una caída del servidor en espera o una interrupción de la red. Si este value se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 60 segundos. Un valor de cero desactiva el mecanismo de tiempo de espera.

Con un clúster distribuido en múltiples ubicaciones geográficas, el uso de diferentes valores por ubicación aporta más flexibilidad en la gestión del clúster. Un valor más pequeño es útil para una detección de fallos más rápida con un standby que tiene una conexión de red de baja latencia, y un valor más grande ayuda a juzgar mejor la salud de un standby si se encuentra en una ubicación remota, con una conexión de red de alta latencia.

Registra la hora de commit de las transacciones. Este parámetro solo se puede establecer al inicio del servidor. El valor predeterminado es off.

Especifica una lista de servidores en espera que pueden soportar replicación síncrona, tal como se describe en la Section 26.2.8. Habrá uno o más servidores en espera síncronos activos; las transacciones que esperan la confirmación (commit) podrán proceder después de que estos servidores en espera confirmen la recepción de sus datos. Los servidores en espera síncronos serán aquellos cuyos nombres aparezcan en esta lista, y que estén actualmente conectados y transmitiendo datos en tiempo real (como lo muestra el estado de streaming en la vista pg_stat_replication). Especificar más de un servidor en espera síncrono puede permitir una disponibilidad muy alta y protección contra la pérdida de datos.

El nombre de un servidor en espera para este propósito es el ajuste application_name del standby, tal como se establece en la información de conexión del mismo. En caso de un servidor en espera de replicación física, esto debe configurarse en el ajuste primary_conninfo; el valor predeterminado es el ajuste de cluster_name si está configurado, de lo contrario walreceiver. Para la replicación lógica, esto se puede configurar en la información de conexión de la suscripción, y su valor predeterminado es el nombre de la suscripción. Para otros consumidores de flujos de replicación, consulta su documentación.

Este parámetro especifica una lista de servidores en espera utilizando cualquiera de las siguientes sintaxis:

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

donde num_sync es el número de servidores en espera síncronos de los cuales las transacciones necesitan esperar respuestas, y standby_name es el nombre de un servidor en espera. num_sync debe ser un valor entero mayor que cero. FIRST y ANY especifican el método para elegir los servidores en espera síncronos de entre los servidores listados.

La palabra clave FIRST, junto con num_sync, especifica una replicación síncrona basada en prioridad y hace que los commits de transacciones esperen hasta que sus registros del WAL se repliquen en los num_sync servidores en espera síncronos elegidos según sus prioridades. Por ejemplo, una configuración de FIRST 3 (s1, s2, s3, s4) hará que cada commit espere las respuestas de tres servidores en espera de mayor prioridad elegidos entre los servidores s1, s2, s3 y s4. Los servidores en espera cuyos nombres aparecen antes en la lista reciben mayor prioridad y se considerarán como síncronos. Otros servidores en espera que aparecen más adelante en esta lista representan servidores en espera síncronos potenciales. Si alguno de los servidores en espera síncronos actuales se desconecta por cualquier motivo, se reemplazará inmediatamente por el servidor en espera con la siguiente prioridad más alta. La palabra clave FIRST es opcional.

La palabra clave ANY, junto con num_sync, especifica una replicación síncrona basada en quórum y hace que los commits de transacciones esperen hasta que sus registros del WAL se repliquen en al menos num_sync servidores en espera listados. Por ejemplo, una configuración de ANY 3 (s1, s2, s3, s4) hará que cada commit proceda tan pronto como al menos tres servidores en espera de s1, s2, s3 y s4 respondan.

FIRST y ANY no distinguen entre mayúsculas y minúsculas. Si estas palabras clave se utilizan como el nombre de un servidor en espera, su standby_name debe estar entre comillas dobles.

La tercera sintaxis se utilizaba antes de la versión 9.6 de PostgreSQL y todavía está soportada. Es igual que la primera sintaxis con FIRST y num_sync igual a 1. Por ejemplo, FIRST 1 (s1, s2) y s1, s2 tienen el mismo significado: se elige s1 o bien s2 como servidor en espera síncrono.

La entrada especial * coincide con cualquier nombre de standby.

No existe ningún mecanismo para imponer la unicidad de los nombres de los servidores en espera. En caso de duplicados, uno de los standbys coincidentes se considerará de mayor prioridad, aunque exactamente cuál es indeterminado.

Si no se especifican nombres de servidores en espera síncronos aquí, entonces la replicación síncrona no está habilitada y los commits de transacciones no esperarán la replicación. Esta es la configuración predeterminada. Incluso cuando la replicación síncrona está habilitada, las transacciones individuales pueden configurarse para no esperar la replicación estableciendo el parámetro synchronous_commit en local o off.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Una lista separada por comas de nombres de ranuras de servidores en espera de replicación física por las cuales esperarán los procesos logical WAL sender. Los procesos logical WAL sender enviarán los cambios decodificados a los plugins solo después de que las ranuras de replicación especificadas confirmen haber recibido el WAL. Esto garantiza que las ranuras de failover de replicación lógica no consuman cambios hasta que esos cambios se reciban y se vacíen en los servidores en espera físicos correspondientes. Si una conexión de replicación lógica está destinada a cambiar a un servidor en espera físico después de que este sea promovido, la ranura de replicación física para el servidor en espera debe listarse aquí. Ten en cuenta que la replicación lógica no procederá si las ranuras especificadas en synchronized_standby_slots no existen o están invalidadas. Además, las funciones de gestión de replicación pg_replication_slot_advance, pg_logical_slot_get_changes y pg_logical_slot_peek_changes, cuando se utilizan con ranuras de failover lógico, se bloquearán hasta que todas las ranuras físicas especificadas en synchronized_standby_slots hayan confirmado la recepción del WAL.

Los servidores en espera correspondientes a las ranuras de replicación física en synchronized_standby_slots deben configurar sync_replication_slots = true para que puedan recibir los cambios de las ranuras de failover lógico desde el primario.

Especifica una cadena de conexión que utilizará el servidor en espera para conectarse con un servidor emisor. Esta cadena tiene el formato describo en la Section 32.1.1. Si alguna opción no se especifica en esta cadena, se comprueba la variable de entorno correspondiente (consulta la Section 32.15). Si la variable de entorno tampoco está configurada, se utilizan los valores predeterminados.

La cadena de conexión debe especificar el nombre de host (o dirección) del servidor emisor, así como el número de puerto si no es el mismo que el predeterminado del servidor en espera. Especifica también un nombre de usuario que corresponda a un rol con los privilegios adecuados en el servidor emisor (consulta la Section 26.2.5.1). También debe proporcionarse una contraseña si el emisor exige autenticación por contraseña. Se puede proporcionar en la cadena primary_conninfo o en un archivo ~/.pgpass independiente en el servidor en espera (usa replication como nombre de la base de datos).

Para la sincronización de ranuras de replicación (consulta la Section 47.2.3), también es necesario especificar un dbname válido en la cadena primary_conninfo. Esto solo se utilizará para la sincronización de ranuras. Se ignora para el streaming.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Si este parámetro cambia mientras el proceso WAL receiver se está ejecutando, se envía una señal a dicho proceso para que se apague y se espera que se reinicie con la nueva configuración (excepto si primary_conninfo es una cadena vacía). Esta configuración no tiene efecto si el servidor no está en modo standby.

Especifica opcionalmente una ranura de replicación existente que se utilizará al conectarse al servidor emisor mediante replicación en streaming para controlar la eliminación de recursos en el nodo aguas arriba (consulta la Section 26.2.6). Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Si este parámetro cambia mientras el proceso WAL receiver se está ejecutando, se envía una señal a dicho proceso para que se apague y se espera que se reinicie con la nueva configuración. Esta configuración no tiene efecto si primary_conninfo no está configurado o si el servidor no está en modo standby.

Especifica si puedes o no conectarte y ejecutar consultas durante la recuperación, tal como se describe en la Section 26.4. El valor predeterminado es on. Este parámetro solo se puede establecer al inicio del servidor. Solo tiene efecto durante la recuperación de archivos o en el modo standby.

Cuando el modo standby en caliente (hot standby) está activo, este parámetro determina cuánto tiempo debe esperar el servidor en espera antes de cancelar las consultas de standby que entran en conflicto con las entradas del WAL a punto de aplicarse, tal como se describe en la Section 26.4.2. max_standby_archive_delay se aplica cuando los datos del WAL se están leyendo desde el archivo del WAL (y por lo tanto no están actualizados). Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 30 segundos. Un valor de -1 permite que el standby espere indefinidamente a que se completen las consultas en conflicto. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Ten en cuenta que max_standby_archive_delay no es lo mismo que la duración máxima de tiempo que puede ejecutarse una consulta antes de ser cancelada; más bien es el tiempo total máximo permitido para aplicar los datos de cualquier segmento del WAL. Por lo tanto, si una consulta ha provocado un retraso significativo anteriormente en el segmento del WAL, las consultas en conflicto posteriores tendrán mucho menos tiempo de gracia.

Cuando el modo standby en caliente (hot standby) está activo, este parámetro determina cuánto tiempo debe esperar el servidor en espera antes de cancelar las consultas de standby que entran en conflicto con las entradas del WAL a punto de aplicarse, tal como se describe en la Section 26.4.2. max_standby_streaming_delay se aplica cuando los datos del WAL se están recibiendo a través de la replicación en streaming. Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 30 segundos. Un valor de -1 permite que el standby espere indefinidamente a que se completen las consultas en conflicto. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Ten en cuenta que max_standby_streaming_delay no es lo mismo que la duración máxima de tiempo que puede ejecutarse una consulta antes de ser cancelada; más bien es el tiempo total máximo permitido para aplicar los datos del WAL una vez que han recibido del servidor primario. Por lo tanto, si una consulta ha provocado un retraso significativo, las consultas en conflicto posteriores tendrán mucho menos tiempo de gracia hasta que el servidor en espera se haya puesto al día nuevamente.

Especifica si el proceso WAL receiver debe crear una ranura de replicación temporal en la instancia remota cuando no se ha configurado ninguna ranura de replicación permanente para utilizar (usando primary_slot_name). El valor predeterminado es off. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor. Si este parámetro cambia mientras el proceso WAL receiver se está ejecutando, se envía una señal a dicho proceso para que se apague y se espera que se reinicie con la nueva configuración.

Especifica la frecuencia mínima para que el proceso WAL receiver en el standby envíe información sobre el progreso de la replicación al primario o al standby aguas arriba, donde se puede ver utilizando la vista pg_stat_replication. El standby informará la última ubicación del registro de escritura anticipada que ha escrito, la última posición que ha vaciado al disco y la última posición que ha aplicado. El valor de este parámetro es la cantidad máxima de tiempo entre informes. Los informes se envían cada vez que cambian las posiciones de escritura o vaciado, o con la frecuencia especificada por este parámetro si se establece en un valor distinto de cero. Existen casos adicionales en los que se envían informes ignorando este parámetro; por ejemplo, cuando se completa el procesamiento del WAL existente o cuando synchronous_commit está configurado en remote_apply. Por lo tanto, la posición de aplicación puede ir ligeramente por detrás de la posición real. Si este valor se especifica sin unidades, se toma como segundos. El valor predeterminado es 10 segundos. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica si un hot standby enviará o no retroalimentación (feedback) al primario o al standby aguas arriba sobre las consultas que se están ejecutando actualmente en el standby. Este parámetro se puede utilizar para eliminar las cancelaciones de consultas causadas por registros de limpieza, pero puede causar un aumento de tamaño (bloat) de la base de datos en el primario para algunas cargas de trabajo. Los mensajes de retroalimentación no se enviarán con una frecuencia mayor a una vez por wal_receiver_status_interval. El valor predeterminado es off. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Si se utiliza la replicación en cascada, la retroalimentación se pasa aguas arriba hasta llegar finalmente al primario. Los standbys no hacen ningún otro uso de la retroalimentación que reciben más que pasarla aguas arriba.

Ten en cuenta que si el reloj en el standby se adelanta o se atrasa, el mensaje de retroalimentación podría no enviarse al intervalo requerido. En casos extremos, esto puede llevar a un riesgo prolongado de no eliminar las filas muertas en el primario durante períodos prolongados, ya que el mecanismo de retroalimentación se basa en marcas de tiempo.

Termina las conexiones de replicación que estén inactivas durante más tiempo que esta cantidad de tiempo. Esto es útil para que el standby receptor detecte una caída del nodo primario o una interrupción de la red. Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 60 segundos. Un valor de cero desactiva el mecanismo de tiempo de espera. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica cuánto tiempo debe esperar el servidor en espera cuando los datos del WAL no están disponibles en ninguna de las fuentes (replicación en streaming, pg_wal local o archivo del WAL) antes de intentar nuevamente recuperar los datos del WAL. Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es 5 segundos. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Este parámetro es útil en configuraciones donde un nodo en recuperación necesita controlar la cantidad de tiempo de espera para que nuevos datos del WAL estén disponibles. Por ejemplo, en la recuperación de archivos, es posible hacer que la recuperación sea más responsiva en la detección de un nuevo archivo de WAL reduciendo el valor de este parámetro. En un sistema con baja actividad del WAL, aumentarlo reduce la cantidad de solicitudes necesarias para acceder a los archivos del WAL, algo útil, por ejemplo, en entornos de nube donde se tiene en cuenta la cantidad de veces que se accede a una infraestructura.

En la replicación lógica, este parámetro también limita la frecuencia con la que un worker de aplicación de replicación o un worker de sincronización de tablas que falla será reiniciado.

De forma predeterminada, un servidor en espera restaura los registros del WAL del servidor emisor lo antes posible. Puede ser útil tener una copia de los datos retrasada en el tiempo, lo que ofrece la oportunidad de corregir errores de pérdida de datos. Este parámetro permite retrasar la recuperación por una cantidad específica de tiempo. Por ejemplo, si estableces este parámetro en 5min, el standby reproducirá cada commit de transacción solo cuando la hora del sistema en el standby sea al menos cinco minutos posterior a la hora de commit reportada por el primario. Si este valor se especifica sin unidades, se toma como milisegundos. El valor predeterminado es cero, lo que no añade ningún retraso.

Es posible que el retraso de replicación entre servidores supere el valor de este parámetro, en cuyo caso no se añade ningún retraso. Ten en cuenta que el retraso se calcula entre la marca de tiempo del WAL tal como fue escrita en el primario y la hora actual en el standby. Los retrasos en la transferencia debido a la latencia de la red o a las configuraciones de replicación en cascada pueden reducir significativamente el tiempo de espera real. Si los relojes del sistema en el primario y en el standby no están sincronizados, esto puede hacer que la recuperación aplique los registros antes de lo esperado; pero ese no es un problema importante porque las configuraciones útiles de este parámetro son mucho mayores que las desviaciones de tiempo típicas entre servidores.

El retraso ocurre únicamente en los registros de WAL para commits de transacciones. Otros registros se reproducen lo más rápido posible, lo cual no es un problema porque las reglas de visibilidad de MVCC aseguran que sus efectos no sean visibles hasta que se aplique el registro de commit correspondiente.

El retraso ocurre una vez que la base de datos en recuperación ha alcanzado un estado consistente, hasta que el standby sea promovido o activado. Después de eso, el standby finalizará la recuperación sin más esperas.

Los registros del WAL deben conservarse en el standby hasta que estén listos para ser aplicados. Por lo tanto, retrasos más largos darán como resultado una mayor acumulación de archivos del WAL, aumentando los requisitos de espacio en disco para el directorio pg_wal del standby.

Este parámetro está diseñado para su uso con implementaciones de replicación en streaming; sin embargo, si se especifica el parámetro, se respetará en todos los casos excepto en la recuperación tras caídas (crash recovery).

El uso de esta característica retrasará el envío de hot_standby_feedback, lo que podría provocar un aumento de tamaño (bloat) en el primario; usa ambos juntos con cuidado.

Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Habilita a un standby físico para sincronizar las ranuras de failover lógico desde el servidor primario, de modo que los suscriptores lógicos puedan reanudar la replicación desde el nuevo servidor primario después de un failover.

Está desactivado por defecto. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica cuántos orígenes de replicación (consulta la Chapter 48) se pueden rastrear simultáneamente, limitando eficazmente cuántas suscripciones de replicación lógica se pueden crear en el servidor. Establecerlo en un valor inferior al número actual de orígenes de replicación rastreados (reflejado en pg_replication_origin_status) evitará que el servidor se inicie. El valor predeterminado es 10. Este parámetro solo se puede establecer al inicio del servidor. max_active_replication_origins debe establecerse al menos en el número de suscripciones que se añadirán al suscriptor, más alguna reserva para la sincronización de tablas.

Especifica el número máximo de workers de replicación lógica. Esto incluye workers de aplicación de líder (leader apply workers), workers de aplicación paralela (parallel apply workers) y workers de sincronización de tablas.

Los workers de replicación lógica se toman del pool definido por max_worker_processes.

El valor predeterminado es 4. Este parámetro solo se puede establecer al inicio del servidor.

Número máximo de workers de sincronización por suscripción. Este parámetro controla la cantidad de paralelismo de la copia de datos inicial durante la inicialización de la suscripción o cuando se añaden nuevas tablas.

Actualmente, solo puede haber un worker de sincronización por tabla.

Los workers de sincronización se toman del pool definido por max_logical_replication_workers.

El valor predeterminado es 2. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Número máximo de workers de aplicación paralela por suscripción. Este parámetro controla la cantidad de paralelismo para la transmisión de transacciones en curso con el parámetro de suscripción streaming = parallel.

Los workers de aplicación paralela se toman del pool definido por max_logical_replication_workers.

El valor predeterminado es 2. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.