Avamar : Échec du nettoyage de la mémoire avec MSG_ERR_TRYAGAINLATER

La tâche de maintenance du nettoyage de la mémoire Avamar se termine avec l’erreur suivante MSG_ERR_TRYAGAINLATER.

Pour vérifier le problème :

1. status.dpn Montre:

admin@avamarhost:~/>: status.dpn
...
Last GC: finished Mon Dec 23 06:08:00 2013 after 03m 05s >> recovered 0.00 KB (MSG_ERR_TRYAGAINLATER)

2. Vérifiez à l’aide de dumpmaintlogs WMIC suivante :

admin@avamarhost:~/>: dumpmaintlogs --types=gc --days=1
...
2013/12/23-12:08:00.9673 {0.0} <4202> failed garbage collection with error MSG_ERR_TRYAGAINLATER

3. Si vous le souhaitez, vous pouvez le vérifier dans les journaux d’Avamar Server par le support Avamar.

Ce comportement est normal et se produit lorsque de nouvelles données sont ajoutées à Avamar à partir des sauvegardes.

Lorsque les conteneurs de stockage ou « bandes » sur Avamar sont divisés en deux, on parle de « fractionnement de bande d’index ».

Cela se produit rarement, rarement et seulement après l’atteinte de certains intervalles de capacité en fonction de la taille du nœud, du nombre, de la version, etc. Cette tâche de maintenance ne peut pas être exécutée durant le GC.

Si une bande d’index est divisée lorsque certaines opérations du GC sont tentées, le GC se ferme avec MSG_ERR_TRYAGAINLATER.

Si une bande d’index exécute le GC et qu’elle doit être fractionnée, elle attend que les opérations du GC soient terminées.

Les bandes d’index sur une grille ont tendance à se diviser à peu près à la même période de temps les unes par rapport aux autres sur les différents nœuds. Parfois, cela peut prendre quelques jours.

Avamar fonctionne normalement.
Une fois le fractionnement de bande d’index terminé, le nettoyage de la mémoire reprend.

La solution de contournement consiste à ne pas exécuter de sauvegardes pendant le GC.

• Ce comportement ne se produit pas sur une grille qui est dans un « état stable » (dont l’utilisation de la capacité est stable ou décroissante), car toutes les bandes qui doivent exister existent déjà.
• Ce comportement ne se produit pas sur une grille qui est devenue saturée et dont la capacité a depuis été réduite (sans avoir été étendue avec de nouveaux nœuds). En effet, toutes les bandes qui peuvent être créées sur une grille existent déjà.
• Ce comportement peut se produire après l’ajout d’un nœud et après l’existence d’une capacité supplémentaire pour fractionner davantage les bandes.
• Ce problème peut se reproduire de temps à autre et est plus susceptible de se produire sur les grilles Avamar qui connaissent une croissance soutenue des données ou qui ont récemment été étendues avec des nœuds supplémentaires.
• Ce comportement peut persister pendant plusieurs jours.