Konfigurieren der gemeinsamen Protokollarchivierung für Db2 HADR

Sie können die gemeinsame Protokollarchivierung für Bereitstellungen mit mehreren Standby-HADR-Datenbanken im selben Cluster und Namespace konfigurieren. Diese Konfiguration verhindert, dass archivierte Protokolldateien manuell von einer alten Primärdatenbank in die neue Primärdatenbank kopiert werden müssen, wenn dies von Hilfs-Standby-Datenbanken in einem Übernahme-Szenario angefordert wird.

Informationen zu dieser Task

Sie können die gemeinsame Protokollarchivierung nur für Db2uCluster oder Db2uInstance benutzerdefinierte Ressourcen konfigurieren, die sich im selben Kubernetes Namespace befinden. Weitere Informationen finden Sie unter Konfiguration der Protokollarchivierung für Db2 Hochverfügbarkeits-Disaster-Recovery (HADR).

In einer containerisierten Umgebung kann ein gemeinsamer Archivspeicher für Protokolle erreicht werden, indem ein separater Protokollarchivspeicherbereich auf der dafür vorgesehenen primären Db2 benutzerdefinierten Ressource (CR) festgelegt und auf den vorhandenen Persistent Volume Claim (PVC) in den Standby-CRs verwiesen wird.

Um die gemeinsame Protokollarchivierung für Db2 HADR zu konfigurieren, müssen Sie je nach Ihrer Bereitstellung eines der folgenden Verfahren ausführen:

Für neue Bereitstellungen
Für bestehende Bereitstellungen mit konfiguriertem und ausgeführtem HADR

Für neue Bereitstellungen

Vorgehensweise

Fügen Sie dem CR ein archivelogs Speicherfeld hinzu.
Es ist wichtig, dass die folgenden Punkte in der Spezifikation für die Lagerung enthalten sind:
1. Für den Speichertyp verwenden Sie create Die
2. Verwenden Sie für den ReadWriteMany Zugriffsmodus, um sicherzustellen, dass die PVC von mehreren Pods gemeinsam genutzt werden kann.
3. Verwenden Sie für „storageClassName “ den Namen der Speicherklasse, die Sie für die Datenspeicherung verwenden.
Weitere Informationen finden Sie unter Erstellen von Archivprotokollspeicher für eine neue Bereitstellung von Db2 auf Red Hat® OpenShift.

Das folgende Beispiel zeigt die Syntax des Abschnitts „Archivprotokollspeicherbereich“ einer Db2 CR-Definition, die Red Hat® OpenShift® Container Platform für ocs-storagecluster-cephfs verwendet.
```
spec:
  storage:
    - name: archivelogs
      type: "create"
      spec:
        storageClassName: "ocs-storagecluster-cephfs"
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 30Gi
```
Erstellen Sie die primären und sekundären Db2 Standby-Systeme. Verweisen Sie auf das Archivprotokoll PVC des vorhandenen Primärreplikats.
Das folgende Beispiel zeigt die Syntax des Abschnitts „Archivprotokollspeicherbereich“ einer Db2 CR-Definition, die einen vorhandenen Anspruch verwendet. Ersetzen Sie DB2_PRIMARY_NAME durch den Namen des in Schritt 1 Db2uInstance festgelegten Primär- Db2uCluster oder.
```
spec:
  storage:
    - claimName: c-<DB2_PRIMARY_NAME>-archivelogs
      name: archivelogs
      spec:
        resources: {}
      type: existing
```

Für bestehende Bereitstellungen mit konfiguriertem und ausgeführtem HADR

Vorgehensweise

Wenn HADR bereits konfiguriert ist und ausgeführt wird, beschreiben die folgenden Schritte, wie Sie ein separates Archivprotokoll-PVC für den festgelegten Primär- Db2uCluster oder Db2uInstance CR erstellen und wie Sie den Speicherort des Archivprotokolls für jede Datenbank neu konfigurieren. Dieser Vorgang erfordert eine geplante Ausfallzeit.

Setzen Sie die Umgebungsvariablen mit den für Ihre Umgebung geeigneten Werten:

DB2_CR_PRIMARY=<Name of primary Db2uCluster CR/Name of primary Db2uInstance CR>

