Configura un sistema de Alta Disponibilidad en PostgreSQL

Name: Configura un sistema de Alta Disponibilidad en PostgreSQL
Rating: 4.7 (312 reviews)

Instala, configura y monitoriza un sistema de réplica para disponibilidad 24x7, paso a paso con scripts listos para usar

Highest Rated

Created byLoles Ferrándiz

Last updated 4/2025

Spanish

What you'll learn

Alta Disponibilidad
Sistema de réplica
Streaming Replication Asynchronous
Hot standby para que los servidores standby permitan conexiones de sólo lectura
Failover de manera que cuando la base de datos principal caiga, una réplica se active inmediatamente y el servicio no se interrumpa
Switchover para invertir los roles entre la Primary y la Standby
Promocionar un standby, es decir, convertirlo en master
Clonar una standby para conectarla con la master
IP virtual para conectar con la base de datos principal
IP virtual para conectar con la base de datos en standby

Course content

4 sections • 21 lectures • 2h 12m total length

Introducción5:53
En esta clase te explico todo lo que puedes esperar de un sistema de réplica y te muestro, a través de una sencilla animación, el comportamiento del sistema de réplica ante cada evento que pueda ocurrir en el sistema.
Comprueba los conocimientos adquiridos hasta el momento

Entorno de pruebas (Parte I)1:05
En esta clase te describo un entorno de pruebas útil para practicar los contenidos de este curso y te doy acceso a un curso gratuito creado por mí, en el que explico cómo configurar máquinas virtuales Linux con VirtualBox.
Entorno de pruebas (Parte II)0:17
Streaming Replication Asíncrono15:54
Configuramos el sistema de réplica utilizando la técnica streaming replication asynchronous. Al finalizar esta clase práctica tendrás un sistema de réplica funcionando entre el servidor de bases de datos principal y un servidor en standby.
Descarga, instalación y configuración de repmgr19:10
Descargamos, instalamos y configuramos el paquete repmgr con el que podremos configurar el failover, una funcionalidad muy útil que permite que un servidor en standby promocione como nuevo servidor maestro en caso de caída del maestro actual.
Registrar nodos12:31
Todos los nodos que formen parte del sistema de réplica han de ser registrados en la base de datos repmgr con su correspondiente configuración (información de conexión, nombre, rol, etc.).
En esta clase práctica veremos cómo registrar los nodos y cómo monitorizarlos para conocer su estado en cada momento.
Failover6:43
En esta clase práctica simulamos un fallo grave en el servidor principal que provoca que el servicio caiga.
Gracias a la configuración de failover realizada en la clase anterior veremos como el servidor en standby promociona a master permitiendo la continuidad del servicio.
Recuperación del Master6:31
El servidor primario, una vez solucionado el problema que provocó su caída tiene que ser recuperado (clonado) e incorporado de nuevo al sistema de réplica como "nueva réplica" que haga de respaldo del "nuevo master" que promocionó tras el failover.
En esta clase veremos como se clona un servidor y se incorpora al sistema de réplica como standby.
Switchover7:54
Switchover es invertir los roles entre dos servidores.
A menudo el servidor principal es un servidor mucho más potente a nivel de procesador, memoria, etc. Cuando ocurre un failover un servidor en standby promociona a "nuevo master" lo cual está bien, pues proporciona esa Alta Disponibilidad que perseguimos. El master puede clonarse e incorporarse al sistema de réplica como "nueva standby" pero quizás no queramos permanecer mucho tiempo en este estado y queramos que el servidor potente vuelva a ser el master.
Para ello tenemos el proceso switchover que explicaremos cómo realizarlo en PostgreSQL.
Activación de las IPs virtuales6:38
En esta clase configuramos dos IPs virtuales en cada uno de los nodos: una para la conexión con el master y otra para la conexión con el standby.
Cada servidor levantará la IP virtual que le corresponda y, a partir de ese momento, los clientes podrán ser reconfigurados para conectarse siempre a una única IP.
Script para la gestión de las IPs virtuales7:13
Necesitamos que las IPs virtuales vayan levantando y parando en los servidores según ocurran los cambios de roles. Por ejemplo, si uno de los dos servidores está caído, el otro asumirá las dos IPs virtuales.
De esta forma los clientes no necesitarán conocer cuántos nodos tiene el sistema de réplica, cuáles nodos están activos y cuáles caídos ni tampoco qué rol tiene cada uno de los nodos activos. Se conectan siempre a la IP virtual con la que trabajen (IP del master o IP del standby) y no tienen que hacer cambios en sus cadenas de conexión.
Además del script que se muestra en la clase, también te dejo otra versión de script para gestionar las IPs virtuales, por si te gusta más. En esta ocasión te dejo los dos scripts, el que tienes que ejecutar en el nodo 1 y el que tienes que ejecutar el nodo 2 (VirtualIP_node1.sh y VirtualIP_node2.sh).
¡Cambia las IPs si lo consideras y comprueba los valores de las variables antes de ejecutarlo pues pueden haber variaciones según el sistema!
Nota: quizás necesites instalar ifupdown.
Prueba de Failover3:34
En esta clase práctica hacemos la prueba de failover definitiva: provocamos la caída del servidor principal y vemos cómo se produce el failover y la correcta configuración de las IPs virtuales.
Prueba de Recuperación2:51
En esta clase práctica recuperamos el servidor caído (la antigua master) y comprobamos como se incorpora perfectamente al sistema de réplica como nueva standby y adquiere la IP virtual de la standby que, a su vez, cae del servidor que en estos momentos actúa como "nuevo master".
Prueba de Switchover2:59
En esta ocasión realizamos un switchover, una inversión de roles para devolver al servidor principal el rol de master y al servidor secundario el rol de standby. Las IPs virtuales se invierten también, como era de esperar ;-)
Test
Más sistemas de Alta Disponibilidad0:08
Despedida4:11
Esta clase teórica menciono otros sistemas de alta disponibilidad que se podrían configurar.

