Récupérer un miroir après un crash

Nous revoilà avec un article lié au Mirroring !

Dans l'article précédent, nous avons vu comment configurer un Miroir entre deux instances IRIS, l'une agissant comme un nœud actif et l'autre comme un nœud passif. Ce système de mise en miroir fonctionne sur le transfert d'un fichier journal qui maintient à jour en permanence l'instance qui fonctionne comme un nœud passif, mais que se passe-t-il si, en raison d'un échec de communication ou d'autorisations du fichier journal, celui-ci n'est pas transféré correctement ?

Le plus courant est que dans cette situation notre Mirror reste non configuré, de telle sorte que le nœud passif ne reçoit pas les modifications apportées au nœud actif :

Dans l'image précédente, nous voyons un miroir configuré avec deux nœuds en mode basculement (mirrorA comme nœud actif et mirrorB comme nœud passif), mais dans ce cas, celui défini comme nœud passif (mirrorB) a perdu la connexion avec le nœud actif ou principal. et a donc cessé de recevoir des données de sa part. des bases de données incluses dans le Miroir (COMPANY, CUSTOMER and PERSONAL). Dans cette situation, la meilleure chose à faire est de supprimer les données que nous avons dans notre nœud passif et de restaurer à nouveau les bases de données du nœud actif vers le nœud passif, à cette URL vous pouvez trouver la documentation relative à la restauration. Pour cet exemple, nous allons opter pour l'option définie dans la documentation comme Sauvegarde en ligne qui utilisera les fonctionnalités de sauvegarde et de restauration incluses dans IRIS.

Très bien, commençons alors :

Configuration du nœud passif

Dans un premier temps, nous devons laisser le nœud passif déconfiguré dans un état permettant la restauration de la sauvegarde sur les bases de données miroir.

Démontage des bases de données miroir

Afin de fonctionner correctement avec les bases de données concernées, nous devons d'abord les démonter et pour cela nous accéderons à l'option directement depuis le portail de gestion : System Operation --> Databases

Passons au démontage des bases de données concernées COMPANY, CUSTOMER and PERSONAL en cliquant sur le nom de chacun d'eux et en appuyant sur le bouton Démonter qui apparaît dans la nouvelle fenêtre:

Une fois les 3 bases de données concernées démontées, nous pouvons désormais opérer dessus et restaurer les bases de données depuis le nœud actif (mirrorA).

Configuration du nœud actif ou principal

Comme nous l'avons indiqué précédemment, nous avons opté pour la sauvegarde en ligne comme la meilleure option de récupération et pour cela nous devons effectuer une sauvegarde des bases de données configurées dans le miroir. Avant de générer notre sauvegarde, nous allons définir la liste de bases de données sur laquelle nous voulons travailler.

Définition de la liste des bases de données

Notre idée est d'effectuer une sauvegarde complète des bases de données configurées dans le miroir et pour cela nous allons créer la liste des bases de données à sauvegarder dans notre fichier de sauvegarde et nous allons le faire depuis l'option du portail de gestion System Administration --> Configuration --> Database Backup --> Database Backup List

À partir de cette option de menu, nous pouvons définir notre liste :

Une fois les bases de données que nous avons configurées dans notre miroir sélectionnées, nous pouvons procéder à leur sauvegarde.

Exécuter la sauvegarde complète

Nous accéderons depuis le portail de gestion à l'option System Operation --> Backup --> Full Backup List et nous définirons le chemin de notre serveur (mirrorA) où nous voulons stocker le fichier de sauvegarde, dans ce cas, car nous avons défini un dossier accessible depuis Visual Studio Code (/shared) nous l'utiliserons pour stocker la sauvegarde et pouvoir la copier facilement sur l'autre nœud (mirrorB):

Comme vous pouvez le voir en sélectionnant l'option Liste de sauvegarde complète, nous avons automatiquement chargé la liste de bases de données précédemment sélectionnée. Eh bien, il suffirait d’appuyer sur Ok pour lancer la génération du fichier de sauvegarde complet. En fonction de la taille des bases de données, cela peut prendre plus ou moins de temps, mais nous pouvons vérifier à tout moment l'état de la sauvegarde depuis l'écran : Backup Status :

Voyons brièvement le journal qui a été généré :

Comme vous pouvez le constater, il indique les bases de données sur lesquelles la sauvegarde va être effectuée et détail important, le fichier journal a changé. Qu'est-ce que cela signifie? Cela signifie que lorsque nous restaurons la sauvegarde sur notre nœud passif (mirrorB) lorsque le journal actif sera synchronisé, nous aurons toutes les modifications apportées depuis la création des sauvegardes entièrement disponibles et, par conséquent, nous n'aurons pas besoin de copier le fichier journal sur notre nœud passif.

Pour ceux d'entre vous qui se demandent ce qu'est exactement le journal, ce n'est rien de plus qu'un fichier dans lequel nous enregistrons les opérations d'écriture (mise à jour ou suppression d'enregistrements) de notre base de données.

Très bien, notre sauvegarde est terminée, vérifions notre chemin /shared/Backup sur notre node actif (mirrorA):

Il y a notre fichier FullDBList_20230522_003.cbk avec la sauvegarde complète de votre base de données dans notre nœud actif (mirrorA). Copions-le sur le serveur de notre nœud passif (mirrorB), rappelez-vous que nous utilisons des instances Docker pour cet exemple, nous utiliserons donc directement le chemin accessible depuis notre projet Visual Studio Code, au cas où les instances IRIS s'exécuteraient sur des serveurs normaux, vous pouvez déplacer les fichiers comme vous le faites habituellement.

Une fois copié, vérifions qu'il est correctement localisé sur le serveur de notre nœud passif (mirrorB):

Parfait! Là, notre nœud passif (mirrorB) attend sa restauration, ne le faisons pas attendre.

Restauration du nœud passif (mirrorB)

Nous avons déjà notre sauvegarde dans notre nœud passif (mirrorB), alors ouvrons un terminal :

iris terminal IRIS

Suivons maintenant les étapes indiquées par le documentation

Voyons chaque étape en détail :

1. zn "%SYS": Changement du namespace par défaut USER to %SYS
2. do ^DBREST: Lancement de la commande de restauration
3. Restore: 2. Selected and/or renamed directories: nous sélectionnons cette option simplement pour afficher tous les répertoires/bases de données que nous allons restaurer.
4. Device: /shared/Backup/FullDBList_20230522_003.cbk:  nous introduisons le nom du fichier de sauvegarde que nous avons copié sur notre nœud passif (mirrorB).

Nous confirmons que c'est le fichier que nous souhaitons restaurer :

Une fois confirmé, nous serons informés des éléments suivants :

Il a été détecté que l'export a été effectué dans l'autre membre du miroir et nous demande si nous souhaitons restaurer uniquement les bases de données configurées dans le miroir. Puisque dans notre export nous n'avons inclus que ces bases de données, peu importe ce que nous répondrons, il faudra les mêmes. Réglons-le sur YES.

Pour chaque base de données de sauvegarde, nous pourrons modifier le répertoire de destination, ce qui ne nous intéresse pas, nous appuyerons donc simplement sur Entrée.

Enfin, il nous demandera de confirmer si l'on souhaite modifier la liste des répertoires précédemment sélectionnés et enfin il faudra écrire YES pour confirmer la restauration.

Comme vous pouvez le voir, la restauration des bases de données sera effectuée et enfin elle nous montrera la possibilité de continuer avec plus de fichiers de restauration, puisque nous n'en avons plus nous pourrions écrire STOP directement, si nous appuyons sur entrée il nous sera demandé si nous avons plus de sauvegardes à restaurer, dans ce cas nous répondrons NO.

Comme vous pouvez le constater, à la fin de la restauration les bases de données sont automatiquement montées.

Vérification du miroir après la restauration

Si nous accédons à nouveau au moniteur miroir, nous pouvons voir son état après la restauration :

Comme on peut le voir, le nœud passif (mirrorB) a récupéré de l'état d'échec dans lequel il se trouvait lors de la restauration et a commencé à recevoir le fichier journal du nœud actif (mirrorA) et qui a été créé après avoir effectué la sauvegarde.

Et voila, notre Mirror est à nouveau pleinement opérationnel !