Documentación de Oracle Cloud Infrastructure

Acerca de las bases de datos en espera

Proporciona información sobre la activación y el uso de Autonomous Data Guard para la recuperación ante desastres en Autonomous Database.

Al utilizar Autonomous Data Guard, el sistema crea una base del sistema en espera que es continuamente actualizada con los cambios de la base del sistema principal. Puede utilizar Autonomous Data Guard con una base de datos en espera en la región actual, una base de datos en espera local o con una o más bases de datos en espera en diferentes regiones o bases de datos en espera entre regiones, o bien puede agregar una base de datos en espera local y una o más bases de datos en espera remotas.

También puede crear una base de datos en espera de Autonomous Data Guard, ya sea local o remota en un arrendamiento diferente.

Nota

Autonomous Data Guard está disponible con los tipos de carga de trabajo Almacén de datos y Procesamiento de transacciones. Autonomous Data Guard no está disponible con el tipo de cargas de trabajo JSON y APEX.

Al seleccionar entre las opciones de recuperación ante desastres que proporciona Autonomous Database, puede seleccionar las funciones y opciones que cumplen los requisitos de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO).

Por defecto, cada instancia de Autonomous Database proporciona una base de datos peer local de recuperación ante desastres basada en copia de seguridad.

Para agregar un failover automático y reducir el objetivo de tiempo de recuperación (RTO), puede utilizar una base de datos en espera local de Autonomous Data Guard.

Para utilizar la opción de recuperación ante desastres más resistente que ofrece Autonomous Database, puede agregar una base de datos en espera de Autonomous Data Guard local y una o más bases de datos en espera de Autonomous Data Guard entre regiones.

Además, otras opciones que utilizan la recuperación ante desastres basada en copia de seguridad le permiten proporcionar opciones de recuperación ante desastres de objetivo de tiempo de recuperación (RTO) de menor costo y mayor en comparación con Autonomous Data Guard. Consulte Uso de la Recuperación ante Desastres Basada en Copia de Seguridad para obtener más información sobre la Recuperación ante Desastres Basada en Copia de Seguridad.

Temas

Tema principal: Uso de bases de datos en espera con Autonomous Data Guard para la recuperación ante desastres

Autonomous Data Guard con base de datos en espera local

Cuando se utiliza una base de datos de Autonomous Data Guard en espera en la región actual, Autonomous Database aprovisiona una base de datos local en espera y supervisa la base de datos principal; si la base de datos principal deja de estar activa, la instancia en espera asume automáticamente el papel de la instancia principal.

Las bases de datos peer de Autonomous Data Guard locales generan el costo adicional de las CPU base y el almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento de escala automática, facturado en la propia base de datos principal. Las CPU de escala automática de la base de datos principal no se facturan además en la base de datos peer de Autonomous Data Guard local. Consulte Facturación de funciones de Oracle Autonomous Database Serverless para obtener más información.

Al agregar una base datos en espera local, se proporciona una base en espera idéntica que permite lo siguiente, según el estado de la base datos principal:

  • Si la base de datos principal deja de estar activa, Autonomous Data Guard convierte la base de datos en espera en la base de datos principal con una interrupción mínima. Una vez finalizado el failover, Autonomous Data Guard crea una nueva base de datos en espera.

  • Puede realizar una operación de switchover, en la que la base de datos principal se convierte en la base de datos en espera y la base de datos en espera se convierte en la base de datos principal.

Autonomous Database no proporciona acceso a una base de datos en espera en la región actual. Puede realizar todas las operaciones, como escalar verticalmente el recuento de OCPU (recuento de OCPU si la base del datos utiliza OCPU) y activar la escala automática de recursos informáticos en la base del datos principal, y Autonomous Data Guard realizará las mismas acciones en la base del datos en espera local. Del mismo modo, en la base de datos principal solo puede realizar acciones como parar o reiniciar la base de datos.

La base de datos en espera local se crea en la misma región que la base de datos principal (región actual). Para mejorar la flexibilidad, la base de datos en espera se aprovisiona de la siguiente manera:

  • En regiones con más de un dominio de disponibilidad, la base de datos en espera local se aprovisiona automáticamente en un dominio de disponibilidad diferente al de la base de datos principal.

  • En las regiones con un único dominio a disponibilidad, una base a datos local en espera se aprovisiona automáticamente en un dominio a errores diferente al de la base a datos principal (es decir, en una máquina física diferente).

Consulte Visualización de información de red en la consola de OCI y Regiones y dominios de disponibilidad para obtener más información sobre los dominios de disponibilidad.

