• У цій статті пояснюється, як функція "повторна синхронізація реплікації" визначає, які дані надсилати мережею. Про те, як виконати повторну синхронізацію, дивіться в статті: Домен даних: Як зламати та повторно синхронізувати реплікацію каталогів.

ВІДНОСИТЬСЯ ДО

• Усі моделі домену даних (DD)
• Реплікація каталогу
• Усі випуски програмного забезпечення 4.3 і вище

РІШЕННЯ

Повторна синхронізація майже ідентична ініціалізації, і навіть може бути вказана замість ініціалізації для контекстів реплікації каталогів , з наступними відмінностями:

Каталог replica *не* зобов'язаний бути порожнім. Внутрішнє призначення переміщує наявні файли з дороги.

(У версіях від 4.3 до 4.5 включно це відбувається шляхом перейменування цих файлів на $destdir/.ddrsaved/ directory. У версії 4.6+ це відбувається шляхом створення знімка з подальшим видаленням файлів з контексту реплікації $destdir.)

Для кожного файлу в каталозі вихідного коду він перевіряє, чи існує той самий відносний шлях у місці призначення (перевіряючи $destdir/.ddrsavedабо знімок). 

Якщо файл існує, він перевіряє, чи файл призначення ідентичний вихідному файлу. 

Якщо він ідентичний, існуючий файл репліки жорстко зв'язується на місці без додаткової вимоги фільтрувати або надсилати будь-який його вміст.

Перевірка ідентичності файлу відбувається в постійному часі.

Перевірка виконана успішно, якщо файл репліки був створений шляхом реплікації >каталогу = 4.3.

Це означає, що роздача може бути досягнута шляхом запуску реплікації колекції (зручно, якщо домени даних знаходяться в локальній мережі), потім розриву реплікації колекції, а потім виконання повторної синхронізації реплікації каталогів.

Якщо репліка файлу не знайдена або вміст не збігається, файл реплікується у звичайному режимі, тобто фільтрується за сегментами.

Вся суть повторної синхронізації полягає в тому, щоб уникнути цієї фільтрації там, де це можливо.

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

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

Оскільки сегменти існують на місці призначення, досягається високе стиснення реплікації, але втрачається можливість уникнути надсилання посилань на сегменти та їх фільтрації в першу чергу.

• У версії 4.5 повторна синхронізація не виконується, якщо на репліці ввімкнено або коли-небудь було ввімкнено блокування збереження.
• У версії 4.6 і новіших версіях передбачено декілька додаткових вимог, пов'язаних із збереженням файлів на репліці. По суті, будь-який файл, заблокований на місці призначення, також повинен існувати та мати відповідний вміст і атрибути на авторі. Це зроблено для запобігання спробам реплікації видалити файли, заблоковані при збереженні, на репліці.

• Домен даних: Контекст реплікації вимкнено через потенційну втрату NVRAM
• Домен даних: Як зламати та повторно синхронізувати реплікацію каталогів