• В этой статье объясняется, как «replication resync» определяет, какие данные отправлять по сети. Порядок действий по выполнению повторной синхронизации см. в статье: Data Domain. Как прервать и повторно синхронизировать репликацию каталога.

ЗАТРОНУТЫЕ РЕШЕНИЯ

• Все модели Data Domain (DD)
• Репликация каталогов
• Все версии программного обеспечения 4.3 и выше

РЕШЕНИЕ

Повторная синхронизация практически идентична инициализации и даже может быть указана вместо инициализации для контекстов репликации каталогов со следующими отличиями:

Каталог реплики *не* должен быть пустым. На внутреннем уровне система назначения перемещает существующие файлы в сторону.

(В версиях 4.3–4.5 включительно это можно сделать, переименовав эти файлы в $destdir/.ddrsaved/ directory. В версии 4.6+ это делается путем создания снимка, а затем удаления файлов из контекста репликации $destdir.)

Для каждого файла в исходном каталоге он проверяет, существует ли такой же относительный путь в целевом каталоге (проверяя $destdir/.ddrsavedили моментальный снимок). 

Если файл существует, проверяется, идентичен ли целевой файл исходному файлу. 

Если файл идентичен, существующий файл реплики жестко связывается на месте без дополнительной фильтрации или отправки его содержимого.

Проверка подлинности файла выполняется в постоянном времени.

Проверка выполняется успешно, если файл реплики был создан с параметром directory replication >= 4.3.

Это означает, что заполнение можно выполнить, запустив репликацию коллекции (удобно, если Data Domain находятся в локальной сети), затем прервав репликацию коллекции, а затем выполнив повторную синхронизацию репликации каталогов.

Если файл реплики не найден или содержимое не совпадает, файл реплицируется обычным образом, то есть фильтруется по сегментам.

Весь смысл повторной синхронизации заключается в том, чтобы по возможности избегать такой фильтрации.

Потенциальная ошибка заключается в том, что действия человека или логика приложения, которые переименовывают файлы, могут привести к перемещению или переименованию исходных файлов или файлов реплик после нарушения репликации перед повторной синхронизацией.

Это приводит к тому, что при поиске имени пути при повторной синхронизации не обнаруживается совпадение и требуется полная фильтрация каждого файла.

Так как сегменты существуют в целевой системе, достигается высокая степень сжатия репликации, но упускается возможность избежать отправки ссылок на сегменты и их фильтрации.

• В версии 4.5 повторная синхронизация завершается сбоем, если для реплики включена или когда-либо была включена блокировка хранения.
• В версии 4.6 и выше имеются дополнительные требования, связанные с заблокированными файлами в реплике. По сути, любой заблокированный файл в целевой системе также должен существовать и иметь соответствующее содержимое и атрибуты в источнике. Это необходимо для того, чтобы предотвратить попытки репликации удалить заблокированные файлы из реплики.

• Data Domain. Контекст репликации отключен из-за потенциальной потери NVRAM
• Data Domain. Как прервать и повторно синхронизировать репликацию каталогов