Вопросы Теги

Синхронизация очень больших структур папок

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

$ ssh other-host sudo /path/to/deployment.script

В противном случае затем у Вас может быть sudo, берут его вход из файла:

$ ssh other-host 'sudo -S /path/to/deployment.script < password.file'

Но, не делайте этого, поскольку это означает помещение пароля в файл. И администратор сервера должен ударить Вашу задницу для этого.

Более оптимальному варианту, чем все вышеупомянутое состоял в том, чтобы настроить администратора сервера запись в authorized_keys файле корня, которому только позволяют запустить скрипт развертывания. Таким образом, для запущения скрипта Вам только нужно к ssh в сервер как корень со специальным ключом.

14
задан 24 February 2010 в 00:58
5 ответов

Если можно доверять файловой системе измененные в последний раз метки времени, можно убыстриться, вещи путем объединения Rsync с UNIX/Linux 'находят' утилиту. 'находка' может собрать список всех файлов, которые показывают измененные в последний раз времена в течение прошедшего дня и затем передают по каналу ТОЛЬКО, который сократил список файлов/каталогов к Rsync. Это намного быстрее, чем наличие Rsync сравнивает метаданные каждого файла на отправителе против удаленного сервера.

Короче говоря, следующая команда выполнит Rsync ТОЛЬКО в списке файлов и каталогах, которые изменились за прошлые 24 часа: (Rsync НЕ потрудится проверять любые другие файлы/каталоги.)

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

В случае, если Вы не знакомы с командой 'находки', она рекурсивно вызывает через определенное поддерево каталога, ища файлы и/или каталоги, которые соответствуют любым критериям, которые Вы указываете. Например, эта команда:

find . -name '\.svn' -type d -ctime -0 -print

запустится в текущем каталоге (". "), и рекурсивно вызывают через все подкаталоги, ища:

  • любые каталоги (" - тип d"),
  • названный ".svn" (" - называют '.svn'"),
  • с метаданными, измененными за прошлые 24 часа ("-ctime-0").

Это печатает имя полного пути (" - печать") чего-либо соответствующего тем критериям на стандартном выводе. '-Имя опций', '-тип' и '-ctime 'называют "тестами" и '-печатью опции', называют "действием". Страница справочника для 'находки' имеет полный список тестов и действий.

Если Вы хотите быть действительно умными, можно использовать тест ''-cnewer команды 'находки' вместо '-ctime, 'для создания этого процесса более отказоустойчивым и гибким. '-cnewer' тестирует, изменили ли каждому файлу/каталогу в дереве его метаданные позже, чем некоторый ссылочный файл. Используйте 'касание' для создания ссылочного файла Следующего запуска в начале каждого выполнения, прямо прежде чем 'найдут... | rsync...' команда, выполняется. Вот базовое внедрение:

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

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

