Redémarrage Db2 Warehouse de HADR sur les bases de données principales ou secondaires principales après basculement vers une base de données secondaire auxiliaire

Lorsque Governor s'exécute sur les bases de données principale et de secours principale désignées, HADR est automatiquement redémarré après une reprise en ligne sur une autre base de données. Mais dans un scénario où la base de données devient inopinément indisponible (par exemple, en cas de panne du site), les flux de journaux de l'ancienne et de la nouvelle base de données primaire peuvent diverger, ce qui empêche le démarrage de HADR.

A propos de cette tâche

Ce message s'affiche dans le diaglog (situé dans le pod Db2u dans ${DIAGPATH}/NODE000) :

MESSAGE : ADM12500E  The HADR standby database cannot be made consistent with
          the primary database. The log stream of the standby database is
          incompatible with that of the primary database. To use this database
          as a standby, it must be recreated from a backup image or split
          mirror of the primary database.

Si ce scénario se produit, effectuez une sauvegarde en ligne à partir de la base de données principale actuelle et restaurez-la dans la base de données de secours qui ne parvient pas à démarrer. Vous pouvez effectuer une sauvegarde manuelle à partir de la base de données principale actuelle et réexécuter le setup_config_hadr script avec --db-role standby.

Procédure

Arrêtez HADR sur la base de données qui ne peut pas se réintégrer :
```
oc exec -it c-db2-primary-db2u-0 -- manage_hadr -stop
```

Déterminez la base de données qui est actuellement la base principale à l'aide de manage_hadr l'outil avec -status l'option.

oc exec -it c-db2wh-aux-db2u-0 -- manage_hadr -status

Dans la sortie, db2wh-aux est la base de données principale actuelle après une reprise forcée et HADR_ROLE = PRIMARY.


#######################################################################
###             Db2 Warehouse high availability and                 ###
###             disaster recovery (HADR) management                 ###
#######################################################################


Running HADR action -status on the database BLUDB ...
################################################################################
###                       The HADR status summary                            ###
################################################################################
Database Member 0 -- Database BLUDB -- Active -- Up 0 days 00:00:39 -- Date 2021-05-28-03.47.31.838856

####### Primary - Standby 1 ######
                            HADR_ROLE = PRIMARY

Exécutez dans le pod de la Db2 Warehouse base de données principale actuelle et passez au propriétaire de l'instance de base de données :
```
oc exec -it c-db2wh-aux-db2u-0
```
```
su - db2inst1
```
Lancer une sauvegarde en ligne de la base de données vers l'emplacement de sauvegarde (${BACKUPDIR} (/mnt/backup):
```
db2 backup db BLUDB online to ${BACKUPDIR}
```
Copiez le magasin de clés dans l'emplacement de sauvegarde :
```
tar -cjvf ${BACKUPDIR}/keystore.tar -C ${KEYSTORELOC} .
```
Mettez à jour les autorisations sur le répertoire de sauvegarde afin que le Db2 Warehouse propriétaire/groupe de l'instance dispose d'un accès en lecture/écriture :
```
sudo chmod 755 -R  /mnt/backup
```
Copiez le Db2 Warehouse fichier de sauvegarde de la base de données principale actuelle vers la base de données de secours dans un répertoire de l'hôte appelé /tmp/hadr.
```
oc rsync c-db2wh-aux-db2u-0:/mnt/backup/ /tmp/hadr
```
Exécutez à nouveau le setup_config_hadr script pour restaurer la base de données.
- Utilisez standby pour --db-role pour vous assurer que la base de données est reconfigurée comme base de données de secours.
- Si la base de données qui est réinitialisée est l'ancienne base de données primaire, utilisez la base de données de secours principale désignée comme primaire, et utilisez la base de données primaire désignée comme secondaire, en laissant les bases de données de secours auxiliaires comme auxiliaires :
```
oc exec -it c-db2wh-primary-db2u-0 -- setup_config_hadr --db-role standby --primary-name db2wh-standby --standby-name db2wh-primary --primary-port 31384 --standby-port 32457 --aux1-name db2wh-aux --aux1-port 32649 --etcd-host my-etcd-client.my-etcd --etcd-port 2379 –multicluster
```
- base de données qui est réinitialisée est l'ancienne base de données de secours principale, utilisez les mêmes paramètres que ceux utilisés dans la configuration originale :
```
oc exec -it c-db2wh-standby-db2u-0 -- setup_config_hadr --db-role standby --primary-name db2wh-primary --standby-name db2wh-standby --primary-port 32457 --standby-port 31384 --aux1-name db2wh-aux --aux1-port 32649 --etcd-host my-etcd-client.my-etcd --etcd-port 2379 --multicluster
```
Exécutez à nouveau le Db2 Warehouse pod. En tant que propriétaire Db2 Warehouse de l'instance, vérifiez la configuration HADR en définissant HADR_LOCAL_SVC.
```
db2 get db cfg for bludb | grep -i hadr_local_svc
```
```
# Output:
HADR local service name           (HADR_LOCAL_SVC) = 60007|31384
```
Vérifiez que le premier numéro de port est correct pour son rôle d'origine désigné :
- Base de données primaire : 60006
- Base de données de secours : 60007
- Base de données auxiliaire 1 : 60008
- Aux2 : 60009
S'il est incorrect, éditez la configuration HADR HADR_LOCAL_SVC pour qu'elle utilise le bon port. Mettez à jour uniquement le premier numéro de port et utilisez la valeur existante pour le deuxième numéro de port :
```
db2 “update db cfg for BLUDB using HADR_LOCAL_SVC 60006|31384”
```
Quittez le pod, et démarrez HADR sur la base de données en tant que base de données de secours :
```
oc exec -it c-db2wh-primary-db2u-0 -- manage_hadr -start_as standby
```