DB2_CR_STANDBY=<Name of principal standby Db2uCluster CR/Name of principal standby Db2uInstance CR>

DB2_CR_AUX=<Name of auxiliary standby Db2uCluster CR/Name of auxiliary standby Db2uInstance CR>

Beenden Sie HADR auf allen Standby-Pods (Haupt- Db2 und Hilfs-Pods) mit dem folgenden Befehl:

oc exec -it c-${DB2_CR_STANDBY}-db2u-0 -- manage_hadr -stop
oc exec -it c-${DB2_CR_AUX}-db2u-0 -- manage_hadr -stop

Beenden Sie HADR auf dem primären Db2 Pod:

oc exec -it c-${DB2_CR_PRIMARY}-db2u-0 -- manage_hadr -stop

Bearbeiten Sie den primären Db2uCluster oder Db2uInstance CR und fügen Sie einen separaten archivelogs Speicherbereich hinzu.
Es ist wichtig, dass die folgenden Punkte in der Spezifikation für die Lagerung enthalten sind:
1. Für den Speichertyp verwenden Sie create Die
2. Verwenden Sie für den ReadWriteMany Zugriffsmodus, um sicherzustellen, dass die PVC von mehreren Pods gemeinsam genutzt werden kann.
3. Verwenden Sie für „storageClassName “ den Namen der Speicherklasse, die Sie für die Datenspeicherung verwenden.
Das folgende Beispiel zeigt die Syntax des Abschnitts „Archivprotokollspeicherbereich“ einer Db2 CR-Definition, die Red Hat OpenShift Container Platform für ocs-storagecluster-cephfs verwendet.
```
spec:
  storage:
    - name: archivelogs
      type: "create"
      spec:
        storageClassName: "ocs-storagecluster-cephfs"
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 30Gi
```
Verwenden Sie den folgenden Befehl, um den Primär- Db2uCluster oder Db2uInstance CR zu bearbeiten:
```
oc edit db2ucluster ${DB2_CR_PRIMARY}
```
```
oc edit db2uinstance ${DB2_CR_PRIMARY}
```

Warten Sie, bis primary Db2uCluster oder den Ready Status Db2uInstance erreicht hat, und bestätigen Sie, dass das Archivprotokoll-PVC erstellt wurde:

oc get pvc -l formation_id=${DB2_CR_PRIMARY}

Das folgende Beispiel zeigt die PVCs, die mit dem primären Db2uCluster oder Db2uInstancec-db2oltp-primary-archivelogs assoziiert sind, ist die neu erstellte PVC:

# oc get pvc -l formation_id=db2oltp-primary

NAME                            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE

c-db2oltp-primary-archivelogs   Bound    pvc-21184a4a-e5d5-4170-a15b-6cb352311cd6   30Gi       RWX            managed-nfs-storage   5m

c-db2oltp-primary-backup        Bound    pvc-2e62ca48-c871-46f7-bafb-8e64b894bb57   50Gi       RWX            managed-nfs-storage   172m

c-db2oltp-primary-meta          Bound    pvc-ece8e06a-3843-4abe-a892-c11f6a62d158   100Gi      RWX            managed-nfs-storage   172m

data-c-db2oltp-primary-db2u-0   Bound    pvc-419154fb-8b1c-4b98-a328-1355f69340d5   100Gi      RWO            managed-nfs-storage   170m

