Para garantizar la continuidad empresarial y minimizar la pérdida de datos, la alta disponibilidad (HA) y la recuperación ante desastres (DR) son estrategias de protección de datos fundamentales para AlloyDB Omni. La HA se enfoca en mantener la disponibilidad de la base de datos y minimizar el objetivo de tiempo de recuperación (RTO), mientras que la DR aborda la recuperación de eventos catastróficos y minimiza el objetivo de punto de recuperación (RPO).
El RTO y el RPO se alinean con los requisitos comerciales 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 experimente consecuencias inaceptables, como la pérdida de ingresos o productividad.
- El RPO es la cantidad máxima de pérdida de datos que puede experimentar una empresa antes de que afecte los requisitos comerciales. Por ejemplo, los sistemas de inventario que requieren un registro de auditoría completo pueden tener el requisito de no perder 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 con copias de seguridad.
- Disponibilidad mejorada: Protege tus datos con la replicación zonal en una región (HA).
- Disponibilidad Premium: Protege tus datos con replicación regional y zonal (HA y DR).
Mecanismos de disponibilidad
Los siguientes 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 diferentes tipos de copias de seguridad (completas, incrementales y diferenciales) ofrecen distintos 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 fallas 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 crear copias de seguridad periódicas (por lo general, 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 en un momento determinado y el mantenimiento de la integridad de los datos durante el restablecimiento.
Replicación de bases de datos
PostgreSQL ofrece servidores de réplica para aumentar la confiabilidad. Estas réplicas se clasifican como en espera activa, que no aceptan conexiones de aplicaciones, o en espera caliente, que operan en modo de solo lectura. Los cambios de la base de datos principal se aplican continuamente a la réplica para mantener actualizados los datos de la réplica. Si falla la base de datos principal, la réplica se promueve al estado 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 una región diferente o en una combinación de estas ubicaciones. Cuanto más lejos se encuentre la réplica de la base de datos principal, mayor será la latencia al enviar cambios para mantener las réplicas actualizadas. Para las implementaciones en ubicaciones distantes que mitigan fallas a gran escala, como fallas regionales, la replicación de datos se realiza de forma asíncrona. Este enfoque evita la degradación del rendimiento que puede ocurrir en tales 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 dentro del mismo centro de datos ofrecen valores de RTO bajos y valores de RPO cercanos a cero. Por otro lado, en las configuraciones de recuperación ante desastres, las réplicas se implementan en regiones o centros de datos separados, según el nivel de protección requerido contra las interrupciones. Este enfoque genera un RPO más alto (ya que la replicación podría ser asíncrona) y un RTO variado.
En la siguiente tabla, se resumen los mecanismos que se usan para las arquitecturas de referencia de disponibilidad de AlloyDB Omni:
| Función | Standard | Mejorada | Premium |
|---|---|---|---|
| Copia de seguridad | ✔ | ✔ | ✔ |
| Réplica zonal | ❌ | ✔ | ✔ |
| Réplica de varias zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabla 1. Mecanismos de disponibilidad compatibles con AlloyDB Omni
Situaciones de recuperación y fallas de bases de datos
La falla de la base de datos puede ocurrir en los siguientes niveles:
- Falla de la instancia (nodo o servidor): Falla la base de datos en sí.
- Falla del servidor: Falla el servidor que aloja la base de datos.
- Falla zonal: Falla todo el centro de datos que aloja el servidor.
- Falla regional: Toda la región que contiene varios centros de datos (zonas de disponibilidad) no está disponible, por ejemplo, debido a una inundación o un terremoto de gran magnitud.
La probabilidad y el riesgo de un desastre disminuyen cuando hay menos eventos y aumenta el costo de prevenirlos. 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 las situaciones de recuperación que admiten las arquitecturas de referencia de AlloyDB Omni:
| Tipo de desastre | Standard | Mejorada | Premium |
|---|---|---|---|
| Falla de VM o instancia | ✔ | ✔ | ✔ |
| Falla del nodo o servidor | ✔ | ✔ | ✔ |
| Falla de zona | ❌ | ✔ | ✔ |
| Falla regional | ❌ | ❌ | ✔ |
Tabla 2. Situaciones de recuperación admitidas
Considera los objetivos comerciales de tu base de datos de AlloyDB Omni, como la necesidad crítica de varios 9s (99.99%) de disponibilidad y la pérdida cero de datos tras la recuperación para las aplicaciones fundamentales. El objetivo de las arquitecturas de referencia de disponibilidad es abordar los requisitos de RTO y RPO.
AlloyDB Omni ofrece arquitecturas de disponibilidad estándar, mejorada y premium para proteger las bases de datos de las interrupciones planificadas y no planificadas, lo que se alinea con las diferentes necesidades comerciales. Por ejemplo, los entornos de desarrollo pueden usar protección básica con copias de seguridad, mientras que las aplicaciones críticas para la misión podrían emplear configuraciones de alta disponibilidad y recuperación ante desastres.
¿Qué sigue?
Obtén 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 con la replicación zonal en una región (disponibilidad mejorada).
- Protege tus datos con la replicación zonal y regional (disponibilidad Premium).