Todas las funciones de la instancia de Autonomous Database de la base datos principal están disponibles cuando la instancia en espera local se convierta en la principal después de Que el sistema falle o después de realizar una operación del switchover, incluidas las siguientes:

  • Opciones de base : las opciones Recuento de ECPU (Recuento de OCPU si la base de datos utiliza OCPU), Almacenamiento, Nombre mostrado, Nombre de base de datos, Escala automática, Etiquetas y Licencias BYOL tienen los mismos valores después del failover en la base de datos en espera o tras realizar un switchover.

  • Blocs de notas de OML: los blocs de notas y usuarios creados en la base de datos principal están disponibles en la base de datos en espera.

  • Datos y metadatos de APEX: la información de APEX creada en la base de datos principal se copia en la base de datos en espera.

  • ACL: la lista de control de acceso (ACL) de la base de datos principal se duplica para la base de datos en espera.

  • Punto final privado: el punto final privado de la base de datos principal se aplica a la base de datos en espera.

    Oracle recomienda que, para las bases de datos en un punto final privado, al crear la subred, utilice la opción de subred regional para obtener una disponibilidad y una latencia óptimas. Consulte Creación de una subred para obtener más información.

  • API o scripts: cualquier API o script que utilice para gestionar Autonomous Database siguen funcionando sin cambios después de una operación de failover o después de realizar un switchover.

  • Conexiones de aplicación de cliente: las aplicaciones de cliente no necesitan cambiar sus cadenas de conexión para conectarse a la base de datos después de un failover en la base de datos en espera o después de realizar un switchover.

  • Conexiones basadas en carteras: puede seguir utilizando las carteras existentes para conectarse a la base de datos después de un failover en la base de datos en espera o después de realizar un switchover.

Acerca de las funciones entre regiones y entre arrendamientos de Autonomous Data Guard

Proporciona información sobre las funciones y el funcionamiento de Autonomous Data Guard con una base de datos en espera entre regiones o entre arrendamientos.

Al agregar una base de datos en espera en una región diferente, si la instancia principal cae, Autonomous Data Guard proporciona una base de datos en espera que está separada físicamente en una región remota. La base de datos en espera está disponible para asumir el rol de la instancia primaria no disponible. Al agregar una base de datos en espera en un arrendamiento diferente, Autonomous Data Guard proporciona una base de datos en espera que se encuentra en un arrendamiento diferente. La base de datos en espera está disponible para asumir el rol de la instancia primaria no disponible.

Las bases de datos en espera entre regiones son una réplica de las bases de datos principales y se pueden utilizar para su recuperación en caso de fallo o cuando la principal no esté disponible. La activación de Autonomous Data Guard con una Base de Datos en Espera entre Regiones proporciona una solución para la recuperación ante desastres con un nivel bajo de RTO en caso de Que una Región completa no esté disponible o Cuando la Base de Datos Principal esté caída por cualquier motivo.

Las bases de datos en espera entre regiones de Autonomous Data Guard conllevan el costo adicional de las CPU base y el doble de almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento de escala automática, facturado en la base de datos peer remota. Las CPU de escala automática del principal no se facturan adicionalmente en la base de datos peer remota. El número de CPU base se especifica por el número de ECPU (OCPU si la base de datos utiliza OCPU), como se muestra en el campo recuento de ECPU (recuento de OCPU) de la consola de Oracle Cloud Infrastructure.

Autonomous Database le permite crear una o más bases de datos peer de recuperación ante desastres remotas, en función de su modelo informático:

  • Modelo de recursos informáticos de OCPU: puede agregar una base de datos en espera remota en una región emparejada. Las regiones emparejadas son regiones remotas en la que puede crear un peer entre regiones

  • Modelo de recursos informáticos de ECPU: puede agregar varios pares de recuperación ante desastres remotos, con hasta un par en cada región emparejada remota. Por ejemplo, si la base de datos primaria está en la región IAD, puede agregar una base de datos en espera en PHX y una base de datos en espera en SJC, pero no puede agregar dos pares de recuperación ante desastres remotos en PHX.

Las regiones emparejadas son regiones remotas en la que puede crear una base de datos en espera entre las regiones. Consulte Regiones asociadas entre regiones de Autonomous Database para obtener más información sobre las regiones asociadas.

Puede realizar casi todas las operaciones, como escalar verticalmente el recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU) y activar la escala automática de recursos informáticos en la base de datos principal. A continuación, Autonomous Data Guard realiza las mismas acciones en la base de datos en espera entre regiones.

Una vez agregada una base a datos en espera remota, Autonomous Database proporciona acceso a la base en espera remota desde la consola de Oracle Cloud Infrastructure. Autonomous Database proporciona acceso a la base de datos en espera remota para que pueda realizar algunas operaciones de forma independiente en la base de datos en espera remota, como la configuración de redes y redes virtuales en la nube para puntos finales privados y la adición de etiquetado para definir claves y valores que no se replican entre la base de datos primaria y la base de datos en espera remota.

Nota

Autonomous Data Guard no realiza una conmutación por error automática para una BD en espera entre regiones. Si la Base de Datos Principal no está disponible y no hay una Base de Datos en Espera Local disponible, puede realizar un failover manual para que una Base de Datos en Espera entre Regiones asuma el rol principal.

No puede conectarse a una base de datos en espera entre regiones mientras funciona como base de datos en espera y no está disponible para operaciones de solo lectura. Puede conectarse a la base de datos en los siguientes casos:

Las siguientes áreas presentan diferencias para el failover o el switchover desde la base de Datos Principal a una base de datos en espera remota, en comparación con el failover o el switchover a una base de datos en espera local.

  • Nombre mostrado: el nombre mostrado tiene la extensión "_region". Donde región es el nombre de la región, como IAD o BOM.

    Si ha creado el par entre regiones antes de la introducción del soporte para varios pares entre regiones, el nombre mostrado del par entre regiones tiene una extensión "_Remote".

  • Cuadernos de OML: después de un switchover o failover entre regiones, los blocs de notas de OML de la base de datos principal que se ha realizado un switchover o un failover no están presentes en la base de datos principal (la base de datos principal actual después del cambio de rol). Se pueden crear nuevos blocs de notas del OML.

  • Punto final público: puede configurar y actualizar independientemente los puntos finales privados en una base de Datos en espera antes de la conmutación por error o antes de la conmutación. Esto le permite tener un punto final privado que se configura de forma diferente, después de un failover o después de realizar un switchover. Autonomous Database no mantiene la configuración del red sincronizada de la instancia principal a una instancia en espera remota.

    El intercambio de tráfico de VCN y el reenvío de dominio son necesarios para que las carteras funcionen entre regiones, con bases de datos autónomas con un punto final privado con una base de datos en espera de Autonomous Data Guard, donde la base de datos principal y la base de datos en espera se encuentran en distintas redes virtuales en la nube. Consulte Intercambio de tráfico de VCN remotas a través de una RPC y DNS en su red virtual en la nube para obtener información sobre el intercambio de tráfico de VCN y el reenvío de dominios.

  • Lista de control de acceso de red: por defecto, una base de datos principal de recuperación ante desastres y las bases de datos peer remotas utilizan las mismas listas de control de acceso de red (ACL). Opcionalmente, puede editar de forma independiente las ACL de red en una base de datos peer remota. Esto le permite utilizar diferentes ACL en una base de datos peer remota.

    Consulte Manage Remote Peer Network ACLs para obtener más información.

  • Etiquetas: las etiquetas se gestionan de forma independiente en una base de datos primaria de recuperación ante desastres y en una base de datos peer remota. Esto significa que:

    • Cuando agrega, elimina o actualiza una etiqueta en un par remoto, el cambio se aplica solo en la base de datos de pares remota.

    • Cuando agrega, actualiza o elimina una etiqueta en la principal, la etiqueta no se agrega, actualiza ni elimina en bases de datos peer remotas.

  • API o scripts: puede que sea necesario actualizar todas las API o scripts que utilice para gestionar Autonomous Database para llamar a las API de la base a datos principal.

    También puede utilizar variables de sustitución predefinidas en las URL de Oracle Cloud Infrastructure (OCI) para el failover entre regiones para Autonomous Database al utilizar las API de REST de OCI. Consulte Variables de sustitución en URL de Oracle Cloud Infrastructure (OCI) para obtener más información.

    Para las conexiones mTLS, debe descargar una cartera de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Aplicaciones cliente: las aplicaciones cliente deben conectarse mediante las cadenas de conexión y la cartera que descargue de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Conexiones basadas en cartera: debe descargar una cartera y conectarse mediante las cadenas de conexión de la base de datos primaria, la base de datos primaria actual, para conectarse a la base de datos después de un failover o después de realizar un switchover. Consulte Carteras y cadenas de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Autonomous Database Herramientas: las herramientas tienen diferentes URL en la base de datos principal, la base de datos principal actual, después de un failover o después de realizar un switchover (las URL de las herramientas no cambian para un switchover o un failover a una fuente de datos en espera local):

    • Acciones de base de datos

    • Oracle APEX

    • Oracle REST Data Services (ORDS)

    • Graph Studio

    • Oracle Machine Learning Notebooks

    • Transformaciones de datos

    • API de MongoDB

  • Uso de Oracle Cloud Infrastructure Object Storage: después de realizar un failover o un switchover de la base de datos primaria a una base de datos en espera, en la base de datos primaria (la base de datos primaria actual) las credenciales y las URL que proporcionan acceso a Object Storage siguen funcionando como lo hacían antes del failover o el switchover, lo que proporciona acceso a lo siguiente:

    • Tablas externas

    • Tablas particionadas externas

    • Tablas particionadas híbridas externas

    Nota

    Esto se aplica cuando está disponible Object Storage. En el caso de escenarios excepcionales en los que no esté disponible Object Storage, Oracle recomienda hacer copias del servicio de almacenamiento de objetos o la replicación en una región diferente. Si no está disponible Object Storage (es decir, el recurso de Object Storage que utilizó con el principal antes de realizar un switchover o un failover), puede actualizar las credenciales de usuario y los parámetros que definen las URL de Object Storage para que estos parámetros especifiquen valores para acceder a Object Storage de una región disponible. Consulte Uso de la replicación para obtener más información.

Autonomous Data Guard entre arrendamientos con base en espera en todas las regiones

