Alta disponibilidad de PostgreSQL
PostgreSQL 11 debe sincronizar sus datos en todos los nodos para que cada nodo esté actualizado al recibir solicitudes de lectura o escritura. No hay ninguna solución única para eliminar posibles incidencias de sincronización, por lo que hay muchas opciones de alta disponibilidad que se deben tener en cuenta. Se puede consultar una comparación de las soluciones de alta disponibilidad para PostgreSQL 11 como una lista en formato de tabla aquí: https://www.postgresql.org/docs/11/different-replication-solutions.htmll.
En el siguiente diagrama se muestra la configuración recomendada por PTC para una implementación de alta disponibilidad de PostgreSQL.
PostgreSQL
ThingWorx puede escribir una gran cantidad de contenido en su base de datos y es importante mantener la secuencia de escritura intacta en todos los nodos de PostgreSQL. PTC recomienda configurar todos los nodos de PostgreSQL para la replicación sincrónica dentro de una arquitectura de replicación en cascada, y trabajar con las limitaciones que coloca en la replicación sincrónica. Esta opción tiene los siguientes requisitos:
• Se deben implementar tres nodos de servidor PostgreSQL de igual tamaño.
◦ Un nodo será el maestro y las solicitudes de escritura se dirigirán a él. El maestro transmite los registros de WAL a un nodo en espera y solo confirmará las transacciones cuando el nodo en espera lo haya confirmado.
◦ Un nodo en espera para recibir el contenido del flujo del maestro. También transmitirá su contenido a un segundo nodo en espera.
◦ Un nodo en espera adicional para recibir el contenido del flujo del primer nodo en espera. En el caso de que se produzca un fallo de un nodo o de que un nodo se quede fuera de línea, este nodo será uno de los dos restantes y completará el proceso de flujo confirmado por los nodos maestro-en espera.
Pgpool-II
Para completar la configuración de alta disponibilidad de PostgreSQL, las solicitudes de escritura y lectura se deben dirigir al nodo adecuado, se debe supervisar la integridad del nodo y los nodos que no son íntegros se deben colocar fuera de línea y reparar. PTC recomienda Pgpool-II para realizar estas tareas. Esta opción tiene los siguientes requisitos:
• Se deben implementar dos nodos de servidor Pgpool de igual tamaño. Operan en modo activo/pasivo.
◦ Un nodo funciona como maestro. Dirige el tráfico de escritura al nodo maestro de PostgreSQL y lee el tráfico en el nodo en espera de PostgreSQL.
◦ Un nodo que funcione en espera. Se hará cargo de la distribución del tráfico cuando falle el nodo maestro de Pgpool.
• Una dirección IP virtual que se gestionará mediante los nodos de Pgpool-II. El maestro utilizará esta dirección para recibir el tráfico PostgreSQL de los clientes.
Notas sobre Pgpool-II:
• Pgpool-II no se soporta en un entorno Windows.
• Las implementaciones en la nube de PostgreSQL pueden utilizar un mecanismo de conmutación por error de DNS directo en lugar de Pgpool-II.
• Se puede ejecutar un proceso Pgpool-II en el mismo servidor que la aplicación de ThingWorx para reducir el número total de servidores en un entorno de alta disponibilidad.
• PTC no recomienda el uso de Pgpool-II para gestionar la replicación de PostgreSQL. En las instrucciones que se proporcionan en este documento, se utiliza la replicación de flujo de PostgreSQL y Pgpool-II para el enrutamiento de tráfico, la supervisión de la integridad de nodos y la automatización de la conmutación por error.