La nueva función Hot Standby en el próximo PostgreSQL 9.0 permite ejecutar consultas en nodos en espera que anteriormente no hacían más que ejecutar un proceso de recuperación. Dos expectativas comunes que escuché de los usuarios que anticipan esta función es que permitirá distribuir consultas cortas en ambos nodos o ejecutar informes largos en el modo de espera sin usar recursos en el maestro. Ambos son posibles de hacer en este momento, pero a menos que comprenda las compensaciones involucradas en cómo funciona Hot Standby, puede haber un comportamiento inesperado aquí.
Consultas estándar de ejecución prolongada
Uno de los problemas tradicionales en una base de datos que usa MVCC, como PostgreSQL, es que una consulta de ejecución prolongada debe mantener abierto un recurso, denominado instantánea en la implementación actual de Postgres, para evitar que la base de datos elimine los datos que la consulta necesita. funcionar. Por ejemplo, solo porque otro cliente eliminó una fila y se comprometió, si una consulta que ya se está ejecutando necesita esa fila para completarse, no puede borrar los bloques del disco físico relacionados con esa fila todavía. Debe esperar hasta que no queden consultas abiertas que esperen que esa fila sea visible.
Limitaciones del modo de espera activo
Si tiene una consulta de ejecución prolongada que desea que Hot Standby ejecute, hay un par de tipos de cosas malas que pueden ocurrir cuando el proceso de recuperación está aplicando actualizaciones. Estos se describen en detalle en la Documentación de Hot Standby. Algunas de estas cosas malas harán que las consultas que se ejecutan en espera se cancelen por razones que pueden no ser intuitivamente obvias:
- Llega una actualización HOT o una actualización relacionada con VACUUM para eliminar algo que la consulta espera que sea visible
- Aparece una eliminación de árbol B
- Hay un problema de bloqueo entre la consulta que está ejecutando y los bloqueos necesarios para que se procese la actualización.
La situación de bloqueo es difícil de manejar, pero no es muy probable que suceda en la práctica durante tanto tiempo si solo está ejecutando consultas de solo lectura en espera, porque se aislarán a través de MVCC. Los otros dos no son difíciles de encontrar. Lo básico que hay que entender es que cualquier ACTUALIZAR o ELIMINAR en el maestro puede provocar la interrupción de cualquier consulta en el standby; no importa si los cambios se relacionan con lo que está haciendo la consulta.
Bueno, rápido, barato:elige dos
Esencialmente, hay tres cosas que la gente podría querer priorizar:
- Evite la limitación del maestro:permita que los xid y las instantáneas asociadas avancen sin límites en el maestro, de modo que VACUUM y la limpieza similar no se vean obstaculizadas por lo que está haciendo el modo de espera
- Consultas ilimitadas:ejecute consultas en espera durante cualquier período de tiempo arbitrario
- Recuperación actual:mantenga el proceso de recuperación en espera actualizado con lo que sucede en el maestro, lo que permite una conmutación por error rápida para HA
En cualquier situación con Hot Standby, es literalmente imposible tener los tres a la vez. Solo puede elegir su compensación. Los parámetros ajustables disponibles ya le permiten optimizar de un par de formas:
- La desactivación de todas estas configuraciones de retraso/diferir optimiza la recuperación siempre actual, pero luego descubrirá que es más probable que las consultas se cancelen de lo que podría esperar.
- retraso_en_espera_máximo optimiza para consultas más largas, a expensas de mantener la recuperación actualizada. Esto retrasa la aplicación de actualizaciones al modo de espera una vez que aparece una que causará un problema (HOT, VACUUM, B-tree delete, etc.).
- vacuum_defer_cleanup_age y algunos trucos de instantáneas pueden introducir una limitación maestra para mejorar los otros dos problemas, pero con una interfaz de usuario débil para hacerlo. vacuum_defer_cleanup_age está en unidades de ID de transacción. Debe tener una idea de la cantidad promedio de rotación de xid en su sistema por unidad de tiempo para convertir la forma en que la gente piensa sobre este problema ("aplazar al menos 1 hora para que mis informes se ejecuten") en una configuración para este valor. la tasa de consumo de xid simplemente no es algo común o incluso razonable para medir/predecir. Como alternativa, puede abrir una instantánea en el principal antes de iniciar una consulta de larga duración en el standby. dblink se sugiere en la documentación de Hot Standby como una forma de lograrlo. Teóricamente, un daemon en el modo de espera podría escribirse en la tierra del usuario, viviendo en el primario, para solucionar este problema también (Simon tiene un diseño básico para uno). Básicamente, inicia una serie de procesos en los que cada uno adquiere una instantánea y luego duerme durante un período antes de liberarlo. Al espaciar cuánto tiempo durmieron cada uno, podría asegurarse de que las instantáneas de xid nunca avanzaran demasiado rápido en el maestro. Ya debería sonar obvio lo terrible que sería esto.
Mejoras potenciales
El único de estos que realmente puede hacer algo limpiamente es ajustar y mejorar la interfaz de usuario para la limitación maestra. Eso convierte esto en el problema tradicional que ya está presente en la base de datos:una consulta de ejecución prolongada mantiene abierta una instantánea (o al menos limita el avance de los ID de transacción relacionados con la visibilidad) en el maestro, evitando que el maestro elimine las cosas necesarias para que la consulta funcione. completo. Alternativamente, puede pensar en esto como un ajuste automático de vacío_defer_cleanup_age.
La pregunta es cómo hacer que el primario respetar las necesidades de las consultas de ejecución prolongada en el espera . Esto podría ser posible si se compartiera con el maestro más información sobre los requisitos de visibilidad de transacciones del standby. Hacer ese tipo de intercambio realmente sería algo más apropiado para compartir con la nueva implementación de Streaming Replication. La forma en que se aprovisiona un servidor Hot Standby simple no proporciona ninguna retroalimentación hacia el maestro adecuado para que se intercambien estos datos, además de enfoques como el hack de dblink ya mencionado.
Con PostgreSQL 9.0 apenas alcanzando una cuarta versión alfa, puede haber Aún será tiempo de ver algunas mejoras en esta área antes del lanzamiento de la versión 9.0. Sería bueno ver Hot Standby y Streaming Replication realmente integrados de una manera que logre cosas que ninguno de los dos es completamente capaz de hacer por sí solo antes de que la codificación en esta versión se congele por completo.