Puede activar Autonomous Data Guard entre arrendamientos con una base de datos en espera entre regiones. Al agregar una base de datos en espera de Autonomous Data Guard entre arrendamientos en una región diferente, Autonomous Database aprovisiona una base de datos en espera entre regiones en el arrendamiento de destino. Con una base de datos en espera de Autonomous Data Guard entre arrendamientos, puede realizar un failover, un switchover o crear una base de datos en espera de instantánea con una base de datos en espera entre regiones en un arrendamiento diferente. Esta función permite utilizar Autonomous Data Guard para migrar una base de datos a un arrendamiento diferente.

Consulte Uso de una base de datos en espera de Autonomous Data Guard entre arrendamientos para obtener más información.

Recuperación ante desastres de pila completa de OCI con una base de datos en espera entre regiones de Autonomous Data Guard

Cuando está activada la recuperación ante desastres de pila completa, la página de detalles de Autonomous Database, en Recuperación ante desastres, muestra el campo RD de pila completa como Activado.


Descripción de adb_full_stack_dr_enabled.png a continuación
Descripción de la ilustración adb_full_stack_dr_enabled.png

Consulte Uso de OCI Full Stack Disaster Recovery con Autonomous Database para obtener más información.

Temas

Tema principal: Acerca de las bases de datos en espera

Rol de base de datos de Autonomous Data Guard

Después de agregar una base de datos en espera entre regiones, cada base de datos tiene un rol designado: principal, en espera o de instantánea en espera.

El rol especifica el estado actual de una base de datos, principal, en espera o de instantánea en espera, y este valor cambia después de realizar un switchover o un failover o después de convertir una base de datos en espera en una instantánea en espera. Puede ver el rol de Autonomous Database en el icono que aparece junto al nombre mostrado en la página Información de Autonomous Database. Por ejemplo:

A continuación se muestra la descripción de adb_adg_primary.png
Descripción de la ilustración adb_adg_primary.png

A continuación se muestra la descripción de adb_adg_standby.png
Descripción de la ilustración adb_adg_standby.png

Después de agregar una base de datos en espera entre regiones, puede ver el rol en el área Recuperación ante desastres de la página de detalles. El rol es uno de los siguientes:

  • El rol muestra principal en la base de datos principal.

  • Después de una operación de switchover o failover, en la misma base de datos, el rol muestra en espera.

  • Después de convertir un par entre regiones en una instantánea en espera, el rol se muestra como instantánea en espera.

Para ver los detalles de un peer, en la página de detalles de Autonomous Database, seleccione el separador Recuperación ante desastres. La lista muestra la información de la base de datos de peer y la columna Rol de peer muestra el rol de peer:

  • En espera (local): la columna Rol de peer muestra En espera y la base de datos tiene el mismo nombre mostrado en la columna Autonomous Database de peer. La columna Región muestra el nombre de la región actual.

  • En espera (entre regiones) La columna Rol de peer muestra En espera para una base de datos en espera remota y la base de datos tiene el mismo nombre con una extensión "_región" en la columna Autonomous Database de peer. Para acceder, haga clic en el enlace para acceder a la base de datos remota. La columna Región muestra el nombre de la región remota.

    Si ha creado el par entre regiones antes de la introducción del soporte para varios pares entre regiones, el nombre mostrado del par entre regiones tiene una extensión "_Remote".

  • Instantánea en espera: la columna Rol peer muestra Instantánea en espera. La columna Región muestra el nombre de la región remota.

Failover y switchover entre regiones de Autonomous Data Guard

Puede tener un par de recuperación ante desastres local y, opcionalmente, puede agregar uno o más pares entre regiones (se permiten varios pares entre regiones con el modelo de recursos informáticos de ECPU). Tanto en los casos locales como entre regiones, el peer puede ser una copia de recuperación ante desastres basada en copia de seguridad o una base de datos en espera de Autonomous Data Guard.

Con una región actual y una o más bases de datos peer de Autonomous Data Guard entre regiones, según el estado de la base de datos principal, tiene las siguientes opciones:

  • Si su base datos principal deja de estar activada y la base datos en espera local está disponible, Autonomous Data Guard realiza automáticamente un failover para convertir la base datos en espera local en la base, con una interrupción mínima. Una vez completado el failover, Autonomous Data Guard crea una nueva base de datos en espera local. Si no es posible realizar un failover automático, tiene la opción de realizar un failover manual.

    Autonomous Data Guard sigue utilizando las mismas bases de datos entre regiones peer.

  • Si se cae la base de datos principal y la base de datos local en espera no está disponible, puede realizar un failover manual en una base de datos peer entre regiones y la base de datos peer entre regiones en la que se realiza el failover se convierte en la base de datos principal.

    En este caso, una vez que finaliza el failover, Autonomous Data Guard no crea una nueva base de datos en espera local (por defecto, tiene un peer de copia de seguridad).

  • Puede realizar una operación de switchover en la que la base de datos principal se convierta en la base de datos en espera local y la base de datos en espera local se convierta en la base de datos principal.

    Autonomous Data Guard sigue utilizando las mismas bases de datos entre regiones peer.

  • Puede realizar una operación de switchover, en la que una base de datos peer entre regiones se convierte en la base de datos primaria (y la base de datos que era la primaria se vuelve a crear como una nueva base de datos en espera para que se convierta en una base de datos peer).

    Un switchover cambia los roles de la base de datos primaria y una base de datos peer. Si realiza una operación de switchover dos veces entre las mismas dos regiones remotas, la base de datos primaria vuelve a ser la base de datos primaria.

