Avamar: Die automatische Speicherbereinigung schlägt fehl MSG_ERR_TRYAGAINLATER
Summary: Ab Version 7.x, wo Backups während der Garbage Collection zulässig sind, wird gelegentlich die Meldung "MSG_ERR_TRYAGAINLATER" angezeigt.
Symptoms
Der Wartungsjob für die Avamar Garbage Collection wird mit folgendem Fehler beendet: MSG_ERR_TRYAGAINLATER.
So überprüfen Sie das Problem:
-
status.dpnZeigt:
admin@avamarhost:~/>: status.dpn ... Last GC: finished Mon Dec 23 06:08:00 2013 after 03m 05s >> recovered 0.00 KB (MSG_ERR_TRYAGAINLATER)
-
Überprüfen Sie dies mithilfe der
dumpmaintlogsBefehls:
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
-
Optional kann dies vom Avamar-Support in den Avamar-Serverprotokollen überprüft werden.
Cause
Dies ist ein erwartetes Verhalten und tritt auf, wenn neue Daten aus Backups zu Avamar hinzugefügt werden.
Wenn Storage-Container oder "Stripes" auf Avamar in zwei Teile aufgeteilt werden, wird dies als "Index-Stripe-Splitting" bezeichnet.
Dies tritt in seltenen Fällen, selten und nur auf, nachdem bestimmte Kapazitätsintervalle je nach Node-Größe, Anzahl, Version usw. erreicht wurden. Diese Wartungsaufgabe kann nicht während GC durchgeführt werden.
Wenn ein Indexstreifen geteilt wird, wenn bestimmte GC-Vorgänge versucht werden, wird GC mit MSG_ERR_TRYAGAINLATER.
Wenn ein Index-Stripe GC ausführt und geteilt werden muss, wartet er, bis GC-Vorgänge abgeschlossen sind.
Indexstripes in einem Raster werden in der Regel etwa im gleichen Zeitraum wie die anderen auf den verschiedenen Nodes aufgeteilt. Manchmal kann dies einige Tage dauern.
Resolution
Avamar funktioniert wie vorgesehen.
Wenn die Index-Stripe-Aufteilung abgeschlossen ist, wird die automatische Speicherbereinigung fortgesetzt.
Der Workaround besteht darin, während der GC keine Backups auszuführen.
Additional Information
- Dieses Verhalten tritt nicht auf einem Grid auf, das sich im "Steady State" befindet (mit gleichbleibender oder abnehmender Kapazitätsauslastung), da alle Stripes, die vorhanden sein müssen, bereits vorhanden sind.
- Dieses Verhalten tritt nicht auf einem Grid auf, das voll geworden ist und seitdem seine Kapazität reduziert hat (ohne mit neuen Nodes erweitert worden zu sein). Dies liegt daran, dass alle Stripes, die auf einem Raster erstellt werden können, bereits vorhanden sind.
- Das Verhalten kann auftreten, nachdem ein Node hinzugefügt wurde und zusätzliche Kapazität vorhanden ist, um Stripes weiter aufzuteilen.
- Das Problem kann von Zeit zu Zeit auftreten und tritt eher bei Avamar-Rastern auf, die ein anhaltendes Datenwachstum verzeichnen oder kürzlich um zusätzliche Nodes erweitert wurden.
- Das Verhalten kann über mehrere Tage anhalten.