Postgresql Hot Standby

26.5.1. Resumen del usuario

26.5.2. Manejo de conflictos de consultas

26.5.3. Descripción general del administrador

26.5.4. Referencia de parámetros de Hot Standby

26.5.5. Advertencias

Hot Standby es el término que se utiliza para describir la capacidad de conectarse al servidor y ejecutar consultas de solo lectura mientras el servidor está en modo de recuperación de archivo o en modo de espera. Esto es útil tanto para fines de replicación como para restaurar una copia de seguridad al estado deseado con gran precisión. El término Hot Standby también se refiere a la capacidad del servidor para pasar de la recuperación al funcionamiento normal mientras los usuarios continúan ejecutando consultas y / o mantienen abiertas sus conexiones.

La ejecución de consultas en el modo de espera activa es similar a la operación de consulta normal, aunque existen varias diferencias administrativas y de uso que se explican a continuación.

26.5.1. Resumen del usuario

Cuando el parámetro hot_standby se establece en verdadero en un servidor en espera, comenzará a aceptar conexiones una vez que la recuperación haya llevado el sistema a un estado coherente. Todas estas conexiones son estrictamente de solo lectura; ni siquiera se pueden escribir tablas temporales.

Los datos en espera tardan algún tiempo en llegar desde el servidor principal, por lo que habrá un retraso medible entre el servidor primario y el modo de espera. Por lo tanto, ejecutar la misma consulta casi simultáneamente tanto en el modo principal como en el modo de espera podría arrojar resultados diferentes. Decimos que los datos en espera son eventualmente consistente con la primaria. Una vez que el registro de confirmación de una transacción se reproduce en el modo de espera, los cambios realizados por esa transacción serán visibles para cualquier nueva instantánea tomada en el modo de espera. Se pueden tomar instantáneas al comienzo de cada consulta o al comienzo de cada transacción, según el nivel de aislamiento de la transacción actual. Para obtener más detalles, consulte la Sección 13.2.

Las transacciones iniciadas durante el modo de espera activo pueden emitir los siguientes comandos:

• Acceso a consultas: SELECT, COPY TO

• Comandos del cursor: DECLARE, FETCH, CLOSE

• Ajustes: SHOW, SET, RESET

• Comandos de gestión de transacciones:

  • BEGIN, END, ABORT, START TRANSACTION

  • SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT

  • EXCEPTION bloques y otras subtransacciones internas

• LOCK TABLE, aunque solo cuando está explícitamente en uno de estos modos: ACCESS SHARE, ROW SHARE o ROW EXCLUSIVE.

• Planes y recursos: PREPARE, EXECUTE, DEALLOCATE, DISCARD

• Complementos y extensiones: LOAD

• UNLISTEN

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

• Lenguaje de manipulación de datos (DML): INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE. Tenga en cuenta que no hay acciones permitidas que provoquen la ejecución de un desencadenador durante la recuperación. Esta restricción se aplica incluso a las tablas temporales, porque las filas de la tabla no se pueden leer ni escribir sin asignar un ID de transacción, lo que actualmente no es posible en un entorno Hot Standby.

• Lenguaje de definición de datos (DDL): CREATE, DROP, ALTER, COMMENT. Esta restricción se aplica incluso a las tablas temporales, ya que para realizar estas operaciones sería necesario actualizar las tablas del catálogo del sistema.

• SELECT ... FOR SHARE | UPDATE, porque los bloqueos de filas no se pueden realizar sin actualizar los archivos de datos subyacentes.

• Reglas sobre SELECT declaraciones que generan comandos DML.

• LOCK que solicita explícitamente un modo superior a ROW EXCLUSIVE MODE.

• LOCK en forma corta por defecto, ya que solicita ACCESS EXCLUSIVE MODE.

• Comandos de administración de transacciones que establecen explícitamente un estado que no es de solo lectura:

  • BEGIN READ WRITE, START TRANSACTION READ WRITE

  • SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE

  • SET transaction_read_only = off

• Comandos de confirmación de dos fases: PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED porque incluso las transacciones de solo lectura necesitan escribir WAL en la fase de preparación (la primera fase de la confirmación de dos fases).

• Actualizaciones de secuencia: nextval(), setval()

• LISTEN, NOTIFY

En funcionamiento normal, “solo lectura“ las transacciones pueden usar LISTEN y NOTIFY, por lo que las sesiones de Hot Standby funcionan con restricciones un poco más estrictas que las sesiones de solo lectura normales. Es posible que algunas de estas restricciones se relajen en una versión futura.

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

