Avamar v7 og nyere – Garbage Collection rapporterer "skipped-hashes", der ikke kan ryddes op på grund af "Hash-referencebitkort", når dataene er i brug

Funktionen Hash-reference til Bit Maps er en funktion, der introduceres med Avamar v7.x-funktionen, som gør det muligt at foretage sikkerhedskopieringer under vedligeholdelsesaktiviteten Garbage Collection (GC). 

Før denne funktion kunne Garbage Collection ikke køre samtidigt på grund af risikoen for datakonflikter. 

I Garbage Collection-fasen opretholder den nye funktion oplysninger i hukommelsen om data, som er tilføjet eller ændret (et "kort over hashes, der henvises til"). Garbage Collection kontrollerer disse oplysninger for at finde ud af, hvilke hashes (og de data, de henviser til) ikke må fjernes.  

Et krav ved denne funktion er, at disse "kort" skal bruge mindst 5 minutter med "lydsvag" tid, hvor der ikke foretages nogen sikkerhedskopieringer, for at de kan nulstilles. Når denne nulstilling finder sted, kan de data, der er låst i dem, scannes under den efterfølgende Garbage Collection-cyklus, så længe de fortsat er uændrede.

Denne støjsvag tid bør tages i betragtning, når du designer den daglige Avamar-tidsplan for sikkerhedskopiering og vedligeholdelse. 
En manglende evne for kortene til nulstilling kan forhindre, at Garbage Collection rydder op i udløbne data.
Hvis hash-kortet, der er henvist til, ikke giver mulighed for at nulstille, behandles data, som er berettiget til at blive fjernet efter affald, ikke, og kapacitetsforbruget kan øges. Hvis kortet ikke kan nulstilles over en længere periode, kan Garbage Collection-logfilen vise en stigende mængde "sprunget hashes".

Sikkerhedskopiering(er) er udløbet, men Garbage Collection gendannede ikke alle de data, der kunne slettes, fordi nogle af dataene var i brug på det pågældende tidspunkt.

For at kontrollere dette skal du køre kommandoen nedenfor:
Kommandoen dumper vedligeholdelsesloggen for Garbage Collection i 7 dage og parses den at vise.

• Hvor mange hashes blev sprunget over,
• Hvor mange data der blev slettet
• Hvor mange garbage collection-fejl har fundet sted
• Hvor lang garbage collection kørte for

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Analyse:

Outputtet viser antallet af sprunget hashes, der øges over tid, indtil hash-referenceoversigten nulstilles den 16. februar 2014.
Vi kan også se mængden af data renset op "megabytes-genoprettet", når hashes er frigjort, og Garbage Collection kan behandle dem for udløbne data.

Øjeblikkelig løsning

1. Sørg for, at kortene kan nulstilles, og lad garbage collection køre igen.
2. Sørg for, at der ikke er nogen kørende avtar-sessioner, der føjer data til systemet (sikkerhedskopiering eller indgående replikeringsdata). Brug GUI-aktivitetsovervågningen, og kontrollér, om der kun ses dvalesessioner med kommandoen "avmaint sessions --full".
3. Stop alle sikkerhedskopieringer og indgående replikeringssessioner.
4. Vent mindst fem minutter for at tillade, at hash-referencebitkortene er tid nok til at blive nulstillet.  
5. Når GC kører igen, skal du kontrollere GC-vedligeholdelsesloggen for at bekræfte, at skipped-hashes=0

Hvis sprunget hashes ikke er nulstillet til nul, skal du arbejde sammen med Support for at dobbelttjek ovenstående trin. Hvis Garbage Collection rapporterer MSG_ERR_TRYAGAINLATER, kan supporten bekræfte, om det skyldes en index stripe-opdelingsaktivitet. 
 

Langsigtet løsning

Design tidsplanerne for sikkerhedskopiering og vedligeholdelse, så der regelmæssigt er "inaktiv" til at nulstille den hash-bittilknytning, der henvises til.

Sikkerhedskopieringsplanerne bør med andre ord ikke køre 24/7. Opbyg en tidsplan, der giver et kort tidsrum, når der ikke skrives nogen sikkerhedskopier eller indgående replikeringsdata til systemet. 

Bemærk: 

• Det eneste tidspunkt, hvor hash-bittilknytningerne, der er henvist til, kontrollerer, om de kan nulstilles, er lige efter en avtar-session afsluttes. Hvis der ikke er nogen avtar-sessioner i gang, vil tilknytningen kun blive nulstillet, hvis:

• En af grundene til, at de hashes, der er sprunget over, kan være midlertidigt højt, skyldes opdeling af indeks-stripe. Dette sker, fordi hashes, der flyttes til det opdelte mål, er beskyttet. Opdelingen af indeksstriben sker på systemer, der stadig vokser eller er fyldt med data. 
• Garbage Collection kan også mislykkes med MSG_ERR_TRYAGAINLATER , når indeksstriber opdeles:  
• MCS er muligvis ikke nødvendigvis opmærksom på alle avtar-sessioner, der forekommer på Avamar Server.