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 de datos en espera que se actualiza continuamente con los cambios de la base de datos 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, bases de datos en espera entre regiones, o 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, local o remota, en un arrendamiento diferente.

Nota

Autonomous Data Guard está disponible con los tipos de carga de trabajo Data Warehouse y Transaction Processing. Autonomous Data Guard no está disponible con los tipos de carga 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 de recuperación ante desastres basada en copia de seguridad local.

Para agregar el 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

  • Autonomous Data Guard con base de datos en espera local
    Cuando se utiliza una base de datos en espera de Autonomous Data Guard en la región actual, Autonomous Database aprovisiona una base de datos en espera local 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 rol de la instancia principal.
  • Autonomous Data Guard con base de datos en espera entre regiones
    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 principal no disponible.
  • 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 de datos principal y, si la instancia deja de estar activa, la instancia en espera local asume el rol de la instancia principal, de acuerdo con el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).
  • Operaciones de Autonomous Data Guard
    Autonomous Data Guard proporciona un juego de operaciones para gestionar una base de datos en espera, que incluye: activar, realizar switchover, desconectar o terminar una base de datos en espera.
  • Estado de recuperación ante desastres de Autonomous Database
    Autonomous Database proporciona información sobre el estado de recuperación ante desastres en la página Detalles de Autonomous Database.
  • 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.

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 en espera de Autonomous Data Guard en la región actual, Autonomous Database aprovisiona una base de datos en espera local 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 rol de la instancia principal.

Las bases de datos peer de Autonomous Data Guard locales conllevan el costo adicional de las CPU base y el almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento escalado automáticamente, que se factura en la propia base de datos principal. Las CPU de escala automática de la base de datos principal no se facturan adicionalmente 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.

La adición de una base de datos en espera local proporciona una base de datos en espera idéntica que permite lo siguiente, según el estado de la base de 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 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, y, a continuación, Autonomous Data Guard realizará las mismas acciones en la base de 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 regiones con un único dominio de disponibilidad, se provisiona automáticamente una base de datos en espera local en un dominio de errores diferente al de la base de 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 Autonomous Database de la base de datos principal están disponibles cuando la instancia en espera local se convierte en la principal, después de que el sistema falle o después de realizar una operación de switchover, incluidas las siguientes:

  • Opciones de base de datos: el recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU), el almacenamiento, el nombre mostrado, el nombre de base de datos, la escala automática, las etiquetas y las opciones de licencia BYOL tienen los mismos valores después de un failover en la base de datos en espera o después de realizar un cambio.

  • 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 de un punto final privado, al crear la subred, utilice la opción de subred regional para obtener una disponibilidad y 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.

Autonomous Data Guard con bases de datos en espera entre regiones

Al agregar una base de datos en espera en una región diferente, si la instancia principal deja de funcionar, 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 principal no disponible.

Una base de datos en espera entre regiones es una réplica de la base de datos principal y se puede utilizar para la recuperación en caso de fallo o cuando la base de datos principal no esté disponible. La activación de Autonomous Data Guard con una base de datos en espera entre regiones proporciona una solución de RTO baja para la recuperación ante desastres 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 del almacenamiento de la base de datos principal, incluido cualquier uso de almacenamiento escalado automáticamente, facturado en la base de datos peer remota. Las CPU de escala automática de la principal no se facturan adicionalmente en la base de datos peer remota. El número de CPU base se especifica mediante 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 permite crear una o más bases de datos peer de recuperación ante desastres remotas, según 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 las que puede crear un peer entre regiones.

  • Modelo de recursos informáticos de ECPU: puede agregar varios peers de recuperación ante desastres remotos, con hasta un peer 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 las que puede crear una base de datos en espera entre regiones. Consulte Regiones emparejadas entre regiones de Autonomous Database para obtener más información sobre las regiones asociadas.

Puede realizar casi todas las operaciones, como la escala vertical del recuento de ECPU (recuento de OCPU si la base de datos utiliza OCPU) y la activación de 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.

Después de agregar una base de datos en espera remota, Autonomous Database proporciona acceso a la base de datos 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 principal y la base de datos en espera remota.

Nota

