In diesem Leitfaden wird die Bereitstellung einer hochverfügbaren Oracle Data Guard-Konfiguration mit mehreren Zonen in einem Google Distributed Cloud-Standardcluster (GDC) ohne Internetverbindung beschrieben. Bei dieser Einrichtung wird die Oracle Database Enterprise Edition verwendet und die vorhandenen Speicher- und Netzwerkfunktionen von GDC genutzt.
Bei dieser Bereitstellung wird der offizielle Oracle Database Operator for Kubernetes verwendet, der die Lebenszyklusverwaltung der Datenbank automatisiert.
Architektur
Die Architektur beschreibt eine hochverfügbare Oracle Database-Bereitstellung, die vom Oracle Database Operator in einem GDC-Standardcluster verwaltet wird. Eine hochverfügbare Bereitstellung besteht aus einer primären Datenbank und einer Standby-Datenbank, die mit Data Guard für die Replikation und das Failover konfiguriert sind.
Die wichtigsten Komponenten sind:
- GDC-Projekt: der Projektcontainer für Ihre Ressourcen.
- Standard-Kubernetes-Cluster: Ein Standardcluster , der die Compute-Ressourcen bereitstellt.
- Oracle Database Operator: Ein Kubernetes-Operator, der die Bereitstellung, Lebenszyklusverwaltung und Beobachtbarkeit von Oracle-Datenbanken automatisiert. Er vereinfacht komplexe Aufgaben wie Patching, Sicherung und Wiederherstellung und erleichtert so die Ausführung zustandsorientierter Oracle-Arbeitslasten in einer containerisierten Umgebung.
- Primäre Datenbank: Die aktive containerisierte Datenbankinstanz mit Lese-/Schreibzugriff.
- Standby-Datenbank: Die Datenbankinstanz mit Lesereplikat (oder Lese-/Schreibzugriff während des Failovers) .
- Data Guard-Broker: Orchestriert die Konfiguration und die Rollenübergänge (Switchover/Failover) zwischen den Datenbanken.
- Harbor: Die private Container-Registry, die zum Hosten der Datenbank-, Operator- und Client-Images in der Umgebung ohne Internetverbindung verwendet wird.
- Cert-Manager: Der Operator verwendet
cert-managerzum Verwalten von Webhook-Zertifikaten.cert-managerist in GDC-Standardclustern vorinstalliert.
In diesem Leitfaden stellen Sie den Operator in einem eigenen Namespace (oracle-database-operator-system) und die Datenbankinstanz in einem separaten Namespace (oracle-dbs) bereit. Diese Namespaces sind im Architekturdiagramm mit gestrichelten Rahmen dargestellt.
Diese Trennung wird aus Gründen der Übersichtlichkeit und Verwaltbarkeit empfohlen. Sie können jedoch selbst entscheiden, wie Sie Ihre Datenbanken organisieren. Sie können beispielsweise bestimmte Datenbanken in verschiedenen Namespaces gruppieren, um eine detaillierte Zugriffssteuerung (RBAC) basierend auf den Anforderungen der Arbeitslast, dem Team oder den Sicherheitsanforderungen zu verwalten.
Hinweis
Bevor Sie mit der Bereitstellung beginnen, müssen Sie prüfen, ob Ihre Umgebung die folgenden Anforderungen erfüllt:
- Erstellen Sie ein Projekt , das als Inhaber für alle Ressourcen dient, die in diesem Leitfaden generiert werden.
Weisen Sie Ihrem Nutzer die Rollen „Cluster Admin“ und „Standard Cluster Admin“ für Ihr Projekt zu. So können Sie einen Standard-Kubernetes-Cluster erstellen und seine Ressourcen verwalten:
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-adminErstellen Sie eine Harbor Instanz und ein Harbor Projekt um die für diesen Leitfaden erforderlichen Container-Images zu hosten.
Weisen Sie Ihrem Nutzer die Rolle „Harbor Instance Admin“ zu, damit Sie Images in Ihre Harbor-Instanz hochladen können:
gdcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="user:${USER_NAME}" \ --role=harbor-instance-adminErstellen Sie ein Harbor-Roboterkonto in Ihrem Harbor-Projekt. Später in diesem Leitfaden werden die Anmeldedaten des Roboterkontos in Kubernetes-Secrets gespeichert, sodass der Cluster beim Instanziieren von Containern Images aus Harbor abrufen kann.
Erstellen Sie einen Standard-Kubernetes-Cluster mit mindestens zwei Worker-Knoten, die jeweils mindestens 16 GB Arbeitsspeicher haben. Beispiel:
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 EOFRichten Sie Ihre Umgebungsvariablen ein. Diese werden im gesamten Leitfaden verwendet, um Ressourcen zu erstellen und darauf zu verweisen:
Hinweise:
- Die beiden Datenbankinstanzen werden in diesem Leitfaden willkürlich als
blueundgreenbezeichnet. Anfangs ist die Instanzbluedie primäre undgreendie Standby-Instanz.
# 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"- Die beiden Datenbankinstanzen werden in diesem Leitfaden willkürlich als
Hinweis zum Netzwerk:In diesem Leitfaden wird davon ausgegangen, dass er von einem Bastion-Knoten aus ausgeführt wird, der Zugriff auf die GDC-APIs und auch auf das Internet hat, um die Manifeste und Container-Images des Oracle-Operators herunterzuladen. Wenn Sie diesen Leitfaden auf einem Computer ohne Internetzugriff ausführen, müssen Sie diese Assets separat abrufen (z. B. mit
docker save, um Images von einem verbundenen Computer zu exportieren, unddocker load, um sie zu importieren) und sie sicher in Ihre Umgebung hochladen, bevor Sie fortfahren.Bevor Sie fortfahren, müssen Sie ein Konto erstellen und ein API-Token unter container-registry.oracle.com, abrufen. Akzeptieren Sie dann die Lizenzvereinbarung für die Images Oracle Database Enterprise Edition und Oracle Instant Client.
Images in Harbor laden
Da Cluster in Google Distributed Cloud mit Air Gap nicht auf externe Registries zugreifen können, müssen Sie die erforderlichen Images in Ihre private Harbor-Instanz spiegeln.
In Oracle Container Registry anmelden
Sie müssen sich zuerst bei der offiziellen Oracle-Registry authentifizieren, um die Basis-Images abzurufen:
docker --config=./docker-oracle login container-registry.oracle.com
Nach einer erfolgreichen Anmeldung werden die Anmeldedaten in ./docker-oracle/config.json gespeichert.
In Harbor anmelden
Authentifizieren Sie sich bei Ihrer privaten Harbor-Instanz:
docker --config=./docker-harbor login ${HARBOR_INSTANCE_URL} \
-u ${HARBOR_ROBOT_ACCOUNT} \
-p ${HARBOR_ROBOT_SECRET}
Nach einer erfolgreichen Anmeldung werden die Anmeldedaten des Roboterkontos in ./docker-harbor/config.json gespeichert.
Images abrufen, taggen und per Push übertragen
Laden Sie die Images aus der offiziellen Oracle Container Registry herunter und übertragen Sie sie per Push in Ihr internes Harbor-Projekt. Sie spiegeln den Operator, die Enterprise-Datenbank und den Instant Client für Tests.
Oracle Database Operator-Image spiegeln:
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}Oracle Database Enterprise-Image spiegeln:
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}Oracle Instant Client-Image spiegeln:
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
Clusterzugriff konfigurieren
Bevor Sie Ressourcen bereitstellen, rufen Sie die Anmeldedaten für Ihren Standardcluster ab und erstellen Sie einen Alias:
Kubeconfig-Datei für Ihren Standardcluster abrufen:
KUBECONFIG=kubeconfig-${CLUSTER_NAME}.yaml gdcloud clusters \ get-credentials ${CLUSTER_NAME} \ --standard \ --project ${PROJECT_ID} \ --zone ${ZONE}Erstellen Sie den Alias
kk, um nachfolgende Befehle zu vereinfachen:alias kk="kubectl --kubeconfig kubeconfig-${CLUSTER_NAME}.yaml"
Secrets erstellen
Erstellen Sie ein Kubernetes-Secret, damit der Cluster Images aus Harbor abrufen kann. Verwenden Sie dazu die Anmeldedaten, die in Ihrer lokalen Datei ./docker-harbor/config.json gespeichert sind. Sie benötigen dieses Secret sowohl im Namespace des Operators (um das Operator-Image abzurufen) als auch im Namespace der Datenbank (um das Datenbank-Image abzurufen).
Namespace für den Operator erstellen:
kk create ns ${ORACLE_OPERATOR_NAMESPACE}Pull-Secret für den Operator erstellen:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${ORACLE_OPERATOR_NAMESPACE}Namespace für die Datenbanken erstellen:
kk create ns ${DB_NAMESPACE}Image-Pull-Secret für die Datenbankcontainer erstellen:
kk create secret docker-registry ${HARBOR_PULL_SECRET_NAME} \ --from-file=.dockerconfigjson=./docker-harbor/config.json \ -n ${DB_NAMESPACE}Secret für das Administratorpasswort der Datenbanken erstellen:
kk create secret generic ${ADMIN_PASSWORD_SECRET_NAME} \ --from-literal=password=${ADMIN_PASSWORD} \ -n ${DB_NAMESPACE}
Oracle Database Operator installieren
Installieren Sie den Oracle Database Operator jetzt in Ihrem Cluster, indem Sie drei Manifeste anwenden:
Cluster Role Binding: Richtet die erforderlichen Berechtigungen für den Operator ein, damit er clusterweit funktioniert.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/cluster-role-binding.yamlKnoten-RBAC: Gewährt Berechtigungen zum Lesen der Knotentopologie, was für die korrekte Pod-Planung entscheidend ist.
kk apply -f https://raw.githubusercontent.com/oracle/oracle-database-operator/refs/tags/v${ORACLE_OPERATOR_VERSION}/rbac/node-rbac.yamlOperator-Deployment: Stellt die Operator-Pods und benutzerdefinierten Ressourcendefinitionen bereit. Mit diesem Befehl wird das offizielle Manifest heruntergeladen, der Image-Pfad durch Ihre Harbor-URL ersetzt, die Konfiguration
imagePullSecretseingefügt, damit sich Kubernetes bei Harbor authentifizieren kann, und das Ergebnis angewendet: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 -Warten Sie, bis die Operator-Pods ausgeführt werden:
kk get pods -n ${ORACLE_OPERATOR_NAMESPACE} --watchDie Ausgabe sollte so aussehen:
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
Primäre und Standby-Datenbanken bereitstellen
Sie stellen jetzt nacheinander zwei Datenbankinstanzen im selben Namespace bereit.
Primäre Instanz bereitstellen
Führen Sie den folgenden Befehl aus, um die primäre Datenbankinstanz zu erstellen:
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"Wichtige Konfigurationsparameter:
sid/pdbName: Definiert die System-ID (SID) und den Namen der plug-in-fähigen Datenbank (PDB).edition: Gibt die Datenbankversion an (enterprisein diesem Fall).image: Verweist auf das Image Ihrer privaten Harbor-Registry.persistence: Fordert ein nichtflüchtiges Volume mit 50 Gi mit der StorageClassstandard-rwoan, wodurch eine zonale nichtflüchtige Festplatte in GDC erstellt wird.replicas: Legt die Anzahl der Pods für die Instanz auf 1 fest.archiveLog: Aktiviert den Archiv-Log-Modus, der für Data Guard erforderlich ist.flashBack: Aktiviert die Flashback-Datenbank, mit der Sie die Datenbank zu einem früheren Zeitpunkt wiederherstellen können.forceLog: Aktiviert die erzwungene Protokollierung, sodass alle Änderungen protokolliert werden, auch bei Vorgängen, bei denen die Protokollierung normalerweise umgangen wird.
Eine vollständige Liste der Konfigurationsoptionen, einschließlich benutzerdefinierter Init-Parameter und Ressourcenlimits, finden Sie in der offiziellen Dokumentation.
Die Datenbankerstellung ist ressourcenintensiv und kann 10 bis 20 Minuten dauern.
Warten Sie, bis die Datenbank vollständig bereit ist, bevor Sie fortfahren. Das ist wichtig, da die Standby-Datenbank Zugriff auf die primäre Datenbank benötigt, um die Replikation einzurichten.
Warten Sie, bis der Datenbank-Pod den Status
Runninghat:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -wDie Ausgabe sollte so aussehen:
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 99sBeobachten Sie dann die Logs und warten Sie auf die Meldung
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_BLUE} -fDie Ausgabe sollte Folgendes enthalten:
######################### DATABASE IS READY TO USE! #########################Prüfen Sie, ob der Status
Healthyund die RollePRIMARYist:kk get sidb -n ${DB_NAMESPACE} ${DB_NAME_BLUE}Die Ausgabe sollte so aussehen:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY
Stand‑by-Instanz bereitstellen
Nachdem die primäre Instanz fehlerfrei ist, stellen Sie die Standby-Instanz bereit. Die Data Guard-Parameter (archiveLog, flashBack, forceLog) werden von der primären Instanz übernommen und dürfen im Standby-Manifest nicht angegeben werden:
Stand‑by-Instanz bereitstellen:
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"Warten Sie, bis der Datenbank-Pod den Status
Runninghat:kk get po -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -wDie Ausgabe sollte so aussehen:
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 99sBeobachten Sie dann die Logs und warten Sie auf die Meldung
DATABASE IS READY TO USE!:kk logs -n ${DB_NAMESPACE} -l app=${DB_NAME_GREEN} -fDie Ausgabe sollte Folgendes enthalten:
######################### DATABASE IS READY TO USE! #########################Prüfen Sie, ob der Status
Healthyund die RollePHYSICAL_STANDBYist:kk get sidb -n ${DB_NAMESPACE}Die Ausgabe sollte so aussehen:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PRIMARY database-green Healthy PHYSICAL_STANDBY
Data Guard-Broker konfigurieren
Stellen Sie
DataguardBrokerbereit, um die Data Guard-Konfiguration zu verwalten: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: trueWichtige Konfigurationsparameter:
protectionMode: Legen SieMaxAvailabilityfest, um Datenverlust zu vermeiden, wenn mindestens eine Standby-Instanz verfügbar ist. Der Modus wird auf asynchron umgestellt, wenn mindestens eine Standby-Instanz erreichbar ist.fastStartFailover: Legen Siefalsefest, um das automatische Failover zu deaktivieren. Wenn diese Option aktiviert ist, kann ein Observer-Prozess automatisch ein Failover auslösen, wenn die primäre Datenbank nicht mehr verfügbar ist.loadBalancer: Legen Sietruefest, um einen Kubernetes-Dienst vom TypLoadBalancerfür den Broker zu erstellen. Dieser Dienst bietet eine stabile externe IP-Adresse, die immer zur aktuellen primären Datenbank weiterleitet.
Beobachten Sie den Broker-Status, bis
Healthygemeldet wird:kk get dataguardbroker -n ${DB_NAMESPACE} -wDie Ausgabe sollte so aussehen:
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 falseDer
DataguardBrokererstellt einen Kubernetes-Dienst (broker-blue-green), der den Traffic automatisch zur aktuellen primären Datenbank weiterleitet. So wird ein stabiler Verbindungspunkt für Anwendungen bereitgestellt. Rufen Sie diesen Dienst ab:kk get svc -n ${DB_NAMESPACE} broker-blue-greenDie Ausgabe sollte so aussehen. Beachten Sie die Bereitstellung einer
CLUSTER-IPfür Cluster-interne Clients und einerEXTERNAL-IPfür externe Clients, die einen Load-Balancer verwenden: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 8mPrüfen Sie die Endpunkte des Broker-Dienstes. Er muss anfangs auf die IP-Adresse des blauen Pods verweisen:
kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenDie Ausgabe sollte so aussehen, wobei die IP-Adresse des blauen Pods anstelle von
BLUE_POD_IPangezeigt wird:NAME ENDPOINTS broker-blue-green [BLUE_POD_IP]:5500,[BLUE_POD_IP]:1521Prüfen Sie die Datenbank-Pods, um die IP-Adresse zu korrelieren:
kk get pod -n ${DB_NAMESPACE} -o wide
Datensynchronisierung und Rollen testen
Sie prüfen jetzt die Replikation, indem Sie Daten in die primäre Datenbank schreiben und sie über einen Cluster-internen Client-Pod aus der Standby-Datenbank lesen.
Mit dem Broker-Dienst in die primäre Datenbank schreiben
Stellen Sie einen temporären Pod bereit, um über den stabilen Broker-Dienst eine Verbindung zur primären Datenbank herzustellen:
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 sysdbaErstellen Sie eine Testtabelle:
CREATE TABLE employees (id NUMBER, name VARCHAR2(50)); INSERT INTO employees VALUES (1, 'John Doe'); COMMIT; SELECT * FROM employees; exit;Die Ausgabe sollte so aussehen:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Aus der Standby-Datenbank lesen (direkter Zugriff)
Stellen Sie einen temporären Pod bereit, um eine direkte Verbindung zum Standby-Dienst herzustellen:
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 sysdbaPrüfen Sie die Datenreplikation:
SELECT * FROM employees; exit;Die Ausgabe sollte so aussehen:
ID NAME ---------- -------------------------------------------------- 1 John Doe
Manuelles Switchover ausführen
Lösen Sie ein manuelles Switchover aus, um die Rollen umzukehren und die grüne Datenbank zur neuen primären Datenbank zu machen. Der Operator benötigt die SID (z. B. ORCLGREEN) für das Switchover-Ziel.
Führen Sie dazu diesen Befehl aus:
kk patch dataguardbroker broker-blue-green -n ${DB_NAMESPACE} --type='merge' \ -p "{\"spec\":{\"setAsPrimaryDatabase\":\"ORCLGREEN\"}}"Beobachten Sie den Switchover-Fortschritt:
kk get sidb -n ${DB_NAMESPACE} -wDie Ausgabe sollte nach Abschluss des Switchovers so aussehen:
NAME EDITION STATUS ROLE database-blue Enterprise Healthy PHYSICAL_STANDBY database-green Healthy PRIMARYPrüfen Sie, ob die Datenbankinstanzen die Rollen getauscht haben und die grüne Datenbank jetzt die primäre Datenbank ist:
kk get dataguardbroker -n ${DB_NAMESPACE}Die Ausgabe sollte so aussehen:
NAME PRIMARY STANDBYS PROTECTION MODE broker-blue-green ORCLGREEN ORCLBLUE MaxAvailabilityPrüfen Sie, ob die Endpunkte des Dienstes
broker-blue-greenaktualisiert wurden und jetzt auf die IP-Adresse des grünen Pods verweisen:kk get endpoints -n ${DB_NAMESPACE} broker-blue-greenDie Ausgabe sollte so aussehen, wobei die IP-Adresse des grünen Pods anstelle von
GREEN_POD_IPangezeigt wird:NAME ENDPOINTS broker-blue-green [GREEN_POD_IP]:5500,[GREEN_POD_IP]:1521
Nächste Schritte
- Referenzarchitektur für selbstverwaltete Oracle-Datenbanken
- Selbstverwaltete Oracle-Datenbanken bereitstellen