Restauración y copia de seguridad de la base de datos de Autonomous Data Guard entre regiones

Una vez que ha agregado una base de Datos en espera entre las regiones de Autonomous Data Guard, la copias de seguridad y las restauraciones a partir de las copias de seguridad se gestionan del siguiente modo:

  • Si la base del datos principal se restaura a partir de una copia, se crea una nueva base del sistema en espera remota a partir de la base del sistema principal restaurada.

  • Las copias de Seguridad Automáticas solo se realizan en la base de datos principal (la base de datos que muestra Rol: Principal). Por ejemplo, después de un switchover o una conmutación por error, la base de datos con el rol Principal comienza a realizar copia de seguridad automáticas. Una base de datos con el rol En espera ya no realiza copias de seguridad. Si vuelve a realizar la operación de switchover, la base de datos que se convierte en la base de datos del rol principal comienza a realizar copias de seguridad de nuevo.

  • No puede restaurar ni clonar a partir de una copia de seguridad cuando una base de datos peer tiene el rol En espera. La copia de seguridad solo se realiza en el rol Principal, y la operación de restauración no está disponible desde la consola de Oracle Cloud Infrastructure en una base de Datos En espera.

Carteras y cadenas de conexión de recuperación ante desastres entre regiones

Al agregar una base de datos en espera entre regiones (remota) de Autonomous Data Guard o al utilizar un peer de recuperación ante desastres basada en copia de seguridad entre regiones, la cartera y la cadena de conexión de la base de datos primaria solo contienen el nombre de host de la base de datos primaria.

Además, la cartera y la cadena de conexión de una base de datos peer remota solo contienen el nombre de host de la base de datos remota. Esto se aplica tanto a las carteras de instancia como a las regionales.

Oracle recomienda configurar las aplicaciones que se ejecutan en la base de datos de rol principal para utilizar la cartera o la cadena de conexión descargada de la base de datos principal. Para las aplicaciones que se ejecutan en una base de datos remota, utilice la cadena de conexión o cartera descargada de la base de datos remota (donde la base de datos remota es la base de datos primaria actual después de un failover o después de realizar un switchover). Puede obtener estas cadenas de conexión o la cartera haciendo clic en Conexión a base de datos en la consola de Oracle Cloud Infrastructure.

Por ejemplo, si Autonomous Data Guard entre regiones está configurado con la base de datos principal en Ashburn (IAD) y una base de datos en espera entre regiones en Phoenix (PHX), Oracle recomienda que las aplicaciones de nivel medio que se ejecutan en IAD utilicen la cadena de conexión o cartera de la base de datos primaria en IAD y las aplicaciones correspondientes que se ejecutan en PHX después de un failover o después de realizar un switchover, utilice la cadena de conexión o cartera de la base de datos en espera en PHX. Durante el failover o switchover regional, Oracle recomienda realizar un failover tanto de la base de datos como de las aplicaciones de nivel medio en la nueva base de datos de roles principal para obtener un rendimiento óptimo y minimizar cualquier latencia entre regiones.

Consulte Descarga de credenciales de cliente (carteras) para obtener más información.

Si lo necesita la aplicación, puede crear manualmente cadenas de conexión que contengan nombres de host de base de datos primaria y remota, para soportar la conexión a cualquier instancia que esté disponible y abierta para conexiones automáticamente, la base de datos primaria o remota.

Para obtener más información sobre los pasos para crear manualmente estas cadenas de conexión, consulte:

Autonomous Data Guard con claves gestionadas por el cliente

Al agregar una base de datos en espera entre regiones de Autonomous Data Guard, hay consideraciones especiales cuando la base de datos primaria utiliza claves gestionadas por el cliente o si desea cambiar a utilizar claves gestionadas por el cliente en la base de datos primaria.

Nota

Autonomous Database soporta varios proveedores de claves gestionadas por el cliente. Solo Oracle Cloud Infrastructure Vault está soportado para su uso con Autonomous Data Guard. Otros almacenes no están soportados para las claves gestionadas por el cliente.

Para que una base de datos en espera remota pueda utilizar la misma clave de cifrado maestra que la base de datos primaria, la clave de cifrado maestra se debe replicar en la región remota. Las claves de cifrado gestionadas por el cliente solo están soportadas con una única base de datos en espera de Autonomous Data Guard entre regiones. No están soportadas varias bases de datos en espera entre regiones porque Oracle Cloud Infrastructure Vault solo soporta la replicación en una región remota.

