Более эффективный способ синхронизировать очень большой # файлов

В дополнение к установке Времени SNTP/Windows также необходимо отключить синхронизацию времени под услугами по интеграции. Если Вы не сделаете, то у Вас будут конфликты относительно того, что устанавливает время, Хост Hyper-V или сервис Windows Time.

Вот статья, описывающая процесс. Вы могли бы также хотеть смотреть на статью The Domain Controller Dilemma Ben Armstrong. Один из комментариев конкретно упоминает DC при синхронизации времени и Hyper-V.

3
задан 15 March 2011 в 21:04
3 ответа

Взгляните на Deltacopy или Syncrify, которые являются оба на основе rsync протокола. Они только передадут файлы, которые изменились или являются новыми и т.д. Что еще более важно, они только передадут измененные блоки из больших файлов. Rsync будет, вероятно, уже установлен на Вашей машине Centos

5
ответ дан 3 December 2019 в 05:17

Унисон является другой возможностью. Важная часть получает что-то, что можно работать на сервере через SSH и позволить серверной стороне обработать, обрабатывают диск ввод-вывод в том конце вместо того, чтобы обойти всю файловую систему удаленно. Унисон может быть выполнен через ssh и использует rsync алгоритм, чтобы только передать измененные части файлов.

1
ответ дан 3 December 2019 в 05:17

Если изменения происходят локально только (т.е. односторонняя синхронизация), Вы могли бы думать о просто использовании archiver (zip, tar, и т.д.) архивировать измененные файлы для транспорта до удаленного сервера. По-видимому, можно использовать дату модификации, архивный бит, или, худший случай, поддержать вторую локальную копию для использования в качестве основания для определения, которое изменили файлы.

Rsync и другие программы копии дельты хороши, но я подозреваю, что Ваша проблема может быть достаточно проста решить w/o, идущий в то экстремальное значение. С большим количеством маленьких файлов Вы также испытаете много задержек с помощью rsync из-за задержки.

Так как Ваш источник является машиной Windows, Вы могли использовать бит "Архива" в качестве болтуна, для которого были изменены файлы (предположение, что процесс обновления переключает архивный бит). Вы могли сделать что-то простое как:

@echo off
set SRC=C:\source
set STAGING=C:\staging

rem Copy all files from source to staging, including subdirectories,
rem where "Archive" bit is set.
xcopy "%SRC%\*" "%STAGING%\" /e /s /a

rem Untick archive bit on all files in source
attrib /S /D -A "%SRC%\*"

Это оставило бы каталог "подготовки" заполненным только файлами, которые изменились (хотя с пустыми подкаталогами для каждого каталога, где файлы не изменились, также). Это также сбросило бы архивный бит на всех файлах во всех подпапках. Вы могли ZIP, что подготовка каталога (использующий Вашу любимую командную строку программа ZIP) и посылает его к удаленному серверу для распаковки.

Это не дает Вам сжатия дельты, но в среднем размере 51 КБ / файл оно кажется, что сжатие дельты не поможет Вам слишком много, и задержка "победа" этого упрощенного метода может быть лучше для Вас.

1
ответ дан 3 December 2019 в 05:17

Теги

Похожие вопросы