Autonomous Data Guard no realiza un failover automático para una base de datos 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 en el failover o el cambio de la base de datos primaria a una base de datos en espera remota, en comparación con el failover o el cambio 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".

  • Blocs de notas 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 de OML.

  • Punto final privado: puede configurar y actualizar de forma independiente los puntos finales privados en una base de datos en espera antes del failover o antes de realizar un switchover. Esto permite tener un punto final privado configurado de forma diferente, después del failover o después de realizar una operación de switchover. Autonomous Database no mantiene la configuración de red sincronizada de la base de datos principal a una remota en espera.

    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 están en diferentes 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: de forma predeterminada, una base de datos primaria de recuperación ante desastres y 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 permite utilizar diferentes ACL en una base de datos peer remota.

    Consulte Gestión de ACL de red peer remota para obtener más información.

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

    • Al agregar, eliminar o actualizar una etiqueta en un peer remoto, el cambio se aplica solo en la base de datos peer remota.

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

  • API o scripts: todas las API o scripts que utilice para gestionar Autonomous Database se deben actualizar para llamar a las API de la base de datos primaria, la base de datos primaria actual, después de un failover o después de realizar un switchover.

    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 Cadenas y carteras de conexión de recuperación ante desastres entre regiones para obtener más información.

  • Aplicaciones de cliente: las aplicaciones de cliente deben conectarse mediante las cadenas de conexión y la cartera que descarga 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 Cadenas y carteras 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 Cadenas y carteras 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 primaria, la base de datos primaria 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 en una base de datos en espera local):

    • Database Actions

    • Oracle APEX

    • Oracle REST Data Services (ÓRDENES)

    • 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, proporcionando acceso a lo siguiente:

    • tablas externas

    • Tablas particionadas externas

    • Tablas particionadas híbridas externas

    Nota

    : esto se aplica cuando está disponible Object Storage. En los raros escenarios en los que no esté disponible Object Storage, Oracle recomienda hacer copias de seguridad o una replicación de Object Storage en una región diferente. Si no está disponible Object Storage (es decir, el recurso de Object Storage que ha utilizado con la instancia principal antes de un switchover o failover), puede actualizar las credenciales de usuario y los parámetros que definen las URL de Object Storage para que los parámetros especifiquen valores para acceder a la instancia de 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 entre 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 la recuperación ante desastres de pila completa está activada, la página de detalles de Autonomous Database, en Recuperación ante desastres, muestra el campo DR de pila completa como Activado.


A continuación se muestra la descripción de adb_full_stack_dr_enabled.png
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: primaria, en espera o de instantánea en espera.

El rol especifica el estado actual de una base de datos, principal, en espera o 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 primaria.

  • Después de un switchover o failover, en la misma base de datos, el Rol muestra En espera.

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

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 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 que la extensión "_región" en la columna Autonomous Database de peer. Puede hacer 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 de 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 peer de recuperación ante desastres local y, opcionalmente, puede agregar uno o más peers entre regiones (se permiten varios peers entre regiones con el modelo de recursos informáticos de ECPU). Tanto en los casos locales como entre regiones, cualquier 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 la base de datos principal deja de estar activa y la base de datos en espera local está disponible, Autonomous Data Guard realiza automáticamente un failover para convertir la base de datos en espera local en la base de datos principal, 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 peer entre regiones.

  • Si la base de datos principal deja de estar activa y la base de datos en espera local 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 realiza el failover se convierte en la base de datos principal.

    En este caso, una vez completado 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 peer entre regiones.

  • Puede realizar una operación de switchover en la que una base de datos peer entre regiones se convierta en la base de datos principal (y la base de datos que era la principal se vuelva 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 un switchover dos veces entre las mismas dos regiones remotas, la base de datos primaria vuelve a ser la base de datos primaria.

Copia de seguridad y restauración entre regiones de la base de datos de Autonomous Data Guard

Una vez agregada una base de datos en espera entre regiones de Autonomous Data Guard, la copia de seguridad y la restauración a partir de la copia de seguridad se gestionan de la siguiente manera:

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

  • Las copias de seguridad automáticas solo se toman en la base de datos principal (la base de datos que muestra rol: principal). Por ejemplo, después de un switchover o un failover, la base de datos con el rol Principal empieza a realizar copias de seguridad automáticas. Una base de datos con el rol En espera deja de realizar copias de seguridad. Si vuelve a realizar el switchover, la base de datos que se convierte en la base de datos con el rol Primario comenzará 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. Las copias de seguridad solo se toman en la base de datos con el rol Principal, y la operación de restauración no está disponible en 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 cadena de cartera y conexión de una base de datos peer remota sólo contiene el nombre de host de la base de datos remota. Esto se aplica tanto a carteras de instancia como regionales.

Oracle recomienda configurar las aplicaciones que se ejecutan en la base de datos de rol principal para que utilicen la cadena de cartera o 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 cartera o conexión 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 capa media que se ejecutan en IAD utilicen la cadena o cartera de conexión 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 la cartera de la base de datos en espera en PHX. Durante el failover o switchover regional, Oracle recomienda realizar un failover de la base de datos y las aplicaciones de nivel medio en la nueva base de datos de rol 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 la aplicación lo necesita, puede crear manualmente cadenas de conexión que contengan nombres de host de base de datos principal y remoto para soportar la conexión a cualquiera de las instancias que estén disponibles y abiertas para conexiones automáticamente, a la base de datos principal 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 está soportado Oracle Cloud Infrastructure Vault para su uso con Autonomous Data Guard. No se admiten otros almacenes para 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.

Tenga en cuenta los siguientes casos:

  • Se permite agregar una base de datos en espera remota de Autonomous Data Guard si Autonomous Database utiliza claves gestionadas por el cliente. 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 ve una región remota en la lista, debe replicar el almacén y las claves en la región en la que desea la base de datos en espera (debe ser una región emparejada).

  • El cambio a claves gestionadas por el cliente está permitido en la base de datos primaria 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 replicadas en las regiones primaria y en espera. En las listas Gestionar clave de cifrado Almacén y Clave de cifrado maestra solo se muestran los almacenes y las claves que se replican 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 principal 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 cualquier registro de hora en los últimos siete (7) días o cualquier registro de hora en el período de retención especificado cuando el período de retención está definido en menos de siete días.

  • Todas las copias de seguridad de la base de datos principal que se replican en la región remota se suprimen en el peer 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 copias de seguridad para copias de seguridad replicadas, excepto si modifica el período de retención de copias de seguridad en la base de datos principal para especificar un valor inferior a siete días. En este caso, el período de retención de las copias de seguridad replicadas en la región remota coincide con el período de retención de la copia de seguridad automática definido en la principal.

La replicación de copia de seguridad entre regiones conlleva 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 la 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 la base de datos entre regiones está en el rol primario, las copias de seguridad se realizan en la primaria 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 definido 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 Límite de licencia BYOL limita el número de ECPU que cubrirán las licencias BYOL.

Por ejemplo, considere una base de datos primaria 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 su licencia de la principal (mediante la licencia BYOL).

En este ejemplo, si define el límite de licencia BYOL en 4 (ECPU) en la principal, 4 de las 8 ECPU utilizan licencias BYOL. Sin embargo, el límite de licencia BYOL que defina en la base de datos 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 Bring Your Own License (BYOL) (sin un límite de licencia de BYOL). Si define por separado un límite de licencia BYOL en la base de datos en espera, por ejemplo, si define el valor de Límite de licencia BYOL en 2 (ECPU), 2 ECPU en la base de datos en espera se facturan mediante licencias BYOL y 6 ECPU. Del mismo modo, el límite de ECPU de BYOL definido en la base de datos en espera no afecta al límite de ECPU de BYOL del principal.

Consulte Selección de la opción Traiga su propia licencia durante el aprovisionamiento o la clonación y Selección de la opción 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 de Autonomous Data Guard (RTO) y objetivo de punto de recuperación (RPO)

Autonomous Data Guard supervisa la base de datos principal y, si la instancia deja de estar activa, la instancia en espera local asume el rol de la instancia principal, de acuerdo con el objetivo de tiempo de recuperación (RTO) y 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 un failover manualmente a la base de datos 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 de 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ático:

    Al activar Autonomous Data Guard, puede seleccionar un límite de pérdida de datos. El límite de pérdida de datos por defecto 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 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, realiza 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 es de dos (2) minutos y el RPO es de 10 segundos

Base de datos en espera de Autonomous Data Guard entre regiones

Al agregar una base de datos en espera entre regiones, los números de RTO y RPO para el 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 inferior a diez (10) minutos y el 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, realizar switchover, desconectar o terminar una base de datos en espera.

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

La conversión de un peer 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 peer de recuperación ante desastres entre regiones deja de refrescar temporalmente 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 cualquier caso, la desactivación de Autonomous Data Guard termina la base de datos en espera.

Consulte Actualización de la base de datos en espera para utilizar un peer 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 desasociará de la base de datos primaria. Esto convierte la base de datos de una base de datos peer en una base de datos independiente. Tras la operación de desconexión, no puede volver a conectarse a la 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 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

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

Consulte Failover automático con una base de datos en espera para obtener 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 un failover manualmente a la base de datos en espera local (no tendrá la opción de realizar un failover a una base de datos en espera remota si hay disponible una base de datos en espera local).
  • Si una base de datos en espera local no está disponible, puede realizar un failover manual a una base de datos en espera remota.

Consulte Realización de un failover manual para obtener más información.

Cambiar

Cuando Autonomous Data Guard está activado, el switchover cambia los roles de la base de datos principal y de la base de datos en espera. De este modo, la base de datos en espera se convierte en la principal y la base de datos principal se convierte en la base de datos 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 el 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 acciones y Terminar. Al terminar la instancia principal, también termina una base de 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 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 par 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 en espera local (o a un peer de copia de seguridad local).

  • Cuando se utiliza un peer de copia de seguridad entre regiones o una base de datos en espera de Autonomous Data Guard entre regiones, la consola de Oracle Cloud Infrastructure muestra el campo Rol con el valor Principal si está viendo la base de datos principal, y muestra En espera si está viendo los detalles de una base de 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 de datos en espera (hasta que el estado de la base de datos en espera cambie 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 de conmutación o de failover.

    Nota

    Cuando se para una base de datos en espera, en el estado en espera se 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.