Los usuarios podrán saber si su sesión es de solo lectura emitiendo SHOW transaction_read_only. Además, un conjunto de funciones (Tabla 9.86) permite a los usuarios acceder a información sobre el servidor en espera. Estos le permiten escribir programas que conocen el estado actual de la base de datos. Estos se pueden usar para monitorear el progreso de la recuperación o para permitirle escribir programas complejos que restauren la base de datos a estados particulares.

26.5.2. Manejo de conflictos de consultas

Los servidores primario y en espera están conectados de muchas maneras de manera flexible. Las acciones en el primario tendrán un efecto en el modo de espera. 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 gran carga de datos en el primario, esto generará un flujo similar de registros WAL en el modo de espera, por lo que las consultas en espera pueden competir por recursos del sistema, como E / S.

También hay otros tipos de conflictos que pueden ocurrir con Hot Standby. Estos conflictos son conflictos duros en el sentido de que es posible que sea necesario cancelar consultas y, en algunos casos, desconectar sesiones para resolverlas. El usuario dispone de varias formas de manejar estos conflictos. Los casos de conflicto incluyen:

• Acceda a bloqueos exclusivos tomados en el servidor primario, incluidos ambos explícitos LOCK comandos y varias acciones DDL, entran en conflicto con los accesos a la tabla en las consultas en espera.

• Dejar caer un espacio de tabla en los conflictos primarios con consultas en espera utilizando ese espacio de tabla para archivos de trabajo temporales.

• Dejar caer una base de datos en la primaria entra en conflicto con las sesiones conectadas a esa base de datos en el modo de espera.

• La aplicación de un registro de limpieza de vacío de WAL entra en conflicto con transacciones en espera cuyas instantáneas aún pueden “ver“ cualquiera de las filas que se eliminarán.

• La aplicación de un registro de limpieza de vacío de WAL entra en conflicto con las consultas que acceden a la página de destino en el modo de espera, ya sea que los datos que se eliminarán estén visibles o no.

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

Un ejemplo de la situación del problema es un administrador en el servidor primario que ejecuta DROP TABLE en una tabla que se está consultando actualmente en el servidor en espera. Claramente, la consulta en espera no puede continuar si el DROP TABLE se aplica en el modo de espera. Si esta situación ocurrió en la primaria, el DROP TABLE esperaría hasta que la otra consulta hubiera terminado. Pero cuando DROP TABLE se ejecuta en el primario, el primario no tiene información acerca de las consultas que se están ejecutando en el modo de espera, por lo que no esperará ninguna de esas consultas en espera. Los registros de cambios de WAL pasan al modo en espera mientras la consulta en espera aún se está ejecutando, lo que provoca un conflicto. El servidor en espera debe retrasar la aplicación de los registros WAL (y todo lo que sigue a ellos también) o bien cancelar la consulta en conflicto para que el DROP TABLE puede ser aplicado.

Cuando una consulta conflictiva es corta, normalmente es deseable permitir que se complete retrasando un poco la aplicación de WAL; pero por lo general no es deseable un retraso prolongado en la aplicación de WAL. Entonces, 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 WAL. Las consultas en conflicto se cancelarán una vez que se haya demorado más que la configuración de demora correspondiente para aplicar los datos WAL recién recibidos. Hay dos parámetros para que se puedan especificar diferentes valores de retardo para el caso de leer datos WAL desde un archivo (es decir, recuperación inicial desde una copia de seguridad base o “alcanzando“ un servidor en espera que se ha quedado muy atrás) en comparación con la lectura de datos WAL a través de la replicación de transmisión.

En un servidor en espera que existe principalmente para alta disponibilidad, es mejor establecer los parámetros de demora relativamente cortos, de modo que el servidor no se quede muy atrás del primario debido a demoras causadas por consultas en espera. Sin embargo, si el servidor en espera está diseñado para ejecutar consultas de larga duración, puede ser preferible un valor de retraso alto o incluso infinito. Sin embargo, tenga en cuenta que una consulta de larga duración podría hacer que otras sesiones en el servidor en espera no vean los cambios recientes en el primario, si retrasa la aplicación de los registros WAL.