Considere los siguientes casos:

  • No se permite agregar una base de datos en Espera remota de Autonomous Data Guard si Autonomous Database utiliza claves gestionadas por los clientes. Cuando la base de datos utiliza una clave gestionada por el cliente y agrega una base de datos en espera entre regiones de Autonomous Data Guard, la lista Región del cuadro de diálogo Agregar base de datos peer solo muestra las regiones que contienen el almacén replicado y las claves. Si no aparece una región remota, debe replicar el almacén y las claves en la región en la que desea que aparezca la base de datos en espera (debe ser una región emparejada).

  • El cambio a claves gestionadas por el cliente se permite en la base de datos principal cuando tiene una base de datos en espera entre regiones de Autonomous Data Guard. En el caso de que la base de datos utilice claves gestionadas por Oracle y cambie a claves gestionadas por el cliente en la primaria, solo verá las claves que se replican tanto en la primaria como en la en espera. El almacén y la clave de cifrado maestra de gestión de claves de cifrado solo muestran los almacenes y las claves replicados en las regiones principal y en espera. Si no ve una clave en la lista, replique el almacén y las claves en una región emparejada.

Puede obtener más información en los siguientes enlaces:

Replicación de copias de seguridad en una base de datos en espera de Autonomous Data Guard entre regiones

Al agregar una base de datos en espera de Autonomous Data Guard entre regiones, puede activar la replicación de copia de seguridad entre regiones para que las copias de seguridad automáticas de la base de datos principal también estén disponibles en una región remota.

Por defecto, las copias de seguridad realizadas en la base de datos primaria no se replican en una base de datos en espera entre regiones. Al activar la replicación de copia de seguridad entre regiones, se replican hasta 7 días de copias de seguridad automáticas para la base de datos primaria en una base de datos en espera entre regiones. Cuando esta función está activada, las copias de seguridad automáticas están disponibles en la región remota de la siguiente manera:

  • Después de una operación de switchover o failover, puede restaurar o clonar en cualquier registro de hora de los últimos siete (7) días o en cualquier registro de hora del período de retención especificado cuando el período de retención se defina en menos de siete días.

  • Todas las copias de seguridad de la base de datos primaria que se replican en la región remota se suprimen en el par de región remota después de siete días o después del número de días del período de retención cuando el período de retención se define en menos de siete días.

  • No puede modificar el período de retención de copia de seguridad para copias de seguridad replicadas, excepto si modifica el período de retención de copia de seguridad en la base de datos primaria para especificar un valor inferior a siete días. En este caso, el período de retención para las copias de seguridad replicadas en la región remota coincide con el período de retención de copia de seguridad automática definido en la principal.

La replicación de copia de seguridad entre regiones genera un costo adicional. Consulte Facturación de funciones de Oracle Autonomous Database Serverless para obtener más información.

Consulte Adición de una Base de Datos en Espera entre Regiones y Activación o Desactivación de Replicación de Copia de Seguridad para una Base de Datos en Espera entre Regiones Existente para obtener más información.

Tenga en cuenta lo siguiente para la replicación de copia de seguridad automática entre regiones:

  • Después de un switchover o un failover, mientras que la base de datos entre regiones tiene el rol principal, las copias de seguridad se realizan en la base de datos principal actual y se replican en la base de datos en espera actual (remota).

  • En una región remota, puede crear una clonación a partir de una copia de seguridad replicada mientras la base de datos tiene el rol En espera.

Licencias BYOL entre regiones de Autonomous Data Guard

El límite de ECPU de BYOL que defina en una base de datos principal de Autonomous Data Guard no se aplica a una base de datos en espera de Autonomous Data Guard entre regiones o entre arrendamientos.

En una base de datos en espera entre regiones o entre arrendamientos, puede definir de forma independiente el límite de ECPU de BYOL, según sea necesario. La definición de un valor para el límite de licencia BYOL limita la cantidad de ECPU que cubrirán las licencias BYOL.

Por ejemplo, considere una base de datos principal de Autonomous Data Guard de 8 ECPU con licencia BYOL. Cuando agrega una base de datos en espera entre regiones o entre arrendamientos, la base de datos en espera obtiene sus licencias de la principal (mediante las licencias BYOL).

En este ejemplo, si define el límite de licencia BYOL en 4 (ECPU) en la instancia principal, 4 de las 8 ECPU utilizan la licencia BYOL. Sin embargo, el límite de licencia BYOL que define en el principal no se aplica en una base de datos en espera entre regiones o entre arrendamientos. La base de datos en espera utiliza la licencia Traiga su propia licencia (BYOL) (sin un límite de licencia BYOL). Si define por separado un límite de licencia BYOL en la base de datos en espera, por ejemplo, si define el valor Límite de licencia BYOL en 2 (ECPU), se facturarán 2 ECPU en la base de datos en espera mediante licencias BYOL y 6 ECPU. Del mismo modo, el límite de ECPU de BYOL que define en la base de datos en espera no afecta al límite de ECPU de BYOL del principal.