Técnica de backup y recuperación: Archivado continuo y Point-In-Time Recovery11:15
De la mano de una presentación animada, en este Bonus conocerás qué es un fichero WAL, en qué consiste el archivado continuo, qué es un punto de recuperación y cómo realizar backups que te permitan recuperar tus bases de datos hasta el instante anterior en el que ocurrió ese error humano, fallo en el sistema o en la tecnología, o desastre natural que haya comprometido tus datos o el acceso a los mismos.
¿Quieres saber más sobre copias de seguridad y recuperación en PostgreSQL?0:18
¿Dónde está el Log de PostgreSQL?16:56
En esta , a través de 4 situaciones distintas y reales, veremos cómo influye la forma en que iniciamos el servidor PostgreSQL con el destino del log y cómo localizarlo en cada una de esas situaciones.
Más sobre el Log de PostgreSQL0:17

Requirements

Conocimientos básicos de Linux
Conocimientos básicos de PostgreSQL

Description

Un sistema de base de datos debe estar disponible cuando se necesita, y más aún en casos concretos de negocio como las grandes empresas, servicios de emergencias, entidades bancarias, etc.

Para garantizar una disponibilidad cercana al 100% es necesario implementar un sistema de réplica que nos permita, por un lado, que los clientes puedan trabajar con otro servidor cuando el servidor de base de datos principal tiene que ser desconectado para llevar a cabo alguna tarea de mantenimiento o ampliación y por otro lado, que ante una caída no controlada del servicio, los clientes tengan otro servidor con el que trabajar mientras se resuelve el problema.

La disponibilidad del 99,99% es posible y en este curso instalo, configuro y monitorizo un sistema de réplica para enseñarte como hacerlo, paso a paso, para que no tengas ninguna dificultad a la hora de respaldar tus bases de datos PostgreSQL con este sistema.

No sólo tendrás un servidor secundario (también llamados standby o slave) con el que trabajar, con todos los datos, en caso de caída del servidor principal si no que ese servidor secundario podrás utilizarlo para operaciones de lectura. De esta forma, los clientes que accedan al sistema para realizar informes, estadísticas, análisis de patrones, etc. podrán realizarlo al servidor en standby, reduciendo la carga de trabajo en el servidor principal, para beneficio de todo el sistema.

El sistema de réplica que configuraremos en este curso tendrá implementado un sistema de failover. Es decir, en caso de caída inesperada del servicio de base de datos, automáticamente, sea la hora que sea, el día que sea, el servidor en standby se convertirá en el nuevo máster sin intervención del DBA, y el servicio podrá continuar sin ningún problema.

Por último, y para mejorar aún más la comodidad de los clientes, haremos uso de dos IPs virtuales, una para conectarse a la base de datos principal y otra para conectarse a la réplica haciendo que los clientes no tengan la necesidad de saber cuántos servidores forman parte del sistema de réplica, si se encuentran activos o caídos, ni el rol que tiene cada uno de ellos.

Who this course is for:

Administradores de Bases de datos
Administradores de Sistemas
Estudiantes de certificaciones en PostgreSQL

Configura un sistema de Alta Disponibilidad en PostgreSQL

What you'll learn

Explore related topics

Course content

Introducción1 lecture • 6min

Sistema de réplica para Alta Disponibilidad en PostgreSQL 12+15 lectures • 1hr 38min

Más sobre Administración PostgreSQL4 lectures • 29min

Bonus1 lecture • 1min

Requirements

Description

Who this course is for: