Esegui il deployment di database Oracle autogestiti ad alta disponibilità

Questa guida illustra il deployment di una configurazione Oracle Data Guard ad alta affidabilità su un cluster standard Google Distributed Cloud (GDC) con air gap. Questa configurazione utilizza Oracle Database Enterprise Edition e sfrutta le funzionalità esistenti di GDC per lo spazio di archiviazione e il networking.

Questo deployment utilizza l'operatore di database Oracle ufficiale per Kubernetes, che automatizza la gestione del ciclo di vita del database.

Architettura

L'architettura descrive un deployment di Oracle Database ad alta affidabilità gestito dall'operatore Oracle Database all'interno di un cluster standard GDC. Un deployment ad alta affidabilità è costituito da un database primario e da un database di standby configurati 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 computing.
• Oracle Database Operator: 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 workload Oracle stateful in un ambiente containerizzato.
• Database primario: l'istanza di database containerizzata di lettura/scrittura attiva.
• Database in standby: l'istanza del database di replica di sola lettura (o di lettura/scrittura durante il failover).
• Data Guard Broker: orchestra la configurazione e le transizioni dei ruoli (switchover/failover) tra i database.
• Harbor: il Container Registry privato utilizzato per ospitare le immagini del database, dell'operator e del client nell'ambiente con air gap.
• Cert-manager: l'operatore si basa su cert-manager per la gestione dei certificati dei webhook. cert-manager è preinstallato sui cluster standard GDC.

Importante: questa configurazione supporta l'alta affidabilità solo in una singola zona.

In questa guida, esegui il deployment dell'operatore nel proprio 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 caselle con bordo tratteggiato nel diagramma dell'architettura.

Questa separazione è consigliata per chiarezza e gestibilità. Tuttavia, spetta a te decidere come organizzare i tuoi database. Ad esempio, potresti raggruppare determinati database in spazi dei nomi diversi per gestire il controllo degli accessi granulare (RBAC) in base alle esigenze del workload, 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 al tuo utente i ruoli Amministratore cluster e Amministratore cluster standard per il tuo progetto. In questo modo puoi creare un cluster Kubernetes standard e gestirne le 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-admin
  

• Crea un'istanza Harbor e un progetto Harbor per ospitare le immagini container necessarie per questa guida.

• Assegna al tuo utente il ruolo Amministratore istanza Harbor in modo da poter caricare immagini nell'istanza Harbor:

  gdcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="user:${USER_NAME}" \
    --role=harbor-instance-admin
  

• Crea un account robot Harbor nel tuo progetto Harbor. Più avanti in questa guida, le credenziali dell'account robot verranno archiviate nei secret di Kubernetes, consentendo al cluster di eseguire il pull delle immagini da Harbor durante la creazione di istanze dei container.

• Crea un cluster Kubernetes standard con almeno due nodi worker, ciascuno con almeno 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
  EOF
  

• Configura le variabili di ambiente. Queste variabili verranno utilizzate in tutta la guida per creare e fare riferimento alle risorse:

  Note:

  • Le due istanze di database sono denominate arbitrariamente blue e green in questa guida. Inizialmente l'istanza blue è l'istanza principale, mentre green è l'istanza 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"
  

• Nota sulla rete: questa guida presuppone che l'esecuzione avvenga da un nodo bastion che ha accesso alle API GDC e a internet per scaricare i manifest e le immagini container di Oracle Operator. Se esegui questa operazione da una macchina senza accesso a internet, devi ottenere questi asset separatamente (ad esempio, utilizzando docker save per esportare le immagini da una macchina connessa e docker load per 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.

Carica le immagini in Harbor

Poiché i cluster all'interno di Google Distributed Cloud con air gap non possono accedere ai registry esterni, devi eseguire il mirroring delle immagini richieste nella tua istanza Harbor privata.

Accedi a Oracle Container Registry

Devi prima autenticarti con il registry 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.

Accedi ad 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 aver eseguito l'accesso, le credenziali dell'account robot verranno salvate in ./docker-harbor/config.json.

Esegui il pull, il tagging e il push delle immagini

