Cuando el parámetro hot_standby está configurado en true en un servidor standby, este comenzará a aceptar conexiones una vez que la recuperación haya llevado al sistema a un estado consistente y esté listo para hot standby. Todas las conexiones de este tipo son estrictamente de solo lectura; ni siquiera se pueden escribir tablas temporales.

Los datos en el standby tardan algún tiempo en llegar desde el servidor primario, por lo que habrá un retraso medible entre el primario y el standby. Por lo tanto, ejecutar la misma consulta casi simultáneamente en el primario y en el standby podría devolver resultados diferentes. Decimos que los datos en el standby son eventualmente consistentes (eventually consistent) con el primario. Una vez que el registro de confirmación de una transacción se reproduce en el standby, los cambios realizados por esa transacción serán visibles para cualquier captura instantánea (snapshot) nueva tomada en el standby. Las capturas instantáneas se pueden tomar al inicio de cada consulta o al inicio de cada transacción, según el nivel de aislamiento de la transacción actual. Para obtener más detalles, consulta la Section 13.2.

Las transacciones iniciadas durante el hot standby pueden emitir los siguientes comandos:

A las transacciones iniciadas durante el hot standby nunca se les asignará un ID de transacción y no pueden escribir en el registro de escritura anticipada del sistema. Por lo tanto, las siguientes acciones producirán mensajes de error:

En la operación normal, a las transacciones de “solo lectura” se les permite utilizar LISTEN y NOTIFY, por lo que las sesiones hot standby funcionan bajo restricciones ligeramente más estrictas que las sesiones ordinarias de solo lectura. Es posible que algunas de estas restricciones se relajen en una versión futura.

Durante el hot standby, el parámetro transaction_read_only es siempre true y no se puede cambiar. Pero mientras no se intente modificar la base de datos, las conexiones durante el hot standby actuarán de manera muy similar a cualquier otra conexión de base de datos. Si se produce una conmutación por error o un cambio de rol, la base de datos cambiará al modo de procesamiento normal. Las sesiones permanecerán conectadas mientras el servidor cambia de modo. Una vez que finaliza el hot standby, será posible iniciar transacciones de lectura/escritura (incluso desde una sesión iniciada durante el hot standby).

Los usuarios pueden determinar si el hot standby está activo actualmente para su sesión emitiendo SHOW in_hot_standby. (En las versiones del servidor anteriores a la 14, el parámetro in_hot_standby no existía; un método sustituto viable para servidores más antiguos es SHOW transaction_read_only). Además, un conjunto de funciones (Table 9.98) permite a los usuarios acceder a información sobre el servidor standby. Estas te permiten escribir programas que conocen el estado actual de la base de datos. Pueden utilizarse para supervisar el progreso de la recuperación o para permitirte escribir programas complejos que restauran la base de datos a estados particulares.

Los servidores primario y standby están en muchos aspectos conectados de forma débil. Las acciones en el primario tendrán un efecto en el standby. Como resultado, existe la posibilidad de interacciones negativas o conflictos entre ellos. El conflicto más fácil de entender es el rendimiento: si se está produciendo una carga de datos enorme en el primario, esto generará un flujo similar de registros WAL en el standby, por lo que las consultas del standby pueden competir por los recursos del sistema, como la E/S.

También hay otros tipos de conflictos que pueden ocurrir con el hot standby. Estos conflictos son conflictos duros (hard conflicts) en el sentido de que podría ser necesario cancelar consultas y, en algunos casos, desconectar sesiones para resolverlos. Al usuario se le proporcionan varias formas de manejar estos conflictos. Los casos de conflicto incluyen:

En el servidor primario, estos casos simplemente resultan en una espera; y el usuario podría optar por cancelar cualquiera de las acciones en conflicto. Sin embargo, en el standby no hay elección: la acción registrada en el WAL ya ocurrió en el primario, por lo que el standby no debe dejar de aplicarla. Además, permitir que la aplicación de WAL espere indefinidamente puede ser muy indeseable, porque el estado del standby quedará cada vez más por detrás del primario. Por lo tanto, se proporciona un mecanismo para cancelar por la fuerza las consultas del standby que entren en conflicto con los registros WAL que se van a aplicar.