Consulte Elija Traiga su propia opción de licencia durante el aprovisionamiento o la clonación y Elija Traiga su propia licencia en Autonomous Database (modelo de recursos informáticos de ECPU) para obtener más información.

Objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) de Autonomous Data Guard

Autonomous Data Guard supervisa la base del datos principal y, si la instancia deja de estar activada, la instancia en espera local asume el rol de la instancia principal, de acuerdo con el objetivo de tiempo de recuperación (RTO) y con el objetivo de punto de recuperación (RPO).

Si una instancia en espera de Autonomous Data Guard local no está disponible y ha activado la recuperación ante desastres entre regiones, puede realizar una operación de failover manual a la instancia en espera entre regiones.

Si no agrega una base de datos en espera de Autonomous Data Guard entre regiones, tiene la opción de agregar un peer de recuperación ante desastres basada en copia de seguridad entre regiones. Consulte Backup-Based Disaster Recovery Time Objective (RTO) and Recovery Point Objective (RPO) para obtener más información sobre el RTO y el RPO con Backup-Based Disaster Recovery.

El RTO es el periodo máximo de tiempo necesario para restaurar la conectividad de la base de datos a una base de datos en espera después de iniciar un failover manual o automático. El RPO es la duración máxima de la pérdida potencial de datos en la base datos principal.

Base de datos en espera de Autonomous Data Guard local

Al agregar una base de datos en espera local, Autonomous Data Guard proporciona estas opciones para failover o switchover:

  • Failover o switchover automáticos:

    Al activar Autonomous Data Guard, puede seleccionar un límite de pérdida de datos. El límite de pérdida de datos predeterminado para el failover automático es 0 (los valores válidos son de 0 a 3600 segundos). Por ejemplo, un límite de pérdida de datos de 0 significa que Autonomous Data Guard solo realiza un failover automático cuando no hay pérdida de datos. Esto significa que si Autonomous Data Guard puede verificar que no hay pérdida de datos, realizará un failover automáticamente en caso de que se produzca un problema. Cuando hay un problema y Autonomous Data Guard determina que la posible pérdida de datos es mayor que el límite de pérdida de datos, no se produce el failover automático y tiene la opción de realizar un failover manual.

  • Failover manual: el RTO tiene dos (2) minutos y RPO 10 segundos.

Bases de datos en espera de Autonomous Data Guard entre regiones

Cuando se agrega una base de Datos en Espera entre Regiones, los números de RTO y RPO para la operación de failover a la Base de Datos en Espera entre Regiones de Autonomous Data Guard son los siguientes:

  • Switchover: el RTO es inferior a diez (10) minutos y el RPO es cero (0).

  • Failover automático: no disponible

  • Failover manual: el RTO es de menos de diez (10) minutos y la RPO es de hasta un (1) minuto.

Puede obtener más información en los siguientes enlaces:

Operaciones de Autonomous Data Guard

Autonomous Data Guard proporciona un juego de operaciones para gestionar una base de datos en espera, que incluye: activar, switchover, desconectar o terminar una base de datos en espera.

Operación Descripción
Convertir a Modo de Instantánea en Espera

La conversión de un par de recuperación ante desastres en una base de datos de instantánea en espera abre la base de datos en modo de lectura-escritura y el par de recuperación ante desastres entre regiones deja temporalmente de refrescar los datos de la base de datos origen.

Consulte Convertir peer entre regiones a base de datos de instantánea en espera para obtener más información.

Desactivar Autonomous Data Guard

Si tiene una base de datos en espera local o una base de datos en espera entre regiones, puede cambiar el tipo de recuperación ante desastres a Recuperación ante desastres basada en copia de seguridad para la base de datos en espera local o puede terminar una base de datos en espera entre regiones. En cualquiera de los casos, la desactivación de Autonomous Data Guard termina la base datos en espera.

Consulte Actualización de la Base de Datos en Espera para Utilizar un Par de Copia de Seguridad o Desactivación de una Base de Datos en Espera entre Regiones para obtener más información.

Desconectar en espera

Al desconectar una base de datos en espera entre regiones, la base de datos en espera se desasocia de la base de datos primaria. Esto convierte la base de datos de una base de datos peer a una base de datos independiente. Tras la operación de desconexión, no se le permite volver a conectar con el principal.

Consulte Desconexión de una base de datos peer y Desconexión de una base de datos de instantánea en espera para obtener más información.

Activar Autonomous Data Guard

Si utiliza la recuperación ante desastres basada en copia de seguridad, puede actualizar el tipo de recuperación ante desastres a Autonomous Data Guard local (región actual), o bien puede agregar una base de datos en espera entre regiones de Autonomous Data Guard.

Consulte Activación de Autonomous Data Guard y Adición de una base de datos en espera entre regiones para obtener más información.

Failover - Automático

Luego de agregar una base de datos local en espera de Autonomous Data Guard, el sistema supervisa la instancia principal y realiza un failover automático a una base de datos local en espera en determinados escenarios.

Consulte Failover automático con una base de datos en espera para más información.