Bestätigen Sie, dass der Archivprotokollpfad in der Konfigurationszuordnung mit Db2 den Konfigurationen aktualisiert wurde. Diese Konfigurationszuordnung heißt c-<DB2_CR>-db2dbconfigund der LOGARCHMETH1 DISK Wert muss auf /mnt/logs/archivegesetzt werden. Wenn er nicht richtig eingestellt ist, aktualisieren Sie den Wert manuell.
```
oc get cm c-${DB2_CR_PRIMARY}-db2dbconfig -ojsonpath='{.data.dbConfig}' | grep -i LOGARCHMETH1
```
Die folgende Ausgabe ist ein Beispiel für den erwarteten Wert:
```
# oc get cm c-db2oltp-primary-db2dbconfig -ojsonpath='{.data.dbConfig}' | grep -i LOGARCHMETH1

LOGARCHMETH1 DISK:/mnt/logs/archive
```
Führen Sie den folgenden Befehl aus, um den primären Db2 Pod auszuführen:
```
oc exec -it c-${DB2_CR_PRIMARY}-db2u-0 -- bash
```
Ändern Sie die Eigentumsrechte für den neuen Archivprotokollspeicher auf den Db2 Instanzbesitzer und aktualisieren Sie die Db2 Konfigurationseinstellungen.
```
chown -R db2inst1:db2iadm1 /mnt/logs/archive/

su - db2inst1 -c "/db2u/scripts/apply-db2cfg-settings.sh"
```
Hinweis: Ignorieren Sie Fehlermeldungen zu Wolverine, da der Hochverfügbarkeitsmechanismus deaktiviert ist, wenn HADR aktiviert ist
Fügen Sie einen separaten archivelog Speicherbereich zum Haupt-Standby Db2uCluster hinzu oder Db2uInstance und verweisen Sie dabei auf das vorhandene PVC vom Primärspeicher. Verwenden Sie den folgenden Befehl, um die Db2uCluster oder Db2uInstance CR zu bearbeiten:
```
oc edit db2ucluster ${DB2_CR_STANDBY}
```
```
oc edit db2uinstance ${DB2_CR_STANDBY}
```
Das folgende Beispiel zeigt die Syntax des Abschnitts „Archivprotokollspeicherbereich“ einer Db2 CR-Definition, die einen vorhandenen Anspruch verwendet.
```
spec:
storage:
- claimName: c-<DB2_CR_PRIMARY>-archivelogs
name: archivelogs
spec:
resources: {}
type: existing
```
Wiederholen Sie die Schritte 6 bis 8, um den Speicherpfad für das Archivprotokoll zu aktualisieren.
Wiederholen Sie die Schritte 9-10 für den Hilfs-Standby Db2uCluster oder Db2uInstance, gekennzeichnet mit ${DB2_CR_AUX}.

Starten Sie HADR als Standby auf den Haupt- und Db2 Hilfs-Standby-Engine-Pods neu:

oc exec -it c-${DB2_CR_AUX}-db2u-0 -- manage_hadr -start_as standby
oc exec -it c-${DB2_CR_STANDBY}-db2u-0 -- manage_hadr -start_as standby

HADR auf dem primären Db2 Engine-Pod neu starten:

oc exec -it c-${DB2_CR_PRIMARY}-db2u-0 -- manage_hadr -start_as primary

Überprüfen Sie, ob die Protokolle zwischen Primär- und Standby-System synchronisiert sind, indem Sie den manage_hadr -status Befehl verwenden und die *_LOG_FILE,PAGE,POS Werte beobachten. Diese Protokolle sollten synchronisiert sein, wenn die Standby-Systeme aufgeholt haben. Schauen Sie sich das folgende Beispiel an:
```
PRIMARY_LOG_FILE,PAGE,POS = S0000016.LOG, 0, 411676046
STANDBY_LOG_FILE,PAGE,POS = S0000016.LOG, 0, 411676046
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000016.LOG, 0, 411676046
```
Wenn die Standbys nicht synchronisiert sind, überprüfen Sie die Db2diaglogs auf Fehler bezüglich fehlender Archivprotokolle. Kopieren Sie die fehlenden Archivprotokolle vom alten Speicherpfad /mnt/bludata0/db2/archive_log in den neuen Speicherpfad /mnt/logs/archive/. Diese Protokolle existieren möglicherweise nur im aktuellen Primärsystem, aber wenn bereits Übernahmen stattgefunden haben, wurden sie möglicherweise auch separat auf einem Standby-System archiviert.

Das folgende Beispiel zeigt einen Befehl zum Kopieren der Archivprotokolle vom alten in einen neuen Pfad innerhalb des Db2 Engine-Pods:
```
cp -r /mnt/bludata0/db2/archive_log/db2inst1/BLUDB/NODE0000/LOGSTREAM0000/C0000001 /mnt/logs/archive/db2inst1/BLUDB/NODE0000/LOGSTREAM0000
```