Un ejemplo de situación problemática es un administrador en el servidor primario que ejecuta DROP TABLE en una tabla que se está consultando actualmente en el servidor standby. Claramente, la consulta del standby no puede continuar si el DROP TABLE se aplica en el standby. Si esta situación ocurriera en el primario, el DROP TABLE esperaría hasta que la otra consulta hubiera terminado. Pero cuando se ejecuta DROP TABLE en el primario, el primario no tiene información sobre qué consultas se están ejecutando en el standby, por lo que no esperará a ninguna de esas consultas del standby. Los registros de cambio de WAL llegan al standby mientras la consulta del standby aún se está ejecutando, lo que provoca un conflicto. El servidor standby debe retrasar la aplicación de los registros WAL (y todo lo que viene después de ellos, también) o bien cancelar la consulta en conflicto para que se pueda aplicar el DROP TABLE.

Cuando una consulta en conflicto es corta, normalmente es deseable permitir que se complete retrasando un poco la aplicación del WAL; pero por lo general no es deseable un retraso prolongado en la aplicación del WAL. Por lo tanto, el mecanismo de cancelación tiene parámetros, max_standby_archive_delay y max_standby_streaming_delay, que definen el retraso máximo permitido en la aplicación del WAL. Las consultas en conflicto se cancelarán una vez que haya tomado más tiempo que la configuración de retraso correspondiente aplicar cualquier dato WAL recién recibido. Hay dos parámetros para que se puedan especificar diferentes valores de retraso para el caso de leer datos WAL de un archivo (es decir, la recuperación inicial de una copia de seguridad base o “ponerse al día” con un servidor standby que se ha quedado muy atrás) en comparación con la lectura de datos WAL a través de la replicación en flujo.

En un servidor standby que existe principalmente para alta disponibilidad, es mejor configurar los parámetros de retraso con valores relativamente cortos, de modo que el servidor no pueda quedarse muy atrás del primario debido a los retrasos causados por las consultas del standby. Sin embargo, si el servidor standby está destinado a ejecutar consultas de larga duración, entonces puede ser preferible un valor de retraso alto o incluso infinito. Ten en cuenta, sin embargo, que una consulta de larga duración podría hacer que otras sesiones en el servidor standby no vean los cambios recientes en el primario, si retrasa la aplicación de los registros WAL.

Una vez superado el retraso especificado por max_standby_archive_delay o max_standby_streaming_delay, las consultas en conflicto se cancelarán. Esto suele dar lugar a un error de cancelación, aunque en el caso de reproducir un DROP DATABASE se finalizará toda la sesión en conflicto. Además, si el conflicto se debe a un bloqueo mantenido por una transacción inactiva, la sesión en conflicto finaliza (este comportamiento podría cambiar en el futuro).

Las consultas canceladas se pueden volver a intentar inmediatamente (después de comenzar una nueva transacción, por supuesto). Dado que la cancelación de la consulta depende de la naturaleza de los registros WAL que se están reproduciendo, una consulta que fue cancelada puede tener éxito si se ejecuta de nuevo.

Ten en cuenta que los parámetros de retraso se comparan con el tiempo transcurrido desde que el servidor standby recibió los datos WAL. Por lo tanto, el período de gracia permitido a cualquier consulta en el standby nunca es superior al parámetro de retraso, y podría ser considerablemente menor si el standby ya se ha quedado atrás como resultado de esperar a que se completen las consultas anteriores, o como resultado de no poder mantenerse al día con una carga de actualizaciones pesada.

La razón más común de conflicto entre las consultas del standby y la reproducción de WAL es la “limpieza temprana” (early cleanup). Normalmente, PostgreSQL permite la limpieza de versiones de fila antiguas cuando no hay transacciones que necesiten verlas para garantizar la visibilidad correcta de los datos según las reglas de MVCC. Sin embargo, esta regla solo se puede aplicar para las transacciones que se ejecutan en el primario. Por lo tanto, es posible que la limpieza en el primario elimine versiones de fila que aún son visibles para una transacción en el standby.

La limpieza de versiones de fila no es la única causa potencial de conflictos con las consultas del standby. Todos los escaneos de solo índice (incluidos los que se ejecutan en los standbys) deben utilizar una captura instantánea MVCC que “coincida” con el mapa de visibilidad. Por lo tanto, se requieren conflictos siempre que VACUUM establezca una página como visible para todos en el mapa de visibilidad que contenga una o más filas no visibles para todas las consultas del standby. Por lo tanto, incluso la ejecución de VACUUM contra una tabla sin filas actualizadas o eliminadas que requieran limpieza podría dar lugar a conflictos.

