Échec de l’importation de la réplication mtree : échec de la contrainte sévère nsrmmdbd SQLITE

Le serveur est configuré avec la réplication de périphérique DD.
La version est 19.9.0.4 ou antérieure.
L’exportation fonctionne correctement.
Échec de l’importation.

Il existe 2 scénarios possibles dans lesquels ce problème peut se produire.
En raison d’un bogue dans la version 19.9.0.4 ou antérieure, la ressource « NSR DD device replication » peut être supprimée du serveur après un redémarrage des services. Cela peut conduire à deux situations :

1. Sur le serveur source, la ressource « NSR DD device replication » est supprimée. La référence de la « dernière heure de réplication » est perdue. L’opération d’exportation suivante n’exportera pas ces savesets après la dernière exportation, mais exportera simplement tous les savesets qui se trouvent dans le volume. Au moment de l’importation, la plupart de ces ssid auraient déjà été importés précédemment, d’où le message d’erreur suivant : La contrainte sévère SQLITE a échoué, car nous ne pouvons pas insérer un ssid deux fois.
2. Sur le serveur cible, la ressource « NSR DD device replication » est supprimée. La référence de la « dernière heure de réplication » est perdue. La prochaine opération d’importation n’importera pas de nouveaux savesets postérieurs à la dernière heure d’importation. Au lieu de cela, il essaiera d’importer tous les savesets. Mais beaucoup de ces savesets ont déjà été importés et échoueront donc.

Étant donné que l’échec provient de la suppression de la ressource « NSR DD device replication », le seul correctif consiste à effectuer une mise à niveau vers la version 19.9.0.5 ou 19.10 pour éviter que le problème ne se produise.

Solution de contournement possible :
Contournement A :
1. Déterminez quelle était l’heure de « dernière réplication » à partir des ressources « NSR DD device replication » disponibles dans le dossier nsr/nsrdb/dbg folder
2. Supprimez la « NSR DD device replication » existante et créez-en une nouvelle avec les mêmes paramètres, mais en utilisant la dernière heure de réplication ci-dessus.

Solution de contournement B :
si le contenu du dossier /nsr/replication dans le serveur cible n’a pas été modifié depuis le début de la réplication, vous pouvez supprimer l’intégralité du volume de réplication et exécuter à nouveau l’importation (uniquement si la dernière heure de réplication de périphérique NSR DD est 0).
Gardez à l’esprit que les savesets ne peuvent pas être supprimés par le serveur NetWorker cible, car ils se trouvent sur une structure mtree en lecture seule ; Par conséquent, la suppression du volume ne supprimera pas les savesets. De plus, comme le dossier /nsr/replication est intact, nous avons les informations de tous les savesets qui ont été importés depuis le démarrage de la tâche de réplication.

Solution de contournement C :
Si vous avez besoin de récupérer un SSID spécifique sur le serveur cible à des fins de restauration, vous pouvez exécuter le moteur d’analyse pour le SSID spécifié.
Étant donné que ce SSID a été importé avec « scanner » et non via une opération d’importation, toute opération d’importation ultérieure tentant d’importer ce SSID échouera. Vous pouvez simplement supprimer le saveset manuellement ultérieurement avec nsrmm -d -S ssid, une fois que vous avez terminé de le récupérer. Là encore, cette opération ne supprimera pas le SSID du système Data Domain, mais uniquement la référence dans la base de données des supports.

Si vous avez besoin d’aide supplémentaire ou si vous avez besoin de comprendre le problème, contactez le support.