Failover: Manual

Si la Base de Datos Principal no está disponible, puede realizar un failover manual para cambiar los roles a fin de convertir una Base de Datos en Espera en la Base de Datos Principal:

  • Si hay disponible una Base de Datos en Espera Local, puede realizar una operación de failover manualmente a la Base de Datos en Espera Local (no tendrá la opción de realizar una operación de failover a una Base de Datos en Espera Remota si hay una Base de Datos en Espera Local disponible).
  • Si no hay ninguna base de datos en espera local disponible, tiene la opción de realizar una conmutación por error manualmente a una base datos en espera remota.

Consulte Perform a Manual Failover para obtener más información.

Switchover

Cuando Autonomous Data Guard está activado, el switchover cambia los roles de la principal y la en espera, la Base de Datos en espera se convierte a la principal y la Base de Datos principal se convierte a la en espera. Si tiene una Base de Datos en Espera Local (región actual) y una Base de Datos en Espera entre Regiones (remota), puede elegir realizar la switchover a la Base de Datos en Espera Local o a la Base de Datos en Espera Remota.

Consulte Realizar un switchover para obtener más información.

Terminar

Si desea terminar la instancia principal, seleccione Más acción y Terminar. Al terminar la instancia principal, también termina una base datos en espera local.

Si tiene una base de datos en espera local (región actual) y una base de datos en espera entre regiones, debe terminar la base de datos en espera entre regiones antes de terminar la base de datos primaria.

Consulte Terminación de una base de datos en espera entre regiones para obtener más información.

Estado de recuperación ante desastres de la instancia de Autonomous Database

Autonomous Database proporciona información sobre el estado de recuperación ante desastres en la página Detalles de Autonomous Database.

En el área Recuperación ante desastres:

El campo Rol muestra el rol de la base de datos actual de la siguiente manera:

  • Cuando tiene un peer de copia de seguridad local o una base de datos en espera de Autonomous Data Guard local, la consola de Oracle Cloud Infrastructure muestra el valor Rol del campo Principal. Autonomous Database no proporciona acceso a una base de datos local en espera (ni a un peer de copia de seguridad local).

  • Cuando se utiliza un peer de copia de seguridad entre distintas regiones o una instancia en espera de Autonomous Data Guard entre distintas regiones, la consola de Oracle Cloud Infrastructure muestra el valor Rol del campo Principal si está visualizando la base del datos principal y muestra En espera si está visualizando los detalles de la base del datos en espera.

  • Switchover: proporciona un enlace para que pueda realizar una operación de switchover.

  • Failover: cuando la base de datos principal no está disponible, si tiene una base de datos en espera local y no se ha realizado correctamente un failover automático, el enlace de failover permite iniciar un failover manual.

    Cuando la base de datos principal no está disponible, si tiene una base de datos en espera entre regiones y no es posible realizar un failover a una base de datos en espera local, el enlace de failover permite iniciar un failover manual a la base de datos en espera remota.

Para ver la información de Autonomous Database peer, en la página de detalles de Autonomous Database, seleccione el separador Recuperación ante desastres. Muestra la información de la instancia de Autonomous Database peer. La columna Estado muestra el estado de una base de datos en espera de la siguiente manera:

  • Aprovisionamiento

    • Este estado se muestra cuando se activa Autonomous Data Guard e indica que se está aprovisionando una base del sistema en espera (hasta el cambio de estado de la base del sistema en espera a En espera).

    • Este estado se muestra después de un failover a una base de datos en espera local mientras se vuelve a crear una base de datos en espera local.

    • Este estado se muestra si se ha realizado una restauración a partir de una operación de copia de seguridad en la base de datos principal y se está volviendo a crear la base de datos en espera local, y la columna Estado muestra Aprovisionando.

  • En espera: indica que hay una base de datos en espera disponible y lista para una operación del switchover o del failover.

    Nota

    Cuando una base de datos en espera se para, el estado en espera muestra En espera. Una base de datos en espera nunca muestra el estado Parado.

  • Cambio de roles en curso:: indica que se ha iniciado una operación de failover o switchover.

Eventos de Autonomous Data Guard

Puede utilizar eventos de Oracle Cloud Infrastructure para responder cuando Autonomous Database cambie su estado debido a un evento relacionado con Autonomous Data Guard, como una operación de failover o switchover.

Los eventos de Autonomous Database son:

  • Iniciar failover automático
  • Finalizar failover automático
  • Iniciar desactivación de Autonomous Data Guard
  • Iniciar activación de Autonomous Data Guard
  • Iniciar failover
  • Iniciar switchover
  • Finalizar desactivación de Autonomous Data Guard
  • Finalizar activación de Autonomous Data Guard
  • Finalizar failover con un resultado de failover correcto o incorrecto
  • Finalizar switchover con un resultado de switchover correcto o incorrecto

En función de los eventos, puede realizar acciones o enviar notificaciones. Consulte Eventos y notificaciones con una base de datos en espera para obtener más información sobre el uso de eventos y la producción de notificaciones.