9
ответ дан 2 December 2019 в 21:06
  • 1
    Это - чрезвычайно умное решение! I' m размышление Вас значат для touch $next_ref_file в конце? Это действительно оставляет нас без способности справиться с удаленными путями, хотя (даже эти статические архивные отчеты в конечном счете становятся достаточно взрослыми, что они заархивированы и удалены). Это не могло бы быть выставочным стопором все же. –  MightyE 24 February 2010 в 17:15
  • 2
    Я нахожу, хотя это даже всего find . -ctime 0 довольно медленно на этой структуре каталогов (все еще ожидающий на нем для завершения для создания отчетов о ее времени). Это на самом деле приводит в уныние меня немного, потому что кажется, что это могло бы быть довольно низкоуровневой операцией, которая, вероятно, устанавливает панель для самого быстрого, которое мы могли ожидать, что это задание завершит. Может иметь место, что диск ввод-вывод является ограничивающим фактором здесь. –  MightyE 24 February 2010 в 17:22
  • 3
    Что касается этого scriptlet, да, я сделал ошибку. Я имел в виду выполненный ' touch' на ' next_ref_file' (НЕ ' curr_ref_file') прямо прежде, чем выполнить ' найдите... | rsync...' команда. (I' ll исправляют мой ответ.) –  Ryan B. Lynch 24 February 2010 в 20:01
  • 4
    Что касается медленного ' find' команда: Какую файловую систему Вы используете? Если you' ре с помощью Ext3, Вы могли бы хотеть рассмотреть две тонких настройки FS: 1) Выполненный ' tune2fs-O dir_index < DEVICE_NODE> ' включить Ext3' s ' dir_index' функция, для ускорения доступа к директорам с большими количествами файла. 2) Выполненный ' смонтируйте, что-o повторно монтируются, noatime, nodiratime' выключить обновления времени доступа, который ускоряет чтение, обычно. ' dumpe2fs-h < DEVICE_NODE> | grep dir_index' говорит Вам если ' dir_index' уже включен (на некоторых дистрибутивах, it' s значение по умолчанию), и ' смонтируйтесь | grep < DEVICE_NODE> ' говорит Вам об обновлениях времени доступа. –  Ryan B. Lynch 24 February 2010 в 20:17
  • 5
    Печально it' s NTFS - использование Windows 2003 Server Cygwin для команды находки. Я буду помнить тех, которые настраивают опции (превосходный совет) для ext3 в случае, если мы когда-либо сталкиваемся с чем-то подобным на одном из наших кластеров Debian. –  MightyE 26 February 2010 в 01:20

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

7
ответ дан 2 December 2019 в 21:06
  • 1
    I' m предоставление Унисона попытки. It' s выполнение в течение приблизительно 2 часов теперь на " Поиск changes" этап, и на основе файлов it' s в настоящее время продолжающий работать, это похоже на it' s приблизительно половина сделанного пути (поэтому, возможно, общее количество 4 часов, прежде чем передача запускается). It' s сходство с ним будет лучше, чем rsync, но все еще за пределами нашего желаемого операционного окна. –  MightyE 24 February 2010 в 16:20
  • 2
    В первый раз, когда Вы создаете индекс с обеих сторон, восстановить времена подобны rsync, поскольку он должен хешировать каждый файл. После того как это сделано, унисон использует прошлый измененный раз каталога для идентификации, когда файл изменился и только должен просканировать тот файл для изменений. –  Dave Cheney 24 February 2010 в 16:31
  • 3
    Печально я была жертвой фанатичного Операционного администратора, который законченный силой моя сессия перед каталогом была сделана, будучи созданным (мы ограничиваем количество одновременных входов в систему рабочих серверов). Я потерял успехи, которые это сделало при создании первоначального каталога, таким образом, я должен запустить снова. I' ll сообщают, как это идет. –  MightyE 24 February 2010 в 19:41
  • 4
    Требуется приблизительно 2 часа теперь, когда первоначальный каталог создается для сканирования для изменений. I' m довольно удивленный, сколько Унисон RAM использует для этого. Для нашего набора файла исходный сервер использует 635M, и удаленный клиент использует 366M. Синхронизировать несколько машин в кластере было бы довольно значительным местом, особенно для исходного сервера! –  MightyE 26 February 2010 в 01:15
  • 5
    Могут Вы для структурирования данных способом, которые помогают определить данные измененного недавно? Т.е., храня его в year/month/day/... формат? –  Dave Cheney 26 February 2010 в 04:19

http://oss.linbit.com/csync2/ разработан для этого вида вещи, я дал бы этому попытку.

3
ответ дан 2 December 2019 в 21:06

Если Вы используете-z, включают rsync, пытаются работать без него. По некоторым причинам я видел, что это ускоряет даже начальное перечисление файлов.

2
ответ дан 2 December 2019 в 21:06
  • 1
    Мы попробовали и без флага-z. Это, казалось, не оказало влияние на " создание файла list" продолжительность выполнения. –  MightyE 24 February 2010 в 16:22

Удаление -z из команды rsync, которая не является сжатием, привело к тому, что "список принимаемых файлов" стал работать намного быстрее, и нам пришлось передать около 500 ГБ. Раньше с ключом -z требовался день.

2
ответ дан 2 December 2019 в 21:06

Теги

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