Récupération d'un cluster après un endommagement de données critiques
Si l'un des serveurs de base de données d'un cluster à haute disponibilité rencontre un incident qui endommage l'espace dbspace racine, l'espace dbspace qui contient les fichiers de journaux logiques ou l'espace dbspace qui contient le journal physique, vous devez faire comme si les disques du serveur de base de données en panne ne contenaient aucune donnée et que vous les démarriez pour la première fois. Utilisez le serveur de base de données fonctionnel possédant les disques intacts comme serveur de base de données.
Échec du serveur principal
Pour les étapes suivantes, supposez que la configuration se compose d'un serveur principal nommé srv_A et d'un serveur secondaire HDR nommé srv_B. Les étapes de restauration d'un cluster RS sont similaires.
Afin de redémarrer le HDR après un échec de support critique :
- Le paramètre de configuration DRAUTO sur srv_B influencera vos actions
- S'il est défini sur 0, vous devez convertir le serveur en serveur principal à l'aide de la commande onmode -d make primary.
- S'il est défini sur 1, alors convertissez le serveur en serveur principal en exécutant la commande onmode -d make primary.
- S'il est défini sur 2, le serveur de base de données secondaire devient le serveur principal dès que la connexion se termine à l'échec de l'ancien serveur principal.
- Restaurez srv_A (le serveur principal) à partir de la dernière sauvegarde de l'espace dbspace.
- Utilisez la commande onmode -d pour définir srv_A comme serveur secondaire HDR et démarrez la HDR.
La commande onmode -d démarre la restauration logique à partir des fichiersde journaux logiques de srv_B. Si la restauration logique ne peut être effectuée, car vous avez sauvegardé et vidé les fichiers journaux logiques sur srv_B, la HDR ne démarre pas tant que l'étape suivante n'est pas réalisée.
- Appliquez les fichiers de journaux logiques à partir de srv_B (le nouveau serveur principal) qui a été sauvegardé sur bande. La paire HDR est à présent opérationnelle. Cependant les rôles de srv_A et srv_B sont interchangés. Pour que srv_A et srv_B reprennent leur rôle d'origine, suivez les instructions : Récupération d’un cluster HDR lorsque le serveur secondaire est devenu le serveur principal.
| Etape | Sur le serveur de base de données principal (srv_A) | Sur le serveur de base de données secondaire (srv_B) |
|---|---|---|
| 1. | onmodecommande onmode -d make primary srv_A |
|
| 2. | ontapecommande ontape -p Commande ON-Bar onbar -r -p |
|
| 3. | onmodecommande onmode -d secondary srv_B |
|
| 4. | ontapecommande ontape -l Commande ON-Bar onbar -r -l |
Echec du serveur secondaire
Si le serveur de base de données secondaire rencontre un incident de support critique, restaurez le cluster en suivant les étapes suivantes pour démarrer un cluster pour la première fois.
Echec des serveurs principal et secondaire
Dans le cas où les deux ordinateurs qui exécutent des serveurs de base de données dans une paire de réplication rencontrent un incident qui endommage l'espace dbspace racine, les espaces dbspace qui contiennent des fichiers de journaux logiques ou le journal physique, vous devez redémarrer le cluster.
- Restaurer le serveur principal à partir de la sauvegarde de l'espace de stockage et des journaux logiques.
- Après avoir restauré le serveur principal, traitez le second comme s'il ne possédait aucune donnée et que vous le démarriez pour le cluster à haute disponibilité pour la première fois.