Scarica le immagini dal container registry ufficiale di Oracle ed eseguine il push al tuo progetto Harbor interno. Eseguirai il mirroring dell'operatore, del database aziendale e del client istantaneo per i test.

1. 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}
   

2. Esegui il mirroring dell'immagine 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}
   

3. Esegui il mirroring dell'immagine 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
   

Configura l'accesso al cluster

Prima di eseguire il deployment delle risorse, recupera le credenziali per il tuo cluster standard e crea un alias pratico:

1. Recupera il file kubeconfig per il tuo cluster standard:

   KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \
     get-credentials ${CLUSTER_NAME} \
     --standard \
     --project ${PROJECT_ID} \
     --zone ${ZONE}
   

2. Crea l'alias kk per semplificare i comandi successivi:

   alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
   

Crea 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).

1. Crea lo spazio dei nomi per l'operatore:

   kk create ns ${ORACLE_OPERATOR_NAMESPACE}
   

2. Crea il secret pull per l'operatore:

   kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \
     --from-file=.dockerconfigjson=./docker-harbor/config.json \
     -n ${ORACLE_OPERATOR_NAMESPACE}
   

3. Crea lo spazio dei nomi per i database:

   kk create ns ${DB_NAMESPACE}
   

4. Crea il secret di pull delle immagini per i container del database:

   kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \
     --from-file=.dockerconfigjson=./docker-harbor/config.json \
     -n ${DB_NAMESPACE}
   

5. 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}
   

Installa l'operatore Oracle Database

Ora installa l'operatore Oracle Database nel tuo cluster applicando tre manifest:

1. Cluster Role Binding: 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.yaml
   

2. RBAC del nodo: concede le autorizzazioni per leggere la topologia del nodo, fondamentale per la corretta pianificazione dei pod.

   kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/node-rbac.yaml
   

3. Deployment 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 imagePullSecrets in modo che Kubernetes possa autenticarsi 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} --watch
   

   L'output dovrebbe essere simile all'esempio 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
   

Esegui il deployment dei database primari e in standby

Ora esegui il deployment di due istanze di database nello stesso spazio dei nomi in sequenza.

Esegui il deployment dell'istanza principale

1. Esegui questo comando per creare l'istanza di database primario:

   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 principali:

   • sid / pdbName: definisce l'identificatore di sistema (SID) e il nome del database pluggable (PDB).
   • edition: specifica la versione del database (enterprise in questo caso).
   • image: rimanda all'immagine del registro Harbor privato.
   • persistence: richiede un volume permanente da 50 Gi utilizzando StorageClass standard-rwo, che crea un disco permanente a livello di zona in GDC.
   • replicas: imposta il numero di pod su 1 per l'istanza.
   • archiveLog: attiva la modalità Archive Log, necessaria per Data Guard.
   • flashBack: attiva Flashback Database, consentendoti di riportare il database a un momento precedente.
   • forceLog: attiva il logging forzato, assicurando che tutte le modifiche vengano registrate, anche per le operazioni che normalmente bypassano il logging.

   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 un uso intensivo delle 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 primario sia accessibile per stabilire la replica.

   Attendi finché il pod del database non è Running:

   kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -w
   

   L'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          99s
   

   Quindi, controlla i log e attendi il messaggio DATABASE IS READY TO USE!:

   kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -f
   

   L'output dovrebbe contenere quanto segue:

   #########################
   DATABASE IS READY TO USE!
   #########################
   

2. Verifica che lo stato sia Healthy e il ruolo sia PRIMARY:

   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
   

Esegui il deployment dell'istanza in standby

Una volta che l'istanza principale è in stato integro, esegui il deployment dell'istanza in standby. Tieni presente che i parametri Data Guard (archiveLog, flashBack, forceLog) vengono ereditati dall'istanza principale e non devono essere specificati nel manifest di standby:

1. 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 finché il pod del database non è Running:

   kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -w
   

   L'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          99s
   

   Quindi, controlla i log e attendi il messaggio DATABASE IS READY TO USE!:

   kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -f
   

   L'output dovrebbe contenere quanto segue:

   #########################
   DATABASE IS READY TO USE!
   #########################
   

