• Cet article explique comment la « resynchronisation de réplication » détermine les données à envoyer sur le réseau. Pour connaître la procédure à suivre pour effectuer une resynchronisation, reportez-vous à l’article : Data Domain : Comment briser et resynchroniser la réplication de répertoire.

S’APPLIQUE À

• Tous les modèles Data Domain (DD)
• Réplication de répertoire
• Toutes les versions logicielles 4.3 et ultérieures

SOLUTION

La resynchronisation est presque identique à l’initialisation, et peut même être spécifiée à la place de l’initialisation pour les contextes de réplication de répertoire , avec les différences suivantes :

Il n’est *pas* nécessaire que le répertoire de réplica soit vide. En interne, la destination déplace les fichiers existants.

(Dans les versions 4.3 à 4.5 incluses, cela consiste à renommer ces fichiers en un fichier $destdir/.ddrsaved/ directory. En 4.6+, c’est en faisant un snapshot puis en supprimant les fichiers du contexte de réplication $destdir.)

Pour chaque fichier du répertoire source, il vérifie si le même chemin relatif existe sur la destination (en vérifiant le $destdir/.ddrsavedou l’instantané). 

Si le fichier existe, il vérifie si le fichier de destination est identique au fichier source. 

S’il est identique, le fichier de réplica existant est lié en place sans qu’il soit nécessaire de filtrer ou d’envoyer son contenu.

La vérification d’identité du fichier se produit à temps constant.

La vérification réussit si le fichier de réplica a été créé par réplication >de répertoire = 4.3.

Cela implique que l’ensemencement peut être effectué en exécutant la réplication de collection (pratique si les Data Domain se trouvent dans un LAN), puis en interrompant la réplication de collection, puis en effectuant une resynchronisation de la réplication de répertoire.

Si un fichier de réplica est introuvable ou si le contenu ne correspond pas, le fichier est répliqué normalement, c’est-à-dire filtré segment par segment.

Tout l’intérêt de la resynchronisation est d’éviter ce filtrage dans la mesure du possible.

Un piège potentiel est que l’activité humaine ou la logique d’application qui renomme les fichiers peut entraîner le déplacement ou le renommage des fichiers de l’initiateur ou du réplica après l’interruption de la réplication, avant la resynchronisation.

En conséquence, la recherche de chemin d’accès lors de la resynchronisation ne trouve aucune correspondance et nécessite un filtrage complet de chaque fichier.

Étant donné que les segments existent sur la destination, une compression de réplication élevée est obtenue, mais une occasion est manquée d’éviter d’envoyer les références des segments et de les filtrer en premier lieu.

• Dans la version 4.5, la resynchronisation échoue si le réplica a, ou a déjà eu, verrouillé la conservation activé.
• Dans les versions 4.6 et ultérieures, il existe des exigences supplémentaires relatives aux fichiers verrouillés pour rétention sur le réplica. En substance, tout fichier verrouillé pour rétention sur la destination doit également exister et doit avoir un contenu et des attributs correspondants sur l’initiateur. Cela permet d’empêcher la réplication de tenter de supprimer les fichiers verrouillés pour rétention sur le réplica.

• Data Domain : Le contexte de réplication est désactivé en raison d’une perte potentielle de NVRAM
• Data Domain : Comment briser et resynchroniser la réplication de répertoire