Agrupación de conexiones de PostgreSQL:Parte 3:Pgpool-II

En nuestras publicaciones anteriores de esta serie, discutimos el caso de la agrupación de conexiones y presentamos PgBouncer. En esta publicación, analizaremos su alternativa más popular:Pgpool-II.

Pgpool-II es la navaja suiza del middleware de PostgreSQL. Admite alta disponibilidad, proporciona equilibrio de carga automatizado y tiene la inteligencia para equilibrar la carga entre maestros y esclavos, de modo que las cargas de escritura siempre se dirijan a los maestros, mientras que las cargas de lectura se dirijan a los esclavos. Pgpool-II también proporciona replicación lógica. Si bien su uso e importancia han disminuido a medida que las opciones de replicación incorporadas mejoraron en el lado del servidor de PostgreSQL, esta sigue siendo una opción valiosa para las versiones anteriores de PostgreSQL. ¡Además de todo esto, también proporciona agrupación de conexiones!

De un vistazo

Configuración de Pgpool-II Siga estos pasos para configurar Pgpool-II, habilitar los servicios de grupo de conexiones que necesita y conectarse a su servidor PostgreSQL. Leer ahora Cómo funciona Consulte la arquitectura Pgpool-II que admite todas sus funciones y aprenda cómo funciona el agrupador de conexiones. Leer ahora ¿Qué no hace Pgpool-II? Revise las limitaciones de Pgpool-II para ver si es el agrupador de conexiones adecuado para su aplicación. Leer ahora

Configuración de Pgpool-II

Los archivos binarios de Pgpool-II se distribuyen a través de los repositorios de Pgpool-II; puede leer más sobre la instalación en este documento de ayuda. Una vez instalado, debemos configurar Pgpool-II para habilitar los servicios que queramos, y conectarnos al servidor PostgreSQL. Puedes leer más sobre esto aquí.

Para obtener una configuración de agrupación mínima, debe proporcionar lo siguiente:

• El nombre de usuario y la contraseña encriptada md5 de los usuarios que se conectarán a Pgpool-II; esto debe definirse en un archivo separado, que se puede generar fácilmente usando la utilidad pg_md5.
• Interfaces/direcciones IP y número de puerto para escuchar las conexiones entrantes:esto debe definirse en el archivo de configuración.
• El nombre de host de los servidores back-end [Se especifica más de un servidor solo si deseamos usar replicación y/o balanceo de carga].
• Los servicios que desea habilitar. De forma predeterminada, la agrupación de conexiones está activada y otros servicios están desactivados en el archivo de configuración instalado con los archivos binarios.

Y eso es todo, ¡estamos listos para empezar! Si bien las configuraciones disponibles con Pgpool-II pueden parecer más abrumadoras a primera vista, ¡la gente detrás de Pgpool-II realmente nos lo ha facilitado!

Cómo funciona

Pgpool-II tiene una arquitectura más complicada que PgBouncer para soportar todas las características que tiene. Sin embargo, en esta sección, nos limitaremos a describir cómo funciona la agrupación de conexiones.

El proceso principal de Pgpool-II bifurca 32 procesos secundarios de forma predeterminada; estos están disponibles para la conexión. La arquitectura es similar al servidor PostgreSQL:un proceso =una conexión. También bifurca el 'proceso pcp' que se utiliza para tareas administrativas, y más allá del alcance de esta publicación. Los 32 niños ahora están listos para aceptar conexiones. Al igual que PgBouncer, estos también emulan un servidor PostgreSQL:los clientes pueden conectarse con exactamente la misma cadena de conexión que lo harían con un servidor PostgreSQL normal.

El núcleo dirige las conexiones entrantes a uno de los procesos secundarios que se han registrado como oyentes. Ni el proceso principal de Pgpool-II ni los usuarios finales tienen ningún control sobre qué proceso secundario responde a una solicitud entrante. Cualquier niño inactivo puede recoger la solicitud. Si no se encuentran elementos secundarios inactivos, la solicitud de conexión se pondrá en cola en el lado del kernel; esto puede hacer que aplicaciones como pgbench se cuelguen, esperando las conexiones del cliente.

Una vez que un niño inactivo de Pgpool-II recibe una solicitud de conexión, este:

1. Comprueba el nombre de usuario en su archivo de contraseñas. Si no lo encuentra, rechaza la conexión.
2. Si se encuentra el nombre de usuario, verifica la contraseña provista contra el hash md5 almacenado en este archivo.
3. Una vez que la autenticación tiene éxito, comprueba si ya tiene una conexión en caché para esta combinación de base de datos+usuario.
4. Si lo hace, devuelve la conexión al cliente. Si no lo hace, abre una nueva conexión.
5. Todas las solicitudes y respuestas pasan por Pgpool-II mientras espera que el cliente se desconecte.
6. Una vez que el cliente se desconecta, Pgpool-II tiene que decidir si almacenar en caché la conexión:
   • Si tiene un espacio vacío, lo almacena en caché.
   • Si no tiene una ranura vacía (es decir, almacenar en caché esta conexión excedería el max_pool_size permitido), lo decidirá en función de un algoritmo interno.
7. Si decide almacenar en caché la conexión, ejecutará la consulta de reinicio preconfigurada para limpiar todos los detalles de la sesión y hacerla segura para que la reutilice otro cliente.
8. Ahora el proceso hijo es libre de seleccionar más conexiones.

¿Qué no hace Pgpool-II?

Desafortunadamente, para aquellos que se enfocan solo en la agrupación de conexiones, lo que Pgpool-II no hace muy bien es la agrupación de conexiones, especialmente para una pequeña cantidad de clientes. Debido a que cada proceso secundario tiene su propio grupo y no hay forma de controlar qué cliente se conecta a qué proceso secundario, se deja demasiado a la suerte cuando se trata de reutilizar conexiones.

Como puede ver, Pgpool y PgBouncer tienen fortalezas bastante diferentes:en nuestra publicación final de la serie, haremos una prueba cara a cara. , y comparación de características! ¡Estén atentos!