Los usuarios deben tener claro que las tablas que se actualizan de forma regular y sustancial en el servidor primario causarán rápidamente la cancelación de las consultas de mayor duración en el standby. En tales casos, la configuración de un valor finito para max_standby_archive_delay o max_standby_streaming_delay puede considerarse similar a la configuración de statement_timeout.

Existen posibilidades de remediación si el número de cancelaciones de consultas del standby resulta inaceptable. La primera opción es configurar el parámetro hot_standby_feedback, que evita que VACUUM elimine las filas muertas recientemente y, por lo tanto, no se producen conflictos de limpieza. Si haces esto, debes tener en cuenta que esto retrasará la limpieza de las filas muertas en el primario, lo que puede dar lugar a un hinchamiento (bloat) indeseable de las tablas. Sin embargo, la situación de la limpieza no será peor que si las consultas del standby se ejecutaran directamente en el servidor primario, y sigues obteniendo el beneficio de descargar la ejecución en el standby. Si los servidores standby se conectan y desconectan con frecuencia, es posible que desees realizar ajustes para gestionar el período en el que no se proporciona la retroalimentación de hot_standby_feedback. Por ejemplo, considera aumentar max_standby_archive_delay para que las consultas no se cancelen rápidamente por conflictos en los archivos de almacenamiento de WAL durante los períodos de desconexión. También deberías considerar aumentar max_standby_streaming_delay para evitar cancelaciones rápidas por entradas de WAL en flujo recién llegadas después de la reconexión.

El número de cancelaciones de consultas y el motivo de las mismas se pueden ver utilizando la vista del sistema pg_stat_database_conflicts en el servidor standby. La vista del sistema pg_stat_database también contiene información resumida.

Los usuarios pueden controlar si se produce un mensaje de registro cuando la reproducción de WAL está esperando conflictos durante más tiempo que deadlock_timeout. Esto se controla mediante el parámetro log_recovery_conflict_waits.

Si hot_standby está configurado en on en postgresql.conf (el valor predeterminado) y hay un archivo standby.signal presente, el servidor se ejecutará en modo hot standby. Sin embargo, puede tomar algún tiempo para que se permitan las conexiones de hot standby, porque el servidor no aceptará conexiones hasta que haya completado la recuperación suficiente para proporcionar un estado consistente contra el cual se puedan ejecutar las consultas. Durante este período, a los clientes que intenten conectarse se les rechazará con un mensaje de error. Para confirmar que el servidor se ha iniciado, realiza un bucle intentando conectarte desde la aplicación o busca estos mensajes en los registros del servidor:

LOG:  entering standby mode

... luego, algún tiempo después ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections

La información de consistencia se registra una vez por punto de control en el primario. No es posible habilitar el hot standby cuando se lee un WAL escrito durante un período en el que wal_level no estaba configurado en replica o logical en el primario. Incluso después de alcanzar un estado consistente, es posible que la captura instantánea de recuperación no esté lista para hot standby si se cumplen las dos condiciones siguientes, lo que retrasa la aceptación de conexiones de solo lectura. Para habilitar el hot standby, se deben cerrar en el primario las transacciones de escritura de larga duración con más de 64 subtransacciones.

Si estás ejecutando el envío de registros basado en archivos ("warm standby"), es posible que debas esperar hasta que llegue el siguiente archivo WAL, lo que podría ser tan largo como la configuración de archive_timeout en el primario.

La configuración de algunos parámetros determina el tamaño de la memoria compartida para el seguimiento de los IDs de transacción, los bloqueos y las transacciones preparadas. Estas estructuras de memoria compartida no deben ser menores en un standby que en el primario para garantizar que el standby no se quede sin memoria compartida durante la recuperación. Por ejemplo, si el primario hubiera utilizado una transacción preparada pero el standby no hubiera asignado ninguna memoria compartida para el seguimiento de las transacciones preparadas, la recuperación no podría continuar hasta que se cambie la configuración del standby. Los parámetros afectados son:

La forma más sencilla de garantizar que esto no se convierta en un problema es configurar estos parámetros en los standbys con valores iguales o superiores a los del primario. Por lo tanto, si deseas aumentar estos valores, debes hacerlo primero en todos los servidores standby, antes de aplicar los cambios al servidor primario. Por el contrario, si deseas disminuir estos valores, debes hacerlo primero en el servidor primario, antes de aplicar los cambios a todos los servidores standby. Ten en cuenta que cuando se promueve un standby, este se convierte en la nueva referencia para la configuración de parámetros requerida para los standbys que le siguen. Por lo tanto, para evitar que esto se convierta en un problema durante un cambio de rol o conmutación por error, se recomienda mantener estos parámetros con la misma configuración en todos los servidores standby.

El WAL realiza un seguimiento de los cambios de estos parámetros en el primario. Si un hot standby procesa un WAL que indica que el valor actual en el primario es mayor que su propio valor, registrará una advertencia y pausará la recuperación, por ejemplo:

WARNING:  hot standby is not possible because of insufficient parameter settings
DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
LOG:  recovery has paused
DETAIL:  If recovery is unpaused, the server will shut down.
HINT:  You can then restart the server after making the necessary configuration changes.

En ese momento, es necesario actualizar la configuración del standby y reiniciar la instancia antes de que pueda continuar la recuperación. Si el standby no es un hot standby, cuando encuentre el cambio de parámetro incompatible, se apagará inmediatamente sin pausar, ya que entonces no tiene valor mantenerlo activo.

Es importante que el administrador seleccione la configuración adecuada para max_standby_archive_delay y max_standby_streaming_delay. Las mejores opciones varían en función de las prioridades del negocio. Por ejemplo, si el servidor está asignado principalmente como un servidor de alta disponibilidad, desearás configuraciones de retraso bajas, tal vez incluso cero, aunque esa es una configuración muy agresiva. Si el servidor standby está asignado como un servidor adicional para consultas de soporte de decisiones, podría ser aceptable configurar los valores de retraso máximo en muchas horas, o incluso -1, lo que significa esperar indefinidamente a que se completen las consultas.

Los "bits de pista" (hint bits) de estado de transacción escritos en el primario no se registran en el WAL, por lo que los datos en el standby probablemente volverán a escribir las pistas en el standby. Por lo tanto, el servidor standby seguirá realizando escrituras en el disco a pesar de que todos los usuarios sean de solo lectura; no se producen cambios en los valores de los datos en sí. Los usuarios seguirán escribiendo archivos temporales de ordenación grandes y volverán a generar archivos de información relcache, por lo que ninguna parte de la base de datos es verdaderamente de solo lectura durante el modo hot standby. Ten en cuenta también que las escrituras en bases de datos remotas utilizando el módulo dblink y otras operaciones fuera de la base de datos utilizando funciones PL seguirán siendo posibles, a pesar de que la transacción sea de solo lectura localmente.

Los siguientes tipos de comandos de administración no se aceptan durante el modo de recuperación:

Nuevamente, ten en cuenta que algunos de estos comandos en realidad están permitidos durante las transacciones en modo "solo lectura" en el primario.

Como resultado, no puedes crear índices adicionales que existan únicamente en el standby, ni estadísticas que existan únicamente en el standby. Si se necesitan estos comandos de administración, deben ejecutarse en el primario, y eventualmente esos cambios se propagarán al standby.

pg_cancel_backend() y pg_terminate_backend() funcionarán en los backends de los usuarios, pero no en el proceso de inicio (startup), que realiza la recuperación. pg_stat_activity no muestra las transacciones en recuperación como activas. Como resultado, pg_prepared_xacts está siempre vacía durante la recuperación. Si deseas resolver transacciones preparadas dudosas, visualiza pg_prepared_xacts en el primario y emite comandos para resolver las transacciones allí o resuélvelas después del final de la recuperación.

pg_locks mostrará los bloqueos mantenidos por los backends, como es habitual. pg_locks también muestra una transacción virtual gestionada por el proceso de inicio que posee todos los AccessExclusiveLocks mantenidos por las transacciones que están siendo reproducidas por la recuperación. Ten en cuenta que el proceso de inicio no adquiere bloqueos para realizar cambios en la base de datos y, por lo tanto, los bloqueos que no sean AccessExclusiveLocks no se muestran en pg_locks para el proceso de inicio; simplemente se presume que existen.

El plugin de Nagios check_pgsql funcionará, porque la información simple que comprueba existe. El script de monitoreo check_postgres también funcionará, aunque algunos valores reportados podrían dar resultados diferentes o confusos. Por ejemplo, el tiempo del último vacuum no se mantendrá, ya que no se produce ningún vacuum en el standby. Los vacuums que se ejecutan en el primario siguen enviando sus cambios al standby.

Los comandos de control de archivos WAL no funcionarán durante la recuperación, por ejemplo, pg_backup_start, pg_switch_wal, etc.

Los módulos cargables dinámicamente funcionan, incluido pg_stat_statements.

Los bloqueos recomendados (advisory locks) funcionan normalmente en la recuperación, incluida la detección de deadlocks. Ten en cuenta que los bloqueos recomendados nunca se registran en el WAL, por lo que es imposible que un bloqueo recomendado en el primario o en el standby entre en conflicto con la reproducción de WAL. Tampoco es posible adquirir un bloqueo recomendado en el primario y hacer que inicie un bloqueo recomendado similar en el standby. Los bloqueos recomendados se refieren únicamente al servidor en el que se adquieren.

Los sistemas de replicación basados en disparadores como Slony, Londiste y Bucardo no se ejecutarán en absoluto en el standby, aunque se ejecutarán felizmente en el servidor primario siempre que los cambios no se envíen a los servidores standby para ser aplicados. La reproducción de WAL no se basa en disparadores, por lo que no se puede retransmitir desde el standby a ningún sistema que requiera escrituras adicionales en la base de datos o que dependa del uso de disparadores.

No se pueden asignar nuevos OIDs, aunque algunos generadores de UUID pueden seguir funcionando siempre que no dependan de escribir un nuevo estado en la base de datos.

Actualmente, no se permite la creación de tablas temporales durante las transacciones de solo lectura, por lo que en algunos casos los scripts existentes no se ejecutarán correctamente. Esta restricción podría relajarse en una versión posterior. Esto es tanto un problema de cumplimiento del estándar SQL como un problema técnico.

DROP TABLESPACE solo puede tener éxito si el espacio de tablas está vacío. Algunos usuarios del standby pueden estar utilizando activamente el espacio de tablas a través de su parámetro temp_tablespaces. Si hay archivos temporales en el espacio de tablas, todas las consultas activas se cancelan para garantizar que se eliminen los archivos temporales, de modo que se pueda eliminar el espacio de tablas y continuar la reproducción de WAL.

Ejecutar DROP DATABASE o ALTER DATABASE ... SET TABLESPACE en el primario generará una entrada WAL que hará que todos los usuarios conectados a esa base de datos en el standby sean desconectados a la fuerza. Esta acción ocurre inmediatamente, independientemente de la configuración de max_standby_streaming_delay. Ten en cuenta que ALTER DATABASE ... RENAME no desconecta a los usuarios, lo que en la mayoría de los casos pasará desapercibido, aunque en algunos casos podría causar confusión en el programa si depende de alguna manera del nombre de la base de datos.

En el modo normal (no de recuperación), si emites DROP USER o DROP ROLE para un rol con capacidad de inicio de sesión mientras ese usuario aún está conectado, no le ocurre nada al usuario conectado — permanece conectado. Sin embargo, el usuario no puede volver a conectarse. Este comportamiento también se aplica en la recuperación, por lo que un DROP USER en el primario no desconecta a ese usuario en el standby.

El sistema de estadísticas acumulativas está activo durante la recuperación. Todos los escaneos, lecturas, bloques, uso de índices, etc., se registrarán normalmente en el standby. Sin embargo, la reproducción de WAL no incrementará los contadores específicos de la relación y de la base de datos. Es decir, la reproducción no incrementará las columnas de pg_stat_all_tables (como n_tup_ins), ni se realizará un seguimiento de las lecturas o escrituras realizadas por el proceso de inicio en las vistas pg_statio_, ni se incrementarán las columnas asociadas de pg_stat_database.

Autovacuum no está activo durante la recuperación. Se iniciará normalmente al final de la recuperación.

El proceso checkpointer y el proceso background writer están activos durante la recuperación. El proceso checkpointer realizará puntos de reinicio (restartpoints, similares a los checkpoints en el primario) y el proceso background writer realizará actividades normales de limpieza de bloques. Esto puede incluir actualizaciones de la información de bits de pista almacenada en el servidor standby. El comando CHECKPOINT se acepta durante la recuperación, aunque realiza un punto de reinicio en lugar de un nuevo punto de control.

Arriba se han mencionado varios parámetros en la Section 26.4.2 y la Section 26.4.3.

En el primario, se puede utilizar el parámetro wal_level. max_standby_archive_delay y max_standby_streaming_delay no tienen efecto si se configuran en el primario.

En el standby, se pueden utilizar los parámetros hot_standby, max_standby_archive_delay y max_standby_streaming_delay.

Existen varias limitaciones del hot standby. Estas pueden y probablemente se solucionarán en versiones futuras: