Opciones de recuperación ante desastres para cargas de trabajo de bases de datos de Oracle
En esta guía, se describen las opciones de recuperación ante desastres disponibles para los usuarios que ejecutan cargas de trabajo de bases de datos de Oracle fundamentales en un entorno de la solución Bare Metal.
En esta guía, se supone que ejecutas Oracle Enterprise Edition. Algunas de las funciones que se describen en esta guía tienen licencias independientes fuera de una licencia de la edición empresarial. Entre algunas de estas funciones, se incluyen las siguientes:
- Clústeres de aplicación real de Oracle
- Oracle Active Data Guard
- Compresión avanzada de Oracle
- Oracle GoldenGate
Consulta tus contratos de licencia de Oracle para determinar qué funciones tienes derecho a usar cuando planificas la recuperación ante desastres y la alta disponibilidad.
RTO y RPO de la aplicación
La recuperación ante desastres para las tecnologías de bases de datos de Oracle se debe determinar en función del objetivo de tiempo de recuperación (RTO) y el objetivo del punto de recuperación (RPO) de una aplicación. En general, el RTO describe la cantidad de tiempo de inactividad aceptable para un sistema y el RPO describe la cantidad de pérdida de datos que es aceptable. El costo y la complejidad de un sistema aumentan a medida que disminuye cada uno de estos valores. Para obtener más información sobre RTO y RPO, consulta Conceptos básicos de la planificación de DR.
Las arquitecturas etiquetadas como “RPO = 0” o “sin pérdida de datos” requieren que los datos se escriban en varias ubicaciones antes de que se consideren “confirmados” en la base de datos. La latencia se convierte en un problema a medida que el RPO se acerca a cero.
A menos que se tenga en cuenta de forma adecuada durante la fase de diseño, la implementación de una arquitectura de pérdida de datos cero puede tener efectos adversos en el rendimiento general de la aplicación.
Alta disponibilidad en comparación con la recuperación ante desastres
La alta disponibilidad y la recuperación ante desastres son conceptos complementarios cuando se diseñan arquitecturas de bases de datos confiables. En el contexto de esta guía, la alta disponibilidad se refiere a la capacidad de un sistema para recuperarse automáticamente de fallas individuales o en cascada. Por otro lado, la recuperación ante desastres forma parte de un plan general de continuidad del negocio y se aplica a fallas más grandes que pueden hacer que grupos completos de sistemas no estén disponibles. La recuperación ante desastres abarca un alcance más amplio debido a la cantidad de componentes integrados que se deben recuperar en caso de un desastre.
La alta disponibilidad se debe considerar la “primera línea de defensa” cuando se diseña un sistema confiable. Una arquitectura de base de datos de alta disponibilidad debe poder soportar fallas individuales y seguir ejecutándose sin causar tiempo de inactividad para la aplicación. Los componentes de alta disponibilidad de un sistema deben incluir, entre otros, los siguientes:
- Alimentación redundante en el hardware del servidor, la red o el almacenamiento
- Varias interfaces de red, interruptores y cables
- Tejidos de almacenamiento, controladores y dispositivos de disco redundantes
- Interconexiones de socios tolerantes a fallas entre Google Cloud y la extensión de región de la solución Bare Metal
- Oracle RAC para evitar que las fallas del servidor inhabiliten una base de datos
Un diseño de recuperación ante desastres debe incluir procesos para recuperarse de varias fallas en cascada que dejan los componentes indisponibles. La planificación de la recuperación ante desastres debe tener en cuenta lo siguiente:
- Interrupciones regionales
- Desastres naturales
- Incidentes que provocan la interrupción total de uno o más componentes de una aplicación
Herramientas de alta disponibilidad y recuperación ante desastres de Oracle
A continuación, se incluyen algunas herramientas de alta disponibilidad y recuperación ante desastres de Oracle:
- Clústeres de aplicación real de Oracle
- Oracle Recovery Manager
- Oracle Data Guard
- Base de datos flashback
- Oracle GoldenGate
Clústeres de aplicación real de Oracle
Oracle Real Application Clusters (RAC) se usa para escalar horizontalmente las cargas de trabajo de la base de datos que se deben reparar con varios servidores de bases de datos. Las bases de datos que usan RAC permiten una configuración activa/activa entre servidores dentro de una extensión de región.
Por lo general, el RAC se usa para proporcionar alta disponibilidad a los sistemas que se deben proteger contra la falla de un solo servidor. Debido al enfoque de “todo compartido” (almacenamiento y redes compartidos) para el clúster, debe existir un clúster de RAC que se ejecute en un solo pod de la solución Bare Metal. Esto hace que RAC sea una solución para las inquietudes de alta disponibilidad, pero no resuelve el requisito de recuperación ante desastres.
Para obtener información sobre cómo configurar RAC para la solución Bare Metal, consulta Cómo instalar Oracle RAC en una solución Bare Metal.
Administrador de recuperación de Oracle
El administrador de recuperación de Oracle (RMAN) es la herramienta principal para crear copias de seguridad y recuperar bases de datos de Oracle debido a su capacidad para leer el formato de archivo de datos propietario de Oracle. Se puede usar para realizar clonaciones de bases de datos, recuperación de un momento determinado o incluso la recuperación de una sola tabla dentro de una base de datos de Oracle.
RMAN es la única herramienta que se puede usar para crear copias de seguridad mientras la base de datos está abierta. También se usa para mantener el catálogo de archivos de copia de seguridad que están disponibles para usarse en la recuperación.
Oracle Data Guard
Oracle Data Guard realiza la replicación de bases de datos en clústeres de RAC remotos o en otras instalaciones de bases de datos. Data Guard admite bases de datos de resguardo en una configuración física o lógica.
Las bases de datos de reserva físicas son copias de bloque por bloque que permiten que una copia de la base de datos esté abierta para la escritura. Todas las demás se activan (pero no se abren) para aplicar cambios o se abren de solo lectura para admitir aplicaciones de informes.
Para obtener información sobre cómo configurar Data Guard en la solución Bare Metal, consulta Implementa Oracle Data Guard en la solución Bare Metal.
FLASHBACK DATABASE
La función FLASHBACK DATABASE de Oracle Enterprise Edition permite a los administradores rebobinar rápidamente una base de datos a un punto específico en el tiempo sin necesidad de realizar restauraciones de bases de datos que consumen mucho tiempo.
En el contexto de la recuperación ante desastres, FLASHBACK DATABASE se usa comúnmente junto con Data Guard durante las operaciones de conmutación por error para restablecer la base de datos más rápido. La base de datos con errores se vuelve a escribir en un momento específico que es coherente con los registros de la nueva instancia principal, y se vuelve a enviar para que se pueda volver a sincronizar por completo.
Oracle GoldenGate
Oracle GoldenGate es una herramienta de replicación lógica que se usa comúnmente para habilitar implementaciones activas/activas de varios sitios o mover datos entre plataformas de hardware. Cuando se usa GoldenGate, un proceso extract en la base de datos de origen captura los cambios en los registros de rehacer en línea y los escribe en los cambios de los archivos de registro, que se transportan a la base de datos de destino. Un proceso replicat en la base de datos de destino convierte las transacciones de los archivos de cola a SQL y ejecuta SQL en la base de datos de destino.
Esta arquitectura hace que GoldenGate sea una herramienta potente para mover datos entre plataformas de bases de datos o transformarlos a medida que se replican. A diferencia de Data Guard, GoldenGate requiere que se instale y mantenga software independiente en los sistemas de origen y destino. GoldenGate no se puede usar para la replicación síncrona debido a que las transacciones se traducen y aplican como SQL en la base de datos de destino. Si bien GoldenGate puede proporcionar un retraso mínimo para la replicación, solo GoldenGate no puede garantizar un RPO de cero.
Modelos de implementación de recuperación ante desastres (solo para bases de datos)
Oracle creó el framework de arquitectura de máxima disponibilidad (MAA) para brindarte los modelos de recuperación ante desastres recomendados para implementar tus aplicaciones y bases de datos.
Cada uno de los siguientes modelos proporciona objetivos específicos de RTO y RPO:
Los modelos se asignan a patrones de implementación específicos que cumplen con el RPO y el RTO en eventos de interrupciones planificadas y no planificadas. Cada carga de trabajo de la base de datos debe evaluarse en función de sus requisitos de disponibilidad y diseñarse con un modelo correspondiente. Es común que las bases de datos de desarrollo usen un modelo con un nivel de protección más bajo que sus contrapartes de producción y QA.
El modelo Bronce está diseñado para bases de datos que no necesitan un RTO medido en minutos. Los modelos Silver y de nivel superior incluyen bases de datos en espera que se ejecutan en un sitio remoto. Cada modelo incorpora la funcionalidad de los modelos de nivel inferior. Por ejemplo, el modelo Bronce usa conceptos de copia de seguridad y recuperación que se deben seguir incluso si se implementa una base de datos de resguardo.
Modelo de cobre
El modelo Copper proporciona una implementación mínima para crear copias de seguridad de bases de datos en medios de almacenamiento local y copiarlas en el almacenamiento que reside fuera de la extensión de la región. Esta implementación requiere un enfoque de dos etapas, pero se puede crear una secuencia de comandos para usar el SDK de Google Cloud y automatizar la transmisión de copias de seguridad.
El uso de esta implementación también aumenta el RTO debido a la recuperación en dos etapas que se requiere. RMAN no puede acceder directamente a las copias de seguridad, por lo que deben trasladarse a una ubicación disponible para RMAN antes de que pueda comenzar la recuperación.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia |
| Desastres: Corrupciones | La última copia de seguridad incremental, completa o de registro de archivo que se transfirió fuera del RE | Horas, según el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socio | |
| Desastres: Fallas de extensión de región | La última copia de seguridad completa, incremental o de registro de archivo que se transfirió fuera del RE | Días o semanas, según el tiempo necesario para que la extensión de región vuelva a estar en línea | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Tiempo necesario para actualizar y reiniciar la instancia |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas |
Modelo de bronce
El modelo Bronce ofrece dos opciones de implementación. Ambos usan almacenamiento nativo de Google Cloud para retener copias de seguridad de bases de datos.
Implementación de Bronce 1: Copia de seguridad en el almacenamiento regional
En esta implementación, las copias de seguridad se escriben directamente en medios fuera del sitio. En la mayoría de los casos, el destino de copia de seguridad preferido es Cloud Storage con Cloud Storage FUSE, que presenta un bucket de Cloud Storage como un sistema de archivos.
Las recomendaciones para usar Cloud Storage FUSE se pueden encontrar en Copias de seguridad de Oracle con NFS y Cloud Storage. También se puede usar Google Cloud Filestore, que presenta recursos compartidos de NFS a las instancias de la solución Bare Metal.
En el siguiente diagrama, se muestra una implementación de ejemplo.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia |
| Desastres: Corrupciones | Última copia de seguridad completa, incremental o de registro de archivo | Horas, según el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socio | |
| Desastres: Fallas de extensión de región | Última copia de seguridad completa, incremental o de registro de archivo | Días o semanas, según el tiempo necesario para que la extensión de región vuelva a estar en línea | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Tiempo necesario para actualizar y reiniciar la instancia |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas |
Implementación de bronce 2: Crea una copia de seguridad con Backup and DR
En esta implementación, se usa el servicio de copia de seguridad y DR para almacenar copias de seguridad en Google Cloud. La copia de seguridad y la DR ofrecen un enfoque incremental continuo para las copias de seguridad, que se almacenan en medios de alto rendimiento respaldados por Cloud Storage para la retención a largo plazo.
La copia de seguridad y la DR también ofrecen un RTO más rápido que el almacenamiento de copias de seguridad en Filestore o Cloud Storage, ya que pueden poner al instante las imágenes de los archivos de base de datos a disposición de la instancia de Oracle. La función de activación y migración activa una base de datos en línea rápidamente mientras se vuelve a copiar en el medio de almacenamiento de producción, lo que reduce drásticamente el RTO.
En el siguiente diagrama, se muestra una implementación de ejemplo.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia
Segundos si usas RAC |
| Desastres: Corrupciones | Última copia de seguridad completa, incremental o de registro de archivo | De minutos a horas, según los requisitos de rendimiento, el tamaño de la base de datos y el ancho de banda asignado a la interconexión de socio | |
| Desastres: Fallas de extensión de región | Última copia de seguridad completa, incremental o de registro de archivo | Días o semanas, según el tiempo necesario para que la extensión de región vuelva a estar en línea o la capacidad del cliente para cambiarse a otra extensión de región | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Tiempo necesario para actualizar y reiniciar la instancia |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas |
Plateado
El modelo de plata presenta la replicación de bases de datos con Oracle Data Guard. Data Guard proporciona replicación de bases de datos en tiempo real con una o más bases de datos que actúan como bases de datos en espera. Dado que Data Guard se basa en el transporte y la aplicación de cambios en la base de datos a medida que ocurren, el RPO puede ser cercano a cero. El modelo de nivel Silver se basa en la replicación asíncrona. El uso de la replicación síncrona garantiza que no se pierdan datos, pero el tiempo que se tarda en enviar datos entre regiones suele aumentar el tiempo de respuesta de la aplicación más allá de los límites aceptables.
La función de conmutación por error de inicio rápido de Data Guard tiene la capacidad de realizar operaciones de conmutación por error automáticas si una base de datos principal deja de estar disponible durante un período determinado por el usuario. La configuración está supervisada por un proceso de observador de Data Guard, que puede ejecutarse.
El modelo de plata tiene el beneficio de garantizar que la base de datos esté disponible en el caso de una falla regional total, pero las operaciones de conmutación por error y de cambio podrían afectar el rendimiento de la aplicación a medida que aumenta la latencia de red entre los servidores de la aplicación y la base de datos. Raramente se recomienda ejecutar aplicaciones y bases de datos de respaldo en diferentes regiones. Si bien el RTO de la base de datos puede ser inferior a 1 minuto, los casos de conmutación por error de la aplicación pueden tardar entre minutos y horas en que los servicios estén completamente operativos. En la mayoría de los casos, ejecutar planes de conmutación por error de recuperación ante desastres entre regiones suele implicar procesos manuales debido a la cantidad de componentes que se mueven.
En el modelo Silver, es posible que debas tener períodos de inactividad o mantenimiento durante las actividades de aplicación de parches trimestrales. La implementación de Oracle RAC puede reducir el tiempo de inactividad debido a fallas de parches o del servidor.
En el siguiente diagrama, se muestra una configuración de ejemplo.
En la configuración de ejemplo del diagrama, se muestran bases de datos de RAC que se ejecutan en las regiones us-west2 y us-east4. La replicación se configura con Data Guard asíncrono. Todo el tráfico entre la solución Bare Metal y Google Cloud pasa por una interconexión de socio, y el tráfico entre regiones pasa por la red troncal de Google. Los servidores de aplicaciones se configuran en cada región, pero, por lo general, se cierran en la región de recuperación ante desastres hasta que se declara un evento de conmutación por error.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia
Segundos si usas RAC |
| Desastres: Corrupciones | < 60 s | De minutos a horas, según la conmutación por error de la aplicación | |
| Desastres: Fallas de extensión de región | < 60 s | De minutos a horas, según la conmutación por error de la aplicación | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Es el tiempo necesario para actualizar y reiniciar la instancia.
Segundos si usas RAC |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas
Minutos si usas |
Modelo Gold
Si te preocupa la pérdida de datos en el modelo Plata, puedes optar por el modelo Oro, que usa una instancia de sincronización remota para proporcionar replicación síncrona a una instancia que se ejecuta en Google Cloud Compute Engine.
Una instancia de sincronización remota incluye un archivo de control de la base de datos y un conjunto de registros de rehacer en espera que se ejecutan geográficamente cerca de la base de datos principal. Esta instancia se configura para recibir la acción de rehacer de forma síncrona con baja latencia, lo que permite que todos los cambios se registren fuera de la extensión de región de la base de datos principal. Luego, la instancia de sincronización remota reenvía la acción de rehacer a la base de datos en espera en la región remota para que se aplique de forma asíncrona.
Una instancia de sincronización remota no es una copia completa de la base de datos y, por lo tanto, no puede controlar el tráfico de la aplicación. La instancia de sincronización remota se usa para proporcionar una ubicación tolerante a errores para que los cambios de la base de datos se escriban de forma síncrona, lo que permite una solución sin pérdida de datos. Cuando se realiza la replicación síncrona en la instancia de sincronización remota, las transacciones no se confirman en la base de datos principal hasta que se reciben y confirman los cambios en la instancia de sincronización remota.
Por lo general, las instancias de Compute Engine se seleccionan como candidatas para alojar una instancia de sincronización remota. Colocar la instancia de sincronización remota en una zona de Compute Engine cerca de la base de datos principal agrega una latencia mínima (por lo general, inferior a 1.5 ms) y protege contra fallas dentro de la extensión de región.
En el siguiente diagrama, se muestra una implementación de ejemplo.
En la configuración de ejemplo del diagrama, se muestra una base de datos de RAC principal que se ejecuta en us-west2 con aplicaciones que se ejecutan en Compute Engine. Una instancia de Compute Engine dentro de us-west2 ejecuta una instancia de sincronización remota y recibe una repetición síncrona. La instancia de sincronización remota está configurada para enviar la repetición de forma asíncrona a una base de datos de RAC que se ejecuta en la región us-east4. Las instancias de la aplicación se configuran en la región us-east4 de Compute Engine para controlar el tráfico de la aplicación en caso de desastre.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia
Segundos si usas RAC |
| Desastres: Corrupciones | 0 | De minutos a horas, según la conmutación por error regional de la aplicación | |
| Desastres: Fallas de extensión de región | 0 | De minutos a horas, según la conmutación por error regional de la aplicación | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Es el tiempo necesario para actualizar y reiniciar la instancia.
Segundos si usas RAC |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas
Minutos si usas |
Modelo Platino
El modelo Platinum ofrece dos opciones de implementación. Cada opción de implementación proporciona protección con una tecnología diferente y tiene diferentes características de RTO y RPO.
Implementación Platinum 1: Data Guard con conmutación por error de inicio rápido
La implementación Platino 1 se basa en la implementación del modelo de oro, ya que agrega una segunda base de datos de Data Guard en espera en la región local que se ejecuta en una instancia de Compute Engine. Esta configuración usa la replicación síncrona entre la base de datos principal y la base de datos en espera que se ejecuta en Compute Engine, lo que proporciona una garantía de pérdida de datos cero en la región principal.
Crear una base de datos en espera en la región permite que las operaciones de conmutación por error y cambio de la base de datos se realicen sin afectar a las aplicaciones. Durante los cambios de rol de la base de datos, las aplicaciones que se configuran de acuerdo con las consideraciones para clientes de Oracle se vuelven a conectar automáticamente a la nueva base de datos principal sin necesidad de intervención manual. Las aplicaciones configuradas correctamente experimentan menos de 2 minutos de tiempo de inactividad durante un evento de conmutación por error.
Si bien la base de datos en espera de Compute Engine no ejecuta RAC, su tamaño debe ser compatible con el tráfico normal de la aplicación cuando se ejecuta como la base de datos principal. Esta instancia puede ejecutarse con una forma más pequeña mientras funciona como una instancia en espera y aumentar su escala durante los eventos de conmutación por error, o bien ejecutarse a plena capacidad en todo momento. Cambiar el tamaño de la instancia durante un evento de conmutación por error afecta negativamente el RTO, ya que la instancia se debe reiniciar durante la operación de cambio de tamaño.
La conmutación por error de inicio rápido se configura en una instancia de Compute Engine que ejecuta el agente de Data Guard con un observador. El observador ejecuta un cliente básico de Oracle con conexiones a todas las bases de datos principales y en espera. Si el observador detecta una falla en la base de datos principal, inicia una conmutación por error a una de las bases de datos en espera. La base de datos de resguardo que se ejecuta en Compute Engine se debe configurar como el destino de conmutación por error preferido cuando se usa la implementación del nivel Gold.
Oracle recomienda que el observador se coloque en una región separada de las bases de datos principal y en espera. Esto proporciona la mejor protección contra fallas regionales y eventos de particionamiento de red. Si no es posible contar con una tercera región, el observador se debe instalar en la región principal y ejecutar en una zona diferente de la región en espera cercana al sitio.
En el siguiente diagrama, se muestra una implementación de ejemplo.
La implementación de ejemplo que se muestra en el diagrama consta de lo siguiente:
- Una base de datos principal que ejecuta RAC en el servidor de la solución Bare Metal en la región
us-west2. - Una base de datos de resguardo cercana al sitio que se ejecuta en una instancia de Compute Engine en la región
us-west2 - Una base de datos en espera remota que se ejecuta en el servidor de la solución Bare Metal en la región
us-east4. - El observador de Data Guard que se ejecuta en la instancia de Compute Engine en la región
us-central1
La replicación síncrona se configura para la base de datos de resguardo en la región que se ejecuta
en la instancia de Compute Engine, y la replicación asíncrona se configura para
la región remota. En cada caso, el rehacer se envía de la base de datos principal a la
en espera; el rehacer no se reenvía de una base de datos en espera a la otra. El observador se configura en una tercera región y mantiene la conectividad con todas las bases de datos de la configuración. Las instancias de la aplicación se configuran en la región principal y se conectan a la base de datos principal en el servidor de la solución Bare Metal (o a la base de datos en la instancia de Compute Engine durante las operaciones de conmutación por error y cambio). Las instancias de la aplicación se configuran en la región us-east4 en Compute Engine para controlar el tráfico de la aplicación en caso de desastre.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia
Segundos si usas RAC |
| Desastres: Corrupciones | 0 | < 60 s | |
| Desastres: Fallas de extensión de región | 0 | < 60 s | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Es el tiempo necesario para actualizar y reiniciar la instancia.
Segundos si usas RAC |
| Actualización importante de la base de datos | 0 | De 1 a 2 horas
Minutos si usas |
Implementación de Platino 2: GoldenGate para la replicación
La implementación de platino 2 se basa en el uso de Oracle GoldenGate para la replicación. Dado que GoldenGate no se replica a nivel del bloque. Permite que cada base de datos lea y escriba sesiones de la aplicación de forma independiente. Replica los cambios de forma bidireccional, lo que permite una configuración de base de datos activa/activa.
Las aplicaciones deben validarse por completo antes de realizar la comitencia a una implementación activa/activa, y debes tener en cuenta la detección y resolución de conflictos.
A diferencia de Data Guard, GoldenGate requiere la instalación y el mantenimiento de software adicional en los servidores de bases de datos de Oracle. Por lo general, las implementaciones activas/activas requieren un diseño sofisticado de esquemas y aplicaciones para aprovechar una implementación de base de datos de varios sitios. Muchas aplicaciones empaquetadas previamente no admiten este tipo de arquitectura.
Las implementaciones que dependen de GoldenGate para toda la replicación no pueden admitir un RPO de pérdida de datos cero debido a la naturaleza asíncrona de la replicación lógica. Se pueden implementar bases de datos de resguardo locales que se ejecutan en Compute Engine con Data Guard para proporcionar un RPO de cero con replicación síncrona.
En el siguiente diagrama, se muestra una implementación de ejemplo.
| Interrupción | Tipo de interrupción | RPO | Regreso a la oficina |
|---|---|---|---|
| No planificado | Falla recuperable de nodos o instancias | 0 | Tiempo necesario para reiniciar la instancia |
| Desastres: Corrupciones | De segundos a minutos
0 si usas Data Guard en cada ubicación |
0 | |
| Desastres: Fallas de extensión de región | De segundos a minutos
0 si usas Data Guard en cada ubicación |
0 | |
| Planificada | Parches de la base de datos y actualizaciones del SO o el firmware | 0 | Es el tiempo necesario para actualizar y reiniciar la instancia.
Segundos si usas RAC |
| Actualización importante de la base de datos | 0 | 0 |