Para asegurar la continuidad de la actividad empresarial y minimizar la pérdida de datos, la alta disponibilidad y la recuperación tras fallos son estrategias de protección de datos cruciales para AlloyDB Omni. La alta disponibilidad se centra en mantener la disponibilidad de la base de datos y minimizar el objetivo de tiempo de recuperación (RTO), mientras que la recuperación tras fallos se centra en la recuperación tras eventos catastróficos y en minimizar el objetivo de punto de recuperación (RPO).
El tiempo de recuperación (RTO) y el punto de recuperación (RPO) se ajustan a los requisitos de la empresa y se definen de la siguiente manera:
- El RTO es el tiempo máximo que una base de datos puede estar inactiva o no disponible antes de que la empresa sufra consecuencias inaceptables, como la pérdida de ingresos o productividad.
- El RPO es la cantidad máxima de datos que puede perder una empresa antes de que afecte a sus requisitos empresariales. Por ejemplo, los sistemas de inventario que requieren una pista de auditoría completa pueden tener el requisito de que no se pierdan datos.
AlloyDB Omni ofrece las siguientes arquitecturas de referencia de disponibilidad, que proporcionan niveles de disponibilidad cada vez mayores:
- Disponibilidad estándar: protege tus datos mediante copias de seguridad.
- Mayor disponibilidad: protege tus datos mediante la replicación por zonas en una región (alta disponibilidad).
- Disponibilidad premium: protege tus datos mediante la replicación zonal y regional (alta disponibilidad y recuperación ante desastres).
Mecanismos de disponibilidad
Estos son los principales mecanismos que garantizan la disponibilidad:
- Copias de seguridad de bases de datos
- Replicación de bases de datos
Copias de seguridad de bases de datos
Las copias de seguridad de bases de datos, un aspecto fundamental de la protección de datos, implican la creación de copias físicas de los archivos de datos de la base de datos. Los distintos tipos de copias de seguridad (completa, incremental y diferencial) ofrecen diferentes equilibrios entre el objetivo de punto de recuperación (RPO), el tamaño y la duración de la copia de seguridad, y el tiempo de restauración.
Para garantizar una recuperación eficiente y minimizar la pérdida de datos en caso de fallos del sistema, una estrategia de copia de seguridad sólida debe incluir copias de seguridad de la base de datos y del archivo de registro de escritura anticipada (WAL). Es fundamental hacer copias de seguridad periódicas (normalmente diarias) de los archivos de datos. También debes crear copias de seguridad de los archivos WAL, que registran las modificaciones de la base de datos y son fundamentales para la recuperación a un momento dado y para mantener la integridad de los datos durante la restauración.
Replicación de bases de datos
PostgreSQL ofrece servidores de réplica para aumentar la fiabilidad. Estas réplicas se clasifican como en espera activa, que no aceptan conexiones de aplicaciones, o en espera activa, que funcionan en modo de solo lectura. Los cambios de la base de datos principal se aplican continuamente a la réplica para que los datos de la réplica estén actualizados. Si la base de datos principal falla, la réplica se convierte en principal y asume las responsabilidades de la base de datos principal.
Las réplicas de la base de datos se pueden colocar en la misma zona o centro de datos que la instancia principal, en una zona diferente, en otra región o en una combinación de estas ubicaciones. Cuanto más lejos esté la réplica de la base de datos principal, mayor será la latencia al enviar los cambios para mantener las réplicas actualizadas. En las implementaciones en ubicaciones distantes para mitigar los fallos a gran escala, como los fallos regionales, la replicación de datos se suele realizar de forma asíncrona. De esta forma, se evita la degradación del rendimiento que puede producirse en estas configuraciones.
En las implementaciones de alta disponibilidad, las réplicas suelen implementarse cerca de la base de datos principal. Por ejemplo, las réplicas que se implementan en una zona diferente del mismo centro de datos ofrecen tiempos de recuperación bajos y un RPO cercano a cero. Por otro lado, en las configuraciones de recuperación tras desastres, las réplicas se implementan en centros de datos o regiones independientes, en función del nivel de protección que se requiera frente a las interrupciones. Este enfoque da como resultado un RPO más alto (ya que la replicación puede ser asíncrona) y un RTO variado.
En la siguiente tabla se resumen los mecanismos utilizados en las arquitecturas de referencia de disponibilidad de AlloyDB Omni:
| Función | Estándar | Mejorada | Premium |
|---|---|---|---|
| Copia de seguridad | ✔ | ✔ | ✔ |
| Réplica zonal | ❌ | ✔ | ✔ |
| Réplica entre zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabla 1. Mecanismos de disponibilidad de AlloyDB Omni admitidos
Fallos de bases de datos y situaciones de recuperación
Los errores de la base de datos pueden producirse en los siguientes niveles:
- Fallo de la instancia (nodo o servidor): la propia base de datos falla.
- Fallo del servidor: el servidor que aloja la base de datos falla.
- Fallo por zonas: falla todo el centro de datos que aloja el servidor.
- Fallo de una región: toda la región que contiene varios centros de datos (zonas de disponibilidad) no está disponible, por ejemplo, debido a una inundación o a un terremoto de gran magnitud.
La probabilidad y el riesgo de que se produzca un desastre disminuyen cuando hay menos eventos y aumenta el coste de prevenir estos eventos. Las empresas deben determinar su tolerancia al riesgo y elegir si aceptan posibles interrupciones o invierten en arquitecturas más resilientes para minimizar los riesgos.
En la siguiente tabla se resumen los casos de recuperación que admiten las arquitecturas de referencia de AlloyDB Omni:
| Tipo de desastre | Estándar | Mejorada | Premium |
|---|---|---|---|
| Fallo de VM o instancia | ✔ | ✔ | ✔ |
| Fallo de nodo o servidor | ✔ | ✔ | ✔ |
| Fallo de zona | ❌ | ✔ | ✔ |
| Fallo regional | ❌ | ❌ | ✔ |
Tabla 2. Situaciones de recuperación admitidas
Ten en cuenta los objetivos de tu empresa para tu base de datos AlloyDB Omni, como la necesidad crítica de tener un nivel de disponibilidad de 99,99 % y de no perder datos al recuperar aplicaciones esenciales. El objetivo de las arquitecturas de referencia de disponibilidad es cumplir los requisitos de RTO y RPO.
AlloyDB Omni ofrece arquitecturas de disponibilidad estándar, mejorada y premium para proteger las bases de datos frente a interrupciones planificadas y no planificadas, lo que se adapta a las diferentes necesidades empresariales. Por ejemplo, los entornos de desarrollo pueden usar una protección básica con copias de seguridad, mientras que las aplicaciones esenciales pueden emplear configuraciones de alta disponibilidad y recuperación tras fallos.
Siguientes pasos
Consulta más información sobre las arquitecturas de referencia de disponibilidad de AlloyDB Omni:
- Protege tus datos con copias de seguridad (disponibilidad estándar).
- Protege tus datos mediante la replicación por zonas en una región (disponibilidad mejorada).
- Protege tus datos mediante la replicación zonal y regional (disponibilidad premium).