Avamar : Lors du basculement R2r de plusieurs nœuds à un nœud unique, une erreur de décalage du lockbox se produit.
Summary: Lors d’une migration de racine à racine (r2r) à partir d’une migration à plusieurs nœuds vers un nœud unique, le fichier de lockbox ne parvient pas à se terminer à l’étape de restauration du lockbox. Cette erreur indique que le champ client-offset n’a pas pu être mis à jour sur un nœud spécifique tel que 0.1. ...
Symptoms
Le processus r2r est interrompu car le script du lockbox ne parvient pas à se terminer sans erreur. Le script demande la mise à jour du champ de décalage MCDB (Management Console Database). Après avoir appuyé sur « yes », le script génère des messages d’erreur de base de données et s’arrête.
Cause
Le script ajuste les variables de décalage client pour un système à plusieurs nœuds, mais la cible est un système à nœud unique, ce qui entraîne la non-correspondance. Et le multinode ne peut pas mettre à jour la variable de nœud associée pour le nœud en question. Par exemple, la valeur 0.1 n’existe pas sur la cible, de sorte que le script rencontre un paramètre non valide et s’arrête.
La clé se trouve à la ligne 1022 du script du lockbox. C’est ici que la demande de mise à jour du décalage du client MCS (Management Console Server) est lancée :
Use of uninitialized value $info{"NEW_VALUE"} in concatenation (.) or string at lockbox_restore.pl line 1022, <STDIN> line 5.
Resolution
Il s’agit du comportement prévu, car la cible du r2r est un serveur à nœud unique et aucune valeur n’est associée à un système à plusieurs nœuds. Le script ne peut pas terminer la mise à jour du champ de décalage des messages du client. Cela peut être ignoré, car il n’est pas strictement nécessaire de mettre à jour le décalage pour terminer le basculement r2r. Toutefois, étant donné que la MCDB doit être mise à jour de toute façon, il est toujours nécessaire d’entrer yes pour les mises à jour.