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 la minimización del objetivo de punto de recuperación (RPO).
El RTO y el RPO se alinean con los requisitos empresariales y se definen de la siguiente manera:
- 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.
- RPO es la cantidad máxima de pérdida de datos que una empresa puede experimentar antes de que afecte los requisitos empresariales. Por ejemplo, los sistemas de inventario que requieren un registro de auditoría completo pueden tener un requisito de pérdida de datos cero.
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 la replicación zonal y regional (HA y DR).
Mecanismos de disponibilidad
Los siguientes son los mecanismos principales 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 diferentes balances 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 restablecimiento.
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 para mantener 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 instancias en espera activas, que no aceptan conexiones de aplicaciones, o instancias en espera en caliente, que operan en modo de solo lectura. Los cambios de la base de datos principal se aplican de forma continua 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 cuando se envíen cambios para mantener las réplicas actualizadas. Para las implementaciones en ubicaciones distantes para mitigar fallas a gran escala, como fallas regionales, la replicación de datos suele realizarse de forma asíncrona. Este enfoque evita la degradación del rendimiento que puede ocurrir en esas 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 RTO bajos y RPO cercanos a cero. Por otro lado, en las configuraciones de recuperación ante desastres, las réplicas se implementan en centros de datos o regiones 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 puede 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 entre zonas | ❌ | ✔ | ✔ |
| Réplica regional | ❌ | ❌ | ✔ |
Tabla 1. Mecanismos de disponibilidad de AlloyDB Omni admitidos
Fallas de la base de datos y situaciones de recuperación
La falla de la base de datos puede ocurrir en los siguientes niveles:
- Falla de instancia (nodo o servidor): Falla la base de datos.
- 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 de 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 un terremoto de gran magnitud.
La probabilidad y el riesgo de un desastre disminuyen cuando hay menos eventos y aumenta el costo de prevención de estos eventos. Las empresas deben determinar su tolerancia al riesgo y elegir si aceptan posibles interrupciones o invierten en arquitecturas más resistentes 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 de nodo o servidor | ✔ | ✔ | ✔ |
| Falla de zona | ❌ | ✔ | ✔ |
| Falla regional | ❌ | ❌ | ✔ |
Tabla 2. Situaciones de recuperación admitidas
Ten en cuenta los objetivos de tu empresa para tu base de datos de AlloyDB Omni, como una necesidad fundamental de varios 9 (99.99%) de disponibilidad y pérdida de datos cero tras la recuperación de aplicaciones críticas. 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 interrupciones planificadas y no planificadas, en función de las diferentes necesidades empresariales. Por ejemplo, los entornos de desarrollo pueden usar protección básica con copias de seguridad, mientras que las aplicaciones críticas pueden 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).