Data Domain : La réplication de structure MTREE affiche un Bytes_remaining incorrect lors de l’initialisation

MTREE Replication affiche des octets incorrects lors du processus d’initialisation pour les anciennes structures MTree qui n’ont jamais été utilisées lors de la réplication.

The following MTREE has been used [# mtree list]:
/data/col1/support           5965.4   RW

Les statistiques indiquent 92 To de données restantes après la création d’une nouvelle réplication MTREE en suivant les étapes ci-dessus :

# replication show detailed-stats rctx://1

CTX:1
Destination:                               
mtree://dd-dr.support.com/data/col1/support
Network bytes sent to destination:          2,287,577,928
Pre-compressed bytes written to source:     92,046,090,413,266
Pre-compressed bytes sent to destination:   2,860,770,559
Bytes after synthetic optimization:         2,860,770,559
Bytes after filtering by destination:       2,253,845,068
Bytes after low bandwidth optimization:     2,253,845,068
Bytes after local compression:              2,258,791,288
Pre-compressed bytes remaining:             92,043,229,642,707   <----
Compression ratio:                          1.3
Sync'ed-as-of time:                         (initializing)

Alors que les clés de registre sous-jacentes affichent des octets plus précis :

repl.001.src_host = dd-prod.support.com
repl.001.src_path = /data/col1/support
repl.001.dst_host = dd-dr.support.com
repl.001.dst_path = /data/col1/support
repl.001.progress.task_name = initializing 3/3
repl.001.progress.init_vbytes = 5991145719813   <---

De ddfs.info:
L’estimation initiale des octets virtuels semble correcte :

09/21 10:58:45.157 (tid 0x2b0e208796e0): repl ctx 1: mrepl_create_init_snap creating initial snapshot.
09/21 10:58:48.068 (tid 0x2b0e208796e0): repl ctx 1: estimating init vbytes as 5991145719813
09/21 10:58:48.995 (tid 0x2b0e208796e0): repl ctx 1: Using init_resync_snapid 1433317767:1886. Total snap count = 2, curent snap cnt = 0.

Au bout de quelques minutes, le cours normal des mrepl_sends Commence à apparaître :

09/21 11:19:04.136 (tid 0x327e760): repl ctx 1:3: mrepl_send_file: file 30:0:ac66:0:a30e9f46:556eb187:1d74 took 218 sec, net throughput 297 KB/s, virtual throughput 290 KB/s, refs_sent 7575, refs_features_sent 0, segs_sent 0, segs_features_sent 7575, size 63416832, vbytes 63416832, nbytes 64858812 (recid 361) (ch-xor 0x98f3c7e9) (hole_seen FALSE)
09/21 11:19:59.031 (tid 0x2b0e2083cde0): repl ctx 1:16: mrepl_send_file: file 30:0:ac68:0:fccc10a6:556eb187:1d74 took 237 sec, net throughput 286 KB/s, virtual throughput 280 KB/s, refs_sent 7908, refs_features_sent 0, segs_sent 0, segs_features_sent 7908, size 66419200, vbytes 66419200, nbytes 67938672 (recid 363) (ch-xor 0x462a1211) (hole_seen FALSE)

La prochaine occurrence de vbytes_remain Affiche une taille différente :

09/21 11:28:02.246 (tid 0x2b0e096ba050): repl ctx 1: mrepl_stats_local: vbytes_remain: 92036838018199

C’est ainsi que la réplication est conçue pour calculer les octets logiques restants. Cette incompatibilité est observée chaque fois que l’utilisateur commence à répliquer des structures MTree plus anciennes. Toutefois, cela n’indique pas que la réplication de MTREE réplique ces données, elle réplique uniquement la taille actuelle de la structure MTREE, comme indiqué par init_vbytes_remain. 

Une fois la phase d’initialisation terminée, réinitialisez vbytes_remain à 0 et également mettre à jour vbytes_written_and_replicated avec l' cum_raw_bytes Ainsi, les sauvegardes suivantes n’affichent pas de statistiques irréalistes, mais signalent uniquement les nouvelles données ingérées.