Questa guida descrive il deployment di una configurazione Oracle Data Guard a più zone e ad alta disponibilità su un cluster standard air-gapped di Google Distributed Cloud (GDC). Questa configurazione utilizza Oracle Database Enterprise Edition e sfrutta le funzionalità esistenti di GDC per l'archiviazione e il networking.
Questo deployment utilizza l'operatore Oracle Database ufficiale per Kubernetes, che automatizza la gestione del ciclo di vita del database.
Architettura
L'architettura descrive un deployment di Oracle Database ad alta disponibilità gestito dall'operatore Oracle Database all'interno di un cluster standard GDC. Un deployment ad alta disponibilità è costituito da un database principale e un database in standby configurato con Data Guard per la replica e il failover.
I componenti chiave sono i seguenti:
- Progetto GDC: il container del progetto per le tue risorse.
- Cluster Kubernetes standard: un cluster standard che fornisce le risorse di calcolo.
- Operatore Oracle Database: un operatore Kubernetes che automatizza il provisioning, la gestione del ciclo di vita e l'osservabilità dei database Oracle. Semplifica attività complesse come l'applicazione di patch, il backup e il ripristino, semplificando l'esecuzione di carichi di lavoro Oracle stateful in un ambiente containerizzato.
- Database principale: l'istanza del database containerizzato attivo in lettura/scrittura.
- Database in standby: l'istanza del database di replica in sola lettura (o in lettura/scrittura durante il failover) .
- Data Guard Broker: orchestra la configurazione e le transizioni di ruolo (switchover/failover) tra i database.
- Harbor: il registro container privato utilizzato per ospitare le immagini del database, dell'operatore e del client nell'ambiente air-gapped.
- Cert-manager: l'operatore si basa su
cert-managerper la gestione dei certificati webhook.cert-managerè preinstallato sui cluster standard GDC.
In questa guida, esegui il deployment dell'operatore nel suo spazio dei nomi (oracle-database-operator-system) e dell'istanza del database in uno spazio dei nomi separato (oracle-dbs). Questi spazi dei nomi sono illustrati con riquadri con bordi tratteggiati nel diagramma dell'architettura.
Questa separazione è consigliata per chiarezza e gestibilità. Tuttavia, la decisione su come organizzare i database spetta a te. Ad esempio, potresti raggruppare determinati database in spazi dei nomi diversi per gestire il controllo dell'accesso granulare (RBAC) in base alle esigenze del carico di lavoro, alla proprietà del team o alle specifiche di sicurezza.
Prima di iniziare
Prima di iniziare il deployment, devi assicurarti che il tuo ambiente soddisfi i seguenti requisiti:
- Crea un progetto che fungerà da contenitore per tutte le risorse generate in questa guida.
Assegna all'utente i ruoli Amministratore cluster e Amministratore cluster standard per il progetto. In questo modo puoi creare un cluster Kubernetes standard e gestire le relative risorse:
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 un'istanza Harbor e un progetto Harbor per ospitare le immagini container necessarie per questa guida.
Assegna all'utente il ruolo Amministratore istanza Harbor in modo che possa caricare le immagini nella tua istanza Harbor:
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=harbor-instance-adminCrea un account robot Harbor nel tuo progetto Harbor. Più avanti in questa guida, le credenziali dell'account robot verranno archiviate nei secret Kubernetes, consentendo al cluster di eseguire il pull delle immagini da Harbor durante l'istanza dei container.
Crea un cluster Kubernetes standard con almeno due nodi worker, ognuno con un minimo di 16 GB di memoria. Ad esempio:
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 EOFImposta le variabili di ambiente. Queste verranno utilizzate in tutta la guida per creare e fare riferimento alle risorse:
Note:
- Le due istanze del database sono denominate arbitrariamente
blueegreenin questa guida. Inizialmente, l'istanzablueè la principale egreenè quella in standby.
# 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"- Le due istanze del database sono denominate arbitrariamente
Nota sulla rete:questa guida presuppone che venga eseguita da un nodo bastion che ha accesso alle API GDC e a internet per scaricare i manifest e le immagini container dell'operatore Oracle. Se esegui questa operazione da una macchina senza accesso a internet, devi ottenere questi asset separatamente (ad esempio, utilizzando
docker saveper esportare le immagini da una macchina connessa edocker loadper importarle) e caricarli in modo sicuro nel tuo ambiente prima di procedere.Prima di procedere, devi creare un account e ottenere un token API all'indirizzo container-registry.oracle.com, quindi accettare il contratto di licenza per le immagini Oracle Database Enterprise Edition e Oracle Instant Client.
Caricare le immagini in Harbor
Poiché i cluster all'interno di Google Distributed Cloud con air gap non possono accedere ai registri esterni, devi eseguire il mirroring delle immagini richieste nella tua istanza Harbor privata.
Accedere a Oracle Container Registry
Per prima cosa, devi eseguire l'autenticazione con il registro Oracle ufficiale per eseguire il pull delle immagini di base:
docker --config=./docker-oracle login container-registry.oracle.com
Dopo l'accesso, le credenziali verranno salvate in ./docker-oracle/config.json.
Accedere a Harbor
Esegui l'autenticazione con la tua istanza Harbor privata:
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
-u ${HARBOR_ROBOT_ACCOUNT} \
-p ${HARBOR_ROBOT_SECRET}
Dopo l'accesso, le credenziali dell'account robot verranno salvate in ./docker-harbor/config.json.
Eseguire il pull, il tag e il push delle immagini
Scarica le immagini dal registro container Oracle ufficiale ed esegui il push nel tuo progetto Harbor interno. Eseguirai il mirroring dell'operatore, del database Enterprise e del client istantaneo per i test.
Esegui il mirroring dell'immagine dell'operatore del database 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}Esegui il mirroring dell'immagine di Oracle Database 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}Esegui il mirroring dell'immagine di Oracle Instant Client:
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
Configurare l'accesso al cluster
Prima di eseguire il deployment delle risorse, recupera le credenziali per il cluster standard e crea un alias pratico:
Recupera il file kubeconfig per il cluster standard:
KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \ get-credentials ${CLUSTER_NAME} \ --standard \ --project ${PROJECT_ID} \ --zone ${ZONE}Crea l'alias
kkper semplificare i comandi successivi:alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
Creare i secret
Crea un secret Kubernetes per consentire al cluster di eseguire il pull delle immagini da Harbor utilizzando le credenziali salvate nel file ./docker-harbor/config.json locale. Questo secret è necessario sia nello spazio dei nomi dell'operatore (per eseguire il pull dell'immagine dell'operatore) sia nello spazio dei nomi del database (per eseguire il pull dell'immagine del database).
Crea lo spazio dei nomi per l'operatore:
kk create ns ${ORACLE_OPERATOR_NAMESPACE}Crea il secret di pull per l'operatore:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${ORACLE_OPERATOR_NAMESPACE}Crea lo spazio dei nomi per i database:
kk create ns ${DB_NAMESPACE}Crea il secret di pull delle immagini per i container di database:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${DB_NAMESPACE}Crea il secret per la password amministrativa dei database:
kk create secret generic ${ADMIN_PASSWORD_SECRET_NAME} \ --from-literal=password=${ADMIN_PASSWORD} \ -n ${DB_NAMESPACE}
Installare l'operatore Oracle Database
Ora installa l'operatore Oracle Database nel cluster applicando tre manifest:
Associazione di ruoli cluster: configura le autorizzazioni necessarie per il funzionamento dell'operatore a livello di cluster.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/cluster-role-binding.yamlRBAC dei nodi: concede le autorizzazioni per leggere la topologia dei nodi, che è fondamentale per la pianificazione corretta dei pod.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/node-rbac.yamlDeployment dell'operatore: esegue il deployment dei pod dell'operatore e delle definizioni di risorse personalizzate. Questo comando scarica il manifest ufficiale, sostituisce il percorso dell'immagine con l'URL di Harbor, inserisce la configurazione
imagePullSecretsin modo che Kubernetes possa eseguire l'autenticazione con Harbor e applica il risultato: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 -Attendi che i pod dell'operatore siano in esecuzione:
kk get pods -n ${ORACLE_OPERATOR_NAMESPACE} --watchL'output dovrebbe essere simile al seguente:
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
Eseguire il deployment dei database principali e in standby
Ora esegui il deployment di due istanze di database nello stesso spazio dei nomi in sequenza.
Eseguire il deployment dell'istanza principale
Esegui il comando seguente per creare l'istanza del database principale:
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"Parametri di configurazione chiave:
sid/pdbName: definisce l'identificatore di sistema (SID) e il nome del database pluggable (PDB).edition: specifica l'edizione del database (enterprisein questo caso).image: punta all'immagine del registro Harbor privato.persistence: richiede un volume permanente di 50 Gi utilizzando la StorageClassstandard-rwo, che crea un disco permanente a livello di zona in GDC.replicas: imposta il numero di pod su 1 per l'istanza.archiveLog: abilita la modalità di log di archivio, necessaria per Data Guard.flashBack: abilita Flashback Database, che ti consente di riportare il database a un punto precedente nel tempo.forceLog: abilita la registrazione forzata, assicurando che tutte le modifiche vengano registrate anche per le operazioni che normalmente ignorano la registrazione.
Per un elenco completo delle opzioni di configurazione, inclusi i parametri di inizializzazione personalizzati e i limiti delle risorse, consulta la documentazione ufficiale.
La creazione del database richiede molte risorse e potrebbe richiedere da 10 a 20 minuti.
Attendi che il database sia completamente pronto prima di procedere. Questo è fondamentale perché il database in standby richiede che il database principale sia accessibile per stabilire la replica.
Attendi che il pod del database sia
Running:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -wL'output dovrebbe essere simile al seguente:
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 99sPoi guarda i log e attendi il messaggio
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -fL'output dovrebbe contenere quanto segue:
######################### DATABASE IS READY TO USE! #########################Verifica che lo stato sia
Healthye il ruolo siaPRIMARY:kk get sidb -n ${DB_NAMESPACE} ${DB_NAME_BLUE}L'output dovrebbe essere simile al seguente:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY
Eseguire il deployment dell'istanza in standby
Una volta che il database principale è integro, esegui il deployment dell'istanza in standby. Tieni presente che i parametri di Data Guard (archiveLog, flashBack, forceLog) vengono ereditati dal database principale e non devono essere specificati nel manifest in standby:
Esegui il deployment dell'istanza in standby:
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"Attendi che il pod del database sia
Running:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -wL'output dovrebbe essere simile al seguente:
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 99sPoi guarda i log e attendi il messaggio
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -fL'output dovrebbe contenere quanto segue:
######################### DATABASE IS READY TO USE! #########################Verifica che lo stato sia
Healthye il ruolo siaPHYSICAL_STANDBY:kk get sidb -n ${DB_NAMESPACE}L'output dovrebbe essere simile al seguente:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY database-green Healthy PHYSICAL_STANDBY
Configurare Data Guard Broker
Esegui il deployment di
DataguardBrokerper gestire la configurazione di 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: trueParametri di configurazione chiave:
protectionMode: impostalo suMaxAvailabilityper garantire che non si verifichino perdite di dati se è disponibile almeno un database in standby, passando alla modalità asincrona se è raggiungibile almeno un database in standby.fastStartFailover: impostalo sufalseper disabilitare il failover automatico. Se abilitato, un processo Observer può attivare automaticamente un failover se il database principale non è disponibile.loadBalancer: impostalo sutrueper creare un servizioLoadBalancerKubernetes per il broker, fornendo un indirizzo IP esterno stabile che instrada sempre al database principale corrente.
Monitora lo stato del broker finché non viene segnalato
Healthy:kk get dataguardbroker -n ${DB_NAMESPACE} -wL'output dovrebbe essere simile al seguente:
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 servizio Kubernetes (broker-blue-green) che instrada automaticamente il traffico al database principale corrente. In questo modo viene fornito un punto di connessione stabile per le applicazioni. Ottieni questo servizio:kk get svc -n ${DB_NAMESPACE} broker-blue-greenL'output dovrebbe essere simile al seguente. Tieni presente il provisioning di un
CLUSTER-IPper i client in cluster e di unEXTERNAL-IPper i client esterni che utilizzano un bilanciatore del carico: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 8mControlla gli endpoint del servizio broker. Inizialmente deve puntare all'indirizzo IP del pod blu:
kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenL'output dovrebbe essere simile al seguente, dove l'IP del pod blu dovrebbe essere visualizzato al posto di
BLUE_POD_IP:NAME ENDPOINTS broker-blue-green [BLUE_POD_IP]:5500,[BLUE_POD_IP]:1521Controlla i pod del database per correlare l'IP:
kk get pod -n ${DB_NAMESPACE} -o wide
Testare la sincronizzazione dei dati e i ruoli
Ora verifica la replica scrivendo i dati nel database principale e leggendoli dal database in standby utilizzando un pod client in cluster.
Scrivere nel database principale con il servizio broker
Esegui il deployment di un pod temporaneo per connetterti al database principale utilizzando il servizio broker stabile:
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 tabella di test:
CREATE TABLE employees (id NUMBER, name VARCHAR2(50)); INSERT INTO employees VALUES (1, 'John Doe'); COMMIT; SELECT * FROM employees; exit;L'output dovrebbe essere simile al seguente:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Leggere dal database in standby (accesso diretto)
Esegui il deployment di un pod temporaneo per connetterti direttamente al servizio in standby:
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 replica dei dati:
SELECT * FROM employees; exit;L'output dovrebbe essere simile al seguente:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Eseguire uno switchover manuale
Attiva uno switchover manuale per invertire i ruoli, rendendo il database verde il nuovo database principale. L'operatore richiede il SID (ad esempio, ORCLGREEN) per la destinazione dello switchover.
Esegui questo comando:
kk patch dataguardbroker broker-blue-green -n ${DB_NAMESPACE} --type='merge' \ -p "{\"spec\":{\"setAsPrimaryDatabase\":\"ORCLGREEN\"}}"Monitora l'avanzamento dello switchover:
kk get sidb -n ${DB_NAMESPACE} -wAl termine dello switchover, l'output dovrebbe essere simile al seguente:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PHYSICAL_STANDBY database-green Healthy PRIMARYVerifica che le istanze del database abbiano cambiato ruolo e che il database verde sia ora il database principale:
kk get dataguardbroker -n ${DB_NAMESPACE}L'output dovrebbe essere simile al seguente:
NAME PRIMARY STANDBYS PROTECTION MODE broker-blue-green ORCLGREEN ORCLBLUE MaxAvailabilityVerifica che gli endpoint del servizio
broker-blue-greensiano stati aggiornati in modo da puntare all'IP del pod verde:kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenL'output dovrebbe essere simile al seguente, dove l'IP del pod verde dovrebbe essere visualizzato al posto di
GREEN_POD_IP:NAME ENDPOINTS broker-blue-green [GREEN_POD_IP]:5500,[GREEN_POD_IP]:1521
Passaggi successivi
- Architettura di riferimento del database Oracle autogestito
- Eseguire il deployment dei database Oracle autogestiti