Una vez que el retraso especificado por max_standby_archive_delay o max_standby_streaming_delay se ha superado, las consultas en conflicto se cancelarán. Por lo general, esto solo da como resultado un error de cancelación, aunque en el caso de reproducir un DROP DATABASE se terminará toda la sesión conflictiva. Además, si el conflicto se debe a un bloqueo mantenido por una transacción inactiva, la sesión en conflicto finaliza (este comportamiento puede cambiar en el futuro).

Las consultas canceladas se pueden reintentar 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 reproducen, una consulta que se canceló puede tener éxito si se vuelve a ejecutar.

Tenga en cuenta que los parámetros de retardo se comparan con el tiempo transcurrido desde que el servidor en espera recibió los datos WAL. Por lo tanto, el período de gracia permitido para cualquier consulta en el modo de espera nunca es mayor que el parámetro de retardo, y podría ser considerablemente menor si el modo de espera ya se ha retrasado como resultado de esperar a que se completen las consultas anteriores o como resultado de ser incapaz de mantenerse al día con una gran carga de actualización.

El motivo más común de conflicto entre las consultas en espera y la reproducción de WAL es “limpieza temprana“. Normalmente, PostgreSQL permite la limpieza de versiones de filas antiguas cuando no hay transacciones que necesiten verlas para garantizar la visibilidad correcta de los datos de acuerdo con las reglas de MVCC. Sin embargo, esta regla solo se puede aplicar a las transacciones que se ejecutan en el maestro. Por lo tanto, es posible que la limpieza en el maestro elimine las versiones de fila que aún son visibles para una transacción en el modo de espera.

Los usuarios experimentados deben tener en cuenta que tanto la limpieza de la versión de la fila como la congelación de la versión de la fila pueden entrar en conflicto con las consultas en espera. Ejecutando un manual VACUUM FREEZE es probable que cause conflictos incluso en tablas sin filas actualizadas o eliminadas.

Los usuarios deben tener claro que las tablas que se actualizan con regularidad y en gran medida en el servidor primario causarán rápidamente cancelación de consultas de ejecución más prolongada en el modo de espera. En tales casos, el establecimiento de un valor finito para max_standby_archive_delay o max_standby_streaming_delay puede considerarse similar a la configuración statement_timeout.

Existen posibilidades de reparación si se determina que el número de cancelaciones de consultas en espera es inaceptable. La primera opción es configurar el parámetro hot_standby_feedback, que previene VACUUM de eliminar filas recientemente muertas y, por lo tanto, no se produzcan conflictos de limpieza. Si hace esto, debe tener en cuenta que esto retrasará la limpieza de filas muertas en el primario, lo que puede resultar en una hinchazón indeseable de la tabla. Sin embargo, la situación de limpieza no será peor que si las consultas en espera se estuvieran ejecutando directamente en el servidor primario y aún así obtiene el beneficio de descargar la ejecución en el modo de espera. Si los servidores en espera se conectan y desconectan con frecuencia, es posible que desee realizar ajustes para manejar el período en el que hot_standby_feedback no se proporciona retroalimentación. Por ejemplo, considere aumentar max_standby_archive_delay para que las consultas no se cancelen rápidamente por conflictos en los archivos WAL durante períodos desconectados. También debería considerar aumentar max_standby_streaming_delay para evitar cancelaciones rápidas por entradas WAL de transmisión por secuencias recién llegadas después de la reconexión.

Otra opción es aumentar el valor de vacuum_defer_cleanup_age en el servidor principal, de modo que las filas muertas no se limpien tan rápido como lo haría normalmente. Esto permitirá más tiempo para que las consultas se ejecuten antes de que se cancelen en el modo de espera, sin tener que establecer un valor alto. max_standby_streaming_delay. Sin embargo, es difícil garantizar una ventana de tiempo de ejecución específica con este enfoque, ya que vacuum_defer_cleanup_age se mide en transacciones ejecutadas en el servidor primario.

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

26.5.3. Descripción general del administrador

Si hot_standby es on en postgresql.conf (el valor predeterminado) y hay un standby.signal presente, el servidor se ejecutará en modo Hot Standby. Sin embargo, las conexiones Hot Standby pueden tardar algún tiempo en permitirse, ya que el servidor no aceptará conexiones hasta que haya completado la recuperación suficiente para proporcionar un estado coherente en el que se puedan ejecutar las consultas. Durante este período, los clientes que intenten conectarse serán rechazados con un mensaje de error. Para confirmar que el servidor ha aparecido, haga un bucle intentando conectarse desde la aplicación o busque estos mensajes en los registros del servidor:

LOG:  entering standby mode

... then some time later ...

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

