En esta guía, se describe la implementación de una configuración de Oracle Data Guard de alta disponibilidad y multizona en un clúster estándar aislado de Google Distributed Cloud (GDC). Esta configuración usa Oracle Database Enterprise Edition y aprovecha las capacidades existentes de GDC para el almacenamiento y la red.
En esta implementación, se usa el operador oficial de Oracle Database para Kubernetes, que automatiza la administración del ciclo de vida de la base de datos.
Arquitectura
La arquitectura describe una implementación de Oracle Database de alta disponibilidad administrada por el operador de Oracle Database dentro de un clúster estándar de GDC. Una implementación de alta disponibilidad consta de una base de datos principal y una base de datos en espera configurada con Data Guard para la replicación y la conmutación por error.
Los componentes clave son los siguientes:
- Proyecto de GDC: Es el contenedor del proyecto para tus recursos.
- Clúster estándar de Kubernetes: Es un clúster estándar que proporciona los recursos de procesamiento.
- Operador de Oracle Database: Es un operador de Kubernetes que automatiza el aprovisionamiento, la administración del ciclo de vida y la observabilidad de las bases de datos de Oracle. Simplifica tareas complejas, como la aplicación de parches, la copia de seguridad y la recuperación, lo que facilita la ejecución de cargas de trabajo de Oracle con estado en un entorno en contenedores.
- Base de datos principal: Es la instancia de base de datos en contenedores activa de lectura y escritura.
- Base de datos en espera: Es la instancia de base de datos de réplica de solo lectura (o de lectura y escritura durante la conmutación por error) .
- Agente de Data Guard: Organiza la configuración y las transiciones de roles (cambio o conmutación por error) entre las bases de datos.
- Harbor: Es el registro de contenedores privado que se usa para alojar las imágenes de la base de datos, el operador y el cliente dentro del entorno aislado.
- Cert-manager: El operador depende de
cert-managerpara administrar los certificados de webhook.cert-managerviene preinstalado en los clústeres estándar de GDC.
En esta guía, implementarás el operador en su propio espacio de nombres (oracle-database-operator-system) y la instancia de base de datos en un espacio de nombres independiente (oracle-dbs). Estos espacios de nombres se ilustran con cuadros de borde discontinuo en el diagrama de arquitectura.
Se recomienda esta separación para mayor claridad y capacidad de administración. Sin embargo, depende de ti decidir cómo organizar tus bases de datos. Por ejemplo, puedes agrupar ciertas bases de datos en diferentes espacios de nombres para administrar el control de acceso detallado (RBAC) según las necesidades de la carga de trabajo, la propiedad del equipo o las especificaciones de seguridad.
Antes de comenzar
Antes de comenzar la implementación, debes asegurarte de que tu entorno cumpla con los siguientes requisitos:
- Crea un proyecto que servirá como titular de todos los recursos generados en esta guía.
Otórgale a tu usuario los roles de administrador de clústeres y administrador de clústeres estándar para tu proyecto. Esto te permite crear un clúster estándar de Kubernetes y administrar sus recursos:
export PROJECT_ID=PROJECT_ID export USER_NAME=USER_NAME gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=cluster-admin gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=standard-cluster-adminCrea una instancia de Harbor y un proyecto de Harbor para alojar las imágenes de contenedor necesarias para esta guía.
Otórgale a tu usuario el rol de administrador de instancias de Harbor para que puedas subir imágenes a tu instancia de Harbor:
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=harbor-instance-adminCrea una cuenta de robot de Harbor en tu proyecto de Harbor. Más adelante en esta guía, las credenciales de la cuenta de robot se almacenarán en secretos de Kubernetes, lo que permitirá que el clúster extraiga imágenes de Harbor cuando se creen instancias de contenedores.
Crea un clúster estándar de Kubernetes con al menos dos nodos trabajadores, cada uno con un mínimo de 16 GB de memoria. Por ejemplo:
kubectl --kubeconfig MGMT_API_KUBECONFIG create -f - <<EOF apiVersion: cluster.gdc.goog/v1 kind: Cluster metadata: name: ${CLUSTER_NAME} namespace: ${PROJECT_ID} spec: nodePools: - machineTypeName: n3-standard-8-gdc nodeCount: 2 name: ${CLUSTER_NAME}-node-pool EOFConfigura tus variables de entorno. Se usarán en toda la guía para crear recursos y hacer referencia a ellos:
Notas:
- Las dos instancias de base de datos se denominan arbitrariamente
blueygreenen esta guía. Inicialmente, la instanciabluees la principal ygreenes la en espera.
# General info export PROJECT_ID="PROJECT_ID" export ZONE="ZONE" export ORG_NAME="ORG_NAME" export CLUSTER_NAME="CLUSTER_NAME" # Software versions export ORACLE_OPERATOR_VERSION="2.1.0" export ORACLE_DB_VERSION="21.3.0.0" # Namespaces export ORACLE_OPERATOR_NAMESPACE="ORACLE_OPERATOR_NAMESPACE" export DB_NAMESPACE="DATABASE_NAMESPACE" # Harbor config export HARBOR_INSTANCE_PROJECT_ID="HARBOR_PROJECT_ID" export HARBOR_INSTANCE_NAME="HARBOR_INSTANCE_NAME" export HARBOR_INSTANCE_URL="HARBOR_INSTANCE_URL" export HARBOR_PROJECT="HARBOR_PROJECT" export HARBOR_PULL_SECRET_NAME="HARBOR_PULL_SECRET_NAME" export HARBOR_ROBOT_ACCOUNT="robot\$HARBOR_PROJECT+ROBOT_NAME" export HARBOR_ROBOT_SECRET="HARBOR_ROBOT_SECRET" # Oracle database config export ADMIN_PASSWORD="ADMIN_PASSWORD" export ADMIN_PASSWORD_SECRET_NAME="ADMIN_PASSWORD_SECRET_NAME" # Database names export DB_NAME_BLUE="database-blue" export DB_NAME_GREEN="database-green"- Las dos instancias de base de datos se denominan arbitrariamente
Nota de red: En esta guía, se supone que se ejecuta desde un nodo bastión que tiene acceso a las APIs de GDC y también a Internet para descargar los manifiestos y las imágenes de contenedor del operador de Oracle. Si ejecutas esta operación desde una máquina sin acceso a Internet, debes obtener estos recursos por separado (por ejemplo, con
docker savepara exportar imágenes desde una máquina conectada ydocker loadpara importarlas) y subirlas de forma segura a tu entorno antes de continuar.Antes de continuar, debes crear una cuenta y obtener un token de API en container-registry.oracle.com, y, luego, aceptar el contrato de licencia para las imágenes de Oracle Database Enterprise Edition y Oracle Instant Client.
Carga imágenes en Harbor
Como los clústeres dentro de Google Distributed Cloud aislados no pueden acceder a registros externos, debes duplicar las imágenes necesarias en tu instancia privada de Harbor.
Accede a Oracle Container Registry
Primero, debes autenticarte con el registro oficial de Oracle para extraer las imágenes base:
docker --config=./docker-oracle login container-registry.oracle.com
Después de acceder correctamente, las credenciales se guardarán en ./docker-oracle/config.json.
Accede a Harbor
Autentícate con tu instancia privada de Harbor:
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
-u ${HARBOR_ROBOT_ACCOUNT} \
-p ${HARBOR_ROBOT_SECRET}
Después de acceder correctamente, las credenciales de la cuenta de robot se guardarán en ./docker-harbor/config.json.
Extrae, etiqueta y envía imágenes
Descarga las imágenes del registro oficial de contenedores de Oracle y envíalas a tu proyecto interno de Harbor. Duplicarás el operador, la base de datos empresarial y el cliente instantáneo para realizar pruebas.
Duplica la imagen del operador de la base de datos de Oracle:
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/operator:${ORACLE_OPERATOR_VERSION} \ --platform linux/amd64 docker tag container-registry.oracle.com/database/operator:${ORACLE_OPERATOR_VERSION} \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION} docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION}Duplica la imagen de la base de datos de Oracle Enterprise:
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/enterprise:${ORACLE_DB_VERSION} \ --platform linux/amd64 docker tag container-registry.oracle.com/database/enterprise:${ORACLE_DB_VERSION} \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION} docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}Duplica la imagen del cliente instantáneo de Oracle:
docker --config=./docker-oracle pull \ container-registry.oracle.com/database/instantclient:latest \ --platform linux/amd64 docker tag container-registry.oracle.com/database/instantclient:latest \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest docker --config=./docker-harbor push \ ${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest
Configura el acceso al clúster
Antes de implementar recursos, recupera las credenciales de tu clúster estándar y crea un alias conveniente:
Recupera el archivo kubeconfig para tu clúster estándar:
KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \ get-credentials ${CLUSTER_NAME} \ --standard \ --project ${PROJECT_ID} \ --zone ${ZONE}Crea el alias
kkpara simplificar los comandos posteriores:alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
Crea secretos
Crea un secreto de Kubernetes para permitir que el clúster extraiga imágenes de Harbor con las credenciales guardadas en tu ./docker-harbor/config.json local. Necesitas este secreto en el espacio de nombres del operador (para extraer la imagen del operador) y en el espacio de nombres de la base de datos (para extraer la imagen de la base de datos).
Crea el espacio de nombres para el operador:
kk create ns ${ORACLE_OPERATOR_NAMESPACE}Crea el secreto de extracción para el operador:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${ORACLE_OPERATOR_NAMESPACE}Crea el espacio de nombres para las bases de datos:
kk create ns ${DB_NAMESPACE}Crea el secreto de extracción de imágenes para los contenedores de la base de datos:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${DB_NAMESPACE}Crea el secreto para la contraseña administrativa de las bases de datos:
kk create secret generic ${ADMIN_PASSWORD_SECRET_NAME} \ --from-literal=password=${ADMIN_PASSWORD} \ -n ${DB_NAMESPACE}
Instala el operador de Oracle Database
Ahora, instala el operador de Oracle Database en tu clúster aplicando tres manifiestos:
Vinculación de roles de clúster: Configura los permisos necesarios para que el operador funcione en todo el clúster.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/cluster-role-binding.yamlRBAC de nodos: Otorga permisos para leer la topología de nodos, lo que es fundamental para la programación correcta de pods.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/node-rbac.yamlImplementación del operador: Implementa los pods del operador y las definiciones de recursos personalizados. Este comando descarga el manifiesto oficial, reemplaza la ruta de acceso de la imagen por tu URL de Harbor, inserta la configuración
imagePullSecretspara que Kubernetes pueda autenticarse con Harbor y aplica el resultado:curl -L https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/oracle-database-operator.yaml \ | sed "s|container-registry.oracle.com/database/operator:latest|${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-operator:${ORACLE_OPERATOR_VERSION}|g" \ | awk "/terminationGracePeriodSeconds: 10/{print; print \" imagePullSecrets:\n - name: ${HARBOR_PULL_SECRET_NAME}\"; next}1" \ | kk apply -f -Espera a que se ejecuten los pods del operador:
kk get pods -n ${ORACLE_OPERATOR_NAMESPACE} --watchEl resultado debe verse de la siguiente manera:
NAME READY STATUS RESTARTS AGE oracle-database-operator-controller-manager-5f7b56874d-k9v4z 1/1 Running 0 45s oracle-database-operator-controller-manager-5f7b56874d-n2x8m 1/1 Running 0 45s oracle-database-operator-controller-manager-5f7b56874d-r6z7q 1/1 Running 0 45s
Implementa bases de datos principal y en espera
Ahora, implementarás dos instancias de base de datos en el mismo espacio de nombres de forma secuencial.
Crea la instancia principal
Ejecuta el siguiente comando para crear la instancia de base de datos principal:
apiVersion: database.oracle.com/v4 kind: SingleInstanceDatabase metadata: name: ${DB_NAME_BLUE} namespace: ${DB_NAMESPACE} spec: replicas: 1 edition: enterprise image: pullFrom: "${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}" pullSecrets: ${HARBOR_PULL_SECRET_NAME} prebuiltDB: true sid: ORCLBLUE pdbName: ORCLPDB1 archiveLog: true flashBack: true forceLog: true adminPassword: secretName: "${ADMIN_PASSWORD_SECRET_NAME}" secretKey: "password" persistence: size: "50Gi" storageClass: "standard-rwo" accessMode: "ReadWriteOnce" resources: requests: memory: "4Gi"Parámetros de configuración clave:
sid/pdbName: Define el identificador del sistema (SID) y el nombre de la base de datos conectable (PDB).edition: Especifica la edición de la base de datos (enterpriseen este caso).image: Apunta a la imagen de tu registro privado de Harbor.persistence: Solicita un volumen persistente de 50 Gi con la StorageClassstandard-rwo, que crea un disco persistente zonal en GDC.replicas: Establece la cantidad de pods en 1 para la instancia.archiveLog: Habilita el modo de registro de archivo, que es necesario para Data Guard.flashBack: Habilita la base de datos flashback, lo que te permite regresar la base de datos a un momento anterior.forceLog: Habilita el registro forzado, lo que garantiza que se registren todos los cambios, incluso para las operaciones que normalmente omiten el registro.
Para obtener una lista completa de las opciones de configuración, incluidos los parámetros de inicialización personalizados y los límites de recursos, consulta la documentación oficial.
La creación de la base de datos requiere muchos recursos y puede tardar entre 10 y 20 minutos.
Espera a que la base de datos esté completamente lista antes de continuar. Esto es fundamental porque la base de datos en espera requiere que se pueda acceder a la principal para establecer la replicación.
Espera hasta que el pod de la base de datos sea
Running:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -wEl resultado debería ser similar al siguiente:
NAME READY STATUS RESTARTS AGE database-blue-i5xdj 0/1 Pending 0 0s database-blue-i5xdj 0/1 Pending 0 0s database-blue-i5xdj 0/1 Pending 0 1s database-blue-i5xdj 0/1 Init:0/1 0 1s database-blue-i5xdj 0/1 PodInitializing 0 98s database-blue-i5xdj 0/1 Running 0 99s database-blue-i5xdj 1/1 Running 0 99sLuego, observa los registros y espera el mensaje
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -fEl resultado debería contener lo siguiente:
######################### DATABASE IS READY TO USE! #########################Verifica que el estado sea
Healthyy el rol seaPRIMARY:kk get sidb -n ${DB_NAMESPACE} ${DB_NAME_BLUE}El resultado debe verse de la siguiente manera:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY
Implementa la instancia en espera
Una vez que la instancia principal esté en buen estado, implementa la instancia en espera. Ten en cuenta que los parámetros de Data Guard (archiveLog, flashBack, forceLog) se heredan de la instancia principal y no se deben especificar en el manifiesto en espera:
Implementa la instancia en espera:
apiVersion: database.oracle.com/v4 kind: SingleInstanceDatabase metadata: name: ${DB_NAME_GREEN} namespace: ${DB_NAMESPACE} spec: replicas: 1 edition: enterprise image: pullFrom: "${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-enterprise:${ORACLE_DB_VERSION}" pullSecrets: ${HARBOR_PULL_SECRET_NAME} prebuiltDB: true sid: ORCLGREEN pdbName: ORCLPDB1 adminPassword: secretName: "${ADMIN_PASSWORD_SECRET_NAME}" secretKey: "password" createAs: standby primaryDatabaseRef: ${DB_NAME_BLUE} persistence: size: "50Gi" storageClass: "standard-rwo" accessMode: "ReadWriteOnce" resources: requests: memory: "4Gi"Espera hasta que el pod de la base de datos sea
Running:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -wEl resultado debería ser similar al siguiente:
NAME READY STATUS RESTARTS AGE database-green-q1gur 0/1 Pending 0 0s database-green-q1gur 0/1 Pending 0 0s database-green-q1gur 0/1 Pending 0 1s database-green-q1gur 0/1 Init:0/1 0 1s database-green-q1gur 0/1 PodInitializing 0 98s database-green-q1gur 0/1 Running 0 99s database-green-q1gur 1/1 Running 0 99sLuego, observa los registros y espera el mensaje
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -fEl resultado debería contener lo siguiente:
######################### DATABASE IS READY TO USE! #########################Verifica que el estado sea
Healthyy el rol seaPHYSICAL_STANDBY:kk get sidb -n ${DB_NAMESPACE}El resultado debe verse de la siguiente manera:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY database-green Healthy PHYSICAL_STANDBY
Configura el agente de Data Guard
Implementa
DataguardBrokerpara administrar la configuración de Data Guard:apiVersion: database.oracle.com/v4 kind: DataguardBroker metadata: name: broker-blue-green namespace: ${DB_NAMESPACE} spec: primaryDatabaseRef: ${DB_NAME_BLUE} standbyDatabaseRefs: - ${DB_NAME_GREEN} protectionMode: MaxAvailability fastStartFailover: false loadBalancer: trueParámetros de configuración clave:
protectionMode: Se establece enMaxAvailabilitypara garantizar que no haya pérdida de datos si al menos una instancia en espera está disponible y que se realice la transición al modo asíncrono si se puede acceder a al menos una instancia en espera.fastStartFailover: Se establece enfalsepara inhabilitar la conmutación por error automática. Cuando está habilitado, un proceso de observador puede activar automáticamente una conmutación por error si la base de datos principal deja de estar disponible.loadBalancer: Se establece entruepara crear un servicioLoadBalancerde Kubernetes para el agente, lo que proporciona una dirección IP externa estable que siempre enruta a la base de datos principal actual.
Supervisa el estado del agente hasta que informe
Healthy:kk get dataguardbroker -n ${DB_NAMESPACE} -wEl resultado debería ser similar al siguiente:
NAME PRIMARY STANDBYS PROTECTION MODE CONNECT STR STATUS FSFO broker-blue-green MaxAvailability Creating broker-blue-green MaxAvailability Creating broker-blue-green ORCLBLUE ORCLGREEN MaxAvailability 10.0.0.25:32345/DATAGUARD Creating false broker-blue-green ORCLBLUE ORCLGREEN MaxAvailability 10.0.0.25:32345/DATAGUARD Healthy falseDataguardBrokercrea un servicio de Kubernetes (broker-blue-green) que enruta automáticamente el tráfico a la base de datos principal actual. Esto proporciona un punto de conexión estable para las aplicaciones. Obtén este servicio:kk get svc -n ${DB_NAMESPACE} broker-blue-greenEl resultado debería ser el siguiente. Ten en cuenta el aprovisionamiento de una
CLUSTER-IPpara los clientes del clúster y unaEXTERNAL-IPpara los clientes externos que usan un balanceador de cargas:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE broker-blue-green LoadBalancer 10.0.19.198 100.66.38.138 1521:31116/TCP,5500:31842/TCP 8mVerifica los extremos del servicio del agente. Inicialmente, debe apuntar a la dirección IP del pod azul:
kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenEl resultado debería ser similar al siguiente, en el que debería aparecer la IP del pod azul en lugar de
BLUE_POD_IP:NAME ENDPOINTS broker-blue-green [BLUE_POD_IP]:5500,[BLUE_POD_IP]:1521Verifica los pods de la base de datos para correlacionar la IP:
kk get pod -n ${DB_NAMESPACE} -o wide
Prueba la sincronización de datos y los roles
Ahora, verificarás la replicación escribiendo datos en la instancia principal y leyéndolos desde la instancia en espera con un pod de cliente en el clúster.
Escribe en la base de datos principal con el servicio del agente
Implementa un pod temporal para conectarte a la base de datos principal con el servicio estable del agente:
kk run sqlplus -n ${DB_NAMESPACE} --rm -it --restart=Never \ --image=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest \ --image-pull-policy=Always \ --overrides='{"spec": {"imagePullSecrets": [{"name": "'${HARBOR_PULL_SECRET_NAME}'"}]}}' \ -- sqlplus sys/${ADMIN_PASSWORD}@broker-blue-green:1521/ORCLPDB1 as sysdbaCrea una tabla de prueba:
CREATE TABLE employees (id NUMBER, name VARCHAR2(50)); INSERT INTO employees VALUES (1, 'John Doe'); COMMIT; SELECT * FROM employees; exit;El resultado debería ser similar al siguiente:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Lee desde la instancia en espera (acceso directo)
Implementa un pod temporal para conectarte directamente al servicio en espera:
kk run sqlplus -n ${DB_NAMESPACE} --rm -it --restart=Never \ --image=${HARBOR_INSTANCE_URL}/${HARBOR_PROJECT}/oracle-instantclient:latest \ --image-pull-policy=Always \ --overrides='{"spec": {"imagePullSecrets": [{"name": "'${HARBOR_PULL_SECRET_NAME}'"}]}}' \ -- sqlplus sys/${ADMIN_PASSWORD}@${DB_NAME_GREEN}:1521/ORCLPDB1 as sysdbaVerifica la replicación de datos:
SELECT * FROM employees; exit;El resultado debería ser similar al siguiente:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Realiza un cambio manual
Activa un cambio manual para invertir los roles, lo que convierte a la base de datos verde en la nueva principal. El operador requiere el SID (por ejemplo, ORCLGREEN) para el destino del cambio.
Ejecuta el siguiente comando:
kk patch dataguardbroker broker-blue-green -n ${DB_NAMESPACE} --type='merge' \ -p "{\"spec\":{\"setAsPrimaryDatabase\":\"ORCLGREEN\"}}"Supervisa el progreso del cambio:
kk get sidb -n ${DB_NAMESPACE} -wEl resultado debería ser similar al siguiente una vez que se complete el cambio:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PHYSICAL_STANDBY database-green Healthy PRIMARYConfirma que las instancias de base de datos hayan cambiado de rol y que la base de datos verde ahora sea la principal:
kk get dataguardbroker -n ${DB_NAMESPACE}El resultado debe verse de la siguiente manera:
NAME PRIMARY STANDBYS PROTECTION MODE broker-blue-green ORCLGREEN ORCLBLUE MaxAvailabilityVerifica que los extremos de servicio
broker-blue-greense hayan actualizado para apuntar a la IP del pod verde:kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenEl resultado debería ser similar al siguiente, en el que debería aparecer la IP del pod verde en lugar de
GREEN_POD_IP:NAME ENDPOINTS broker-blue-green [GREEN_POD_IP]:5500,[GREEN_POD_IP]:1521
¿Qué sigue?
- Arquitectura de referencia de la base de datos de Oracle autoadministrada
- Implementa bases de datos de Oracle autoadministradas