2. Verifica che lo stato sia Healthy e il ruolo sia PHYSICAL_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
   

Configura Data Guard Broker

1. Esegui il deployment di DataguardBroker per 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: true
   

   Parametri di configurazione principali:

   • protectionMode: impostato su MaxAvailability per garantire che non si verifichino perdite di dati se è disponibile almeno uno standby, passando alla modalità asincrona se è raggiungibile almeno uno standby.
   • fastStartFailover: impostato su false per disattivare il failover automatico. Se abilitato, un processo Observer può attivare automaticamente un failover se il database primario diventa non disponibile.
   • loadBalancer: impostato su true per creare un servizio Kubernetes LoadBalancer per il broker, fornendo un indirizzo IP esterno stabile che esegue sempre il routing al database primario corrente.

2. Monitora lo stato del broker finché non viene visualizzato Healthy:

   kk get dataguardbroker -n ${DB_NAMESPACE} -w
   

   L'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    false
   

3. DataguardBroker crea un servizio Kubernetes (broker-blue-green) che instrada automaticamente il traffico al database primario 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-green
   

   L'output dovrebbe essere simile al seguente. Tieni presente il provisioning di un CLUSTER-IP per i client nel cluster e di un EXTERNAL-IP per i client esterni utilizzando 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   8m
   

4. Controlla gli endpoint del servizio broker. Inizialmente deve puntare all'indirizzo IP del pod blu:

   kk get endpoints -n ${DB_NAMESPACE} broker-blue-green
   

   L'output dovrebbe essere simile al seguente, dove l'IP del pod blu dovrebbe apparire al posto di BLUE_POD_IP:

   NAME                ENDPOINTS
   broker-blue-green   [BLUE_POD_IP]:5500,[BLUE_POD_IP]:1521
   

5. Controlla 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 cluster primario e leggendoli dal cluster in standby utilizzando un pod client all'interno del cluster.

Scrivi nel database primario con il servizio broker

1. Esegui il deployment di un pod temporaneo per connetterti al database primario 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 sysdba
   

2. Crea 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
   

Lettura da standby (accesso diretto)

1. 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 sysdba
   

2. Verifica la replica dei dati:

   SELECT * FROM employees;
   exit;
   

   L'output dovrebbe essere simile al seguente:

           ID NAME
   ---------- --------------------------------------------------
           1 John Doe
   

Esegui un cambio manuale

Attiva uno switchover manuale per invertire i ruoli, in modo che il database verde diventi il nuovo database principale. L'operatore richiede il SID (ad esempio ORCLGREEN) per la destinazione del cambio.

1. Esegui questo comando:

   kk patch dataguardbroker broker-blue-green -n ${DB_NAMESPACE} --type='merge' \
     -p "{\"spec\":{\"setAsPrimaryDatabase\":\"ORCLGREEN\"}}"
   

2. Monitora l'avanzamento del cambio:

   kk get sidb -n ${DB_NAMESPACE} -w
   

   Una volta completato lo switchover, l'output dovrebbe essere simile al seguente:

   NAME             EDITION      STATUS    ROLE
   database-blue    Enterprise   Healthy   PHYSICAL_STANDBY
   database-green                Healthy   PRIMARY
   

3. Verifica che le istanze del database abbiano cambiato ruolo e che il database verde sia ora quello principale:

   kk get dataguardbroker -n ${DB_NAMESPACE}
   

   L'output dovrebbe essere simile all'esempio seguente:

   NAME                PRIMARY     STANDBYS   PROTECTION MODE
   broker-blue-green   ORCLGREEN   ORCLBLUE   MaxAvailability
   

4. Verifica che gli endpoint del servizio broker-blue-green siano stati aggiornati in modo da puntare all'IP del pod verde:

   kk get endpoints -n ${DB_NAMESPACE} broker-blue-green
   

   L'output dovrebbe essere simile al seguente, dove l'IP del pod verde dovrebbe apparire 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
• Esegui il deployment di database Oracle autogestiti