La información de coherencia se registra una vez por punto de control en el primario. No es posible habilitar el modo de espera activo cuando se lee WAL escrito durante un período en el que wal_level no estaba configurado para replica o logical en la primaria. Alcanzar un estado consistente también puede retrasarse en presencia de estas dos condiciones:

• Una transacción de escritura tiene más de 64 subtransacciones.

• Transacciones de escritura de muy larga duración

Si está ejecutando el trasvase de registros basado en archivos (“espera en caliente”), es posible que deba esperar hasta que llegue el siguiente archivo WAL, que podría ser tan largo como el archive_timeout ajuste en el primario.

La configuración de algunos parámetros en el modo de espera deberá reconfigurarse si se han cambiado en el primario. Para estos parámetros, el valor en el modo de espera debe ser igual o mayor que el valor en el primario. Por lo tanto, si desea aumentar estos valores, primero debe hacerlo en todos los servidores en espera, antes de aplicar los cambios al servidor primario. Por el contrario, si desea reducir estos valores, debe hacerlo en el servidor primario primero, antes de aplicar los cambios a todos los servidores en espera. Si estos parámetros no se establecen lo suficientemente altos, el modo de espera se negará a comenzar. Luego, se pueden proporcionar valores más altos y el servidor se reinicia para comenzar la recuperación nuevamente. Estos parámetros son:

• max_connections

• max_prepared_transactions

• max_locks_per_transaction

• max_wal_senders

• max_worker_processes

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 según las prioridades comerciales. Por ejemplo, si el servidor tiene la tarea principalmente como servidor de alta disponibilidad, entonces querrá una configuración de retraso bajo, quizás incluso cero, aunque esa es una configuración muy agresiva. Si el servidor en espera tiene la tarea de ser un servidor adicional para consultas de soporte de decisiones, entonces podría ser aceptable establecer los valores máximos de retraso en muchas horas, o incluso -1, lo que significa esperar una eternidad para que se completen las consultas.

Los “bits de sugerencia” de estado de transacción escritos en el primario no se registran en WAL, por lo que los datos en el modo de espera probablemente volverán a escribir las pistas en el modo de espera. Por lo tanto, el servidor en espera seguirá realizando escrituras en disco aunque 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 gran tamaño y volverán a generar archivos de información de relcache, por lo que ninguna parte de la base de datos es realmente de solo lectura durante el modo de espera activa. Tenga 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, aunque 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:

• Lenguaje de definición de datos (DDL): p. Ej., CREATE INDEX

• Privilegio y propiedad: GRANT, REVOKE, REASSIGN

• Comandos de mantenimiento: ANALYZE, VACUUM, CLUSTER, REINDEX

Nuevamente, tenga en cuenta que algunos de estos comandos están permitidos durante las transacciones en modo “solo lectura” en el primario.

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

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

pg_locks mostrará bloqueos retenidos por backends, como es normal. pg_locks también muestra una transacción virtual administrada por el proceso de inicio que posee todos AccessExclusiveLocks retenidas por transacciones que se reproducen mediante recuperación. Tenga en cuenta que el proceso de inicio no adquiere bloqueos para realizar cambios en la base de datos y, por lo tanto, bloqueos que no sean AccessExclusiveLocks no aparecer en pg_locks para el proceso de inicio; simplemente se presume que existen.

El complemento de Nagios check_pgsql funcionará, porque la información simple que busca existe. El script de monitoreo check_postgres también funcionará, aunque algunos valores reportados podrían dar resultados diferentes o confusos. Por ejemplo, el último tiempo de vacío no se mantendrá, ya que no se produce vacío en el modo de espera. Las aspiradoras que se ejecutan en el primario aún envían sus cambios al modo de espera.

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

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

Los bloqueos de aviso funcionan normalmente en recuperación, incluida la detección de interbloqueo. Tenga en cuenta que los bloqueos de aviso nunca se registran en WAL, por lo que es imposible que un bloqueo de aviso en el primario o en el modo de espera entre en conflicto con la reproducción de WAL. Tampoco es posible adquirir un bloqueo de aviso en el primario y hacer que inicie un bloqueo de aviso similar en el modo de espera. Los bloqueos de aviso se relacionan únicamente con el servidor en el que se adquieren.

Los sistemas de replicación basados ​​en disparadores como Slony, Londiste y Bucardo no se ejecutarán en el modo de espera en absoluto, aunque se ejecutarán sin problemas en el servidor principal siempre que los cambios no se envíen a los servidores de reserva para su aplicación. La reproducción de WAL no se basa en disparadores, por lo que no puede retransmitir desde el modo de espera a ningún sistema que requiera escrituras adicionales en la base de datos o dependa del uso de disparadores.

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

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

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

Corriendo 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 modo de espera se desconecten a la fuerza. Esta acción se produce de inmediato, sea cual sea la configuración de max_standby_streaming_delay. Tenga 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 modo normal (sin recuperación), si emite DROP USER o DROP ROLE para un rol con capacidad de inicio de sesión mientras ese usuario todavía está conectado, no le sucede 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 modo de espera.

El recopilador de estadísticas está activo durante la recuperación. Todos los escaneos, lecturas, bloqueos, uso de índices, etc., se registrarán normalmente en el modo de espera. Las acciones repetidas no duplicarán sus efectos en el primario, por lo que la reproducción de una inserción no incrementará la columna Inserciones de pg_stat_user_tables. El archivo de estadísticas se elimina al inicio de la recuperación, por lo que las estadísticas del primario y del modo de espera serán diferentes; esto se considera una característica, no un error.

El autovacío no está activo durante la recuperación. Comenzará normalmente al final de la recuperación.

El proceso de puntero de verificación y el proceso de escritura en segundo plano están activos durante la recuperación. El proceso de puntero de verificación realizará puntos de reinicio (similar a los puntos de control en el primario) y el proceso de escritura en segundo plano realizará actividades normales de limpieza de bloques. Esto puede incluir actualizaciones de la información de bits de sugerencia almacenada en el servidor en espera. los CHECKPOINT El comando se acepta durante la recuperación, aunque realiza un punto de reinicio en lugar de un nuevo punto de control.

26.5.4. Referencia de parámetros de Hot Standby

Se han mencionado varios parámetros anteriormente en la Sección 26.5.2 y la Sección 26.5.3.

En el primario, se pueden usar los parámetros wal_level y vacuum_defer_cleanup_age. max_standby_archive_delay y max_standby_streaming_delay no tienen efecto si se configuran en el primario.

En el modo de espera, se pueden utilizar los parámetros hot_standby, max_standby_archive_delay y max_standby_streaming_delay. vacuum_defer_cleanup_age no tiene ningún efecto mientras el servidor permanezca en modo de espera, aunque será relevante si el modo de espera se convierte en primario.

26.5.5. Advertencias

Hay varias limitaciones de Hot Standby. Estos pueden y probablemente se solucionarán en versiones futuras:

• Se requiere un conocimiento completo de las transacciones en ejecución antes de poder tomar instantáneas. Las transacciones que utilizan un gran número de subtransacciones (actualmente más de 64) retrasarán el inicio de las conexiones de solo lectura hasta la finalización de la transacción de escritura más larga. Si ocurre esta situación, se enviarán mensajes explicativos al registro del servidor.

• Puntos de partida válidos para Las consultas en espera se generan en cada punto de control del maestro. Si el modo de espera se apaga mientras el maestro está en un estado de apagado, es posible que no sea posible volver a ingresar al modo de espera en caliente hasta que se inicie el primario, de modo que genere más puntos de inicio en los registros de WAL. Esta situación no es un problema en las situaciones más comunes en las que podría suceder. En general, si el primario está apagado y ya no está disponible, es probable que se deba a una falla grave que requiere que el modo de espera se convierta para operar como el nuevo primario de todos modos. Y en situaciones en las que el primario se retira intencionalmente, la coordinación para asegurarse de que el modo de espera se convierta en el nuevo primario sin problemas también es un procedimiento estándar.

• Al final de la recuperación, AccessExclusiveLocks retenidas por transacciones preparadas requerirán el doble del número normal de entradas de la tabla de bloqueo. Si planea ejecutar una gran cantidad de transacciones preparadas simultáneas que normalmente requieren AccessExclusiveLocks, o planea tener una gran transacción que requiera muchos AccessExclusiveLocks, se recomienda seleccionar un valor mayor de max_locks_per_transaction, quizás hasta el doble del valor del parámetro en el servidor primario. No necesita considerar esto en absoluto si su configuración de max_prepared_transactions es 0.

• El nivel de aislamiento de transacciones serializables aún no está disponible en espera activa. (Consulte la Sección 13.2.3 y la Sección 13.4.1 para obtener más detalles.) Un intento de establecer una transacción en el nivel de aislamiento serializable en el modo de espera activa generará un error.