A continuación se muestra un extracto de nuestro documento técnico "Administración y automatización de PostgreSQL con ClusterControl" que se puede descargar de forma gratuita.
Nota de revisión:tenga en cuenta que los términos utilizados en este blog Master-Slave son sinónimos de los términos Master-Standby utilizados por PostgreSQL. Estamos utilizando Master-Slave para mantener el paralelismo con otras tecnologías.
Para la configuración HA podemos tener varias arquitecturas, pero las básicas serían arquitecturas maestro-esclavo y maestro-maestro. Los servidores de bases de datos pueden trabajar juntos para permitir que un segundo servidor se haga cargo rápidamente si el servidor primario falla (alta disponibilidad). ), o para permitir que varias computadoras sirvan los mismos datos (equilibrio de carga).
Arquitecturas maestro-esclavo de PostgreSQL
Estas arquitecturas nos permiten mantener una base de datos maestra con uno o más servidores en espera listos para hacerse cargo de las operaciones si falla el servidor principal. Estas bases de datos en espera permanecerán sincronizadas (o casi sincronizadas) con la maestra.
La replicación entre el maestro y los esclavos se puede realizar mediante instrucciones SQL (reservas lógicas) o mediante modificaciones de la estructura de datos interna (reservas físicas). PostgreSQL utiliza un flujo de registros de escritura anticipada (WAL) para mantener sincronizadas las bases de datos en espera. Si el servidor principal falla, el standby contiene casi todos los datos del servidor principal y puede convertirse rápidamente en el nuevo servidor de base de datos principal. Esto puede ser síncrono o asíncrono y solo se puede hacer para todo el servidor de la base de datos.
La configuración de la replicación de transmisión es una tarea que requiere seguir algunos pasos a fondo. Para esos pasos y más antecedentes sobre este tema, consulte:Conviértase en un DBA de PostgreSQL - Cómo configurar la replicación de transmisión para alta disponibilidad.
A partir de la versión 10, PostgreSQL incluye la opción de configurar la replicación lógica.
La replicación lógica permite que un servidor de base de datos envíe un flujo de modificaciones de datos a otro servidor. La replicación lógica de PostgreSQL construye un flujo de modificaciones de datos lógicos desde WAL. La replicación lógica permite replicar los cambios de datos de tablas individuales. No requiere que un servidor en particular sea designado como maestro o réplica, pero permite que los datos fluyan en múltiples direcciones.
Puede encontrar más información sobre la replicación lógica:Blog:descripción general de la replicación lógica en PostgreSQL.
Para asegurar efectivamente una alta disponibilidad, no es suficiente tener una arquitectura maestro-esclavo. También debemos habilitar alguna forma automática de conmutación por error, de modo que si algo falla, podamos tener el menor retraso posible para reanudar la funcionalidad normal. PostgreSQL no incluye un mecanismo automático de conmutación por error para identificar fallas en la base de datos maestra y notificar a la solución para que tome posesión, por lo que requerirá un poco de trabajo por parte del DBA. Debe trabajar en un script que incluya el comando de promoción pg_ctl, que promoverá al esclavo como nuevo maestro. También hay algunas herramientas de terceros para esta automatización. Muchas de estas herramientas existen y están bien integradas con las instalaciones del sistema operativo necesarias para una conmutación por error exitosa, como la migración de direcciones IP.
Después de que ocurra una conmutación por error, debe modificar su aplicación en consecuencia para que funcione con el nuevo maestro. También tendrá un solo servidor en funcionamiento, por lo que se debe volver a crear la arquitectura maestro-esclavo, para que volvamos a la misma situación normal que teníamos antes del problema.
Descargue el documento técnico hoy Gestión y automatización de PostgreSQL con ClusterControl Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar PostgreSQLDescargar el documento técnicoArquitecturas maestro-maestro de PostgreSQL
Esta arquitectura proporciona una forma de minimizar el impacto de un error en uno de los nodos, ya que el otro nodo puede encargarse de todo el tráfico, tal vez afectando levemente el rendimiento, pero sin perder nunca la funcionalidad. También se usa para lograr (y tal vez este sea un punto aún más interesante) escalabilidad horizontal (scale-out), opuesto al concepto de escalabilidad vertical donde agregamos más recursos a un servidor (scale-up).
Para implementar esta arquitectura, necesitará usar herramientas externas, ya que esta función (todavía) no es compatible de forma nativa con PostgreSQL.
Debe tener mucho cuidado al elegir una solución para implementar maestro-maestro, ya que hay muchos productos diferentes. Muchos de ellos siguen siendo “verdes”, con pocos usuarios serios o casos de éxito. Algunos otros proyectos, por otro lado, han sido abandonados, ya que no hay mantenedores activos.
Para obtener más información sobre las herramientas disponibles, consulte:Blog:Principales soluciones HA de clústeres de PG para PostgreSQL.
Equilibrio de carga y agrupación de conexiones
Hay varias herramientas de balanceo de carga que se pueden usar para administrar el tráfico de su aplicación para aprovechar al máximo la arquitectura de su base de datos. De la misma forma, existen otras que pueden ayudarte a administrar la forma en que la aplicación se conecta a la base de datos, agrupando estas conexiones y reutilizándolas entre diferentes solicitudes.
Hay algunos productos que se utilizan para ambos propósitos, como el conocido pgpool, y algunos otros que se centrarán en una sola de estas características, como pgbouncer (agrupación de conexiones) y HAProxy (utilizado para balanceo de carga).
