Синхронізація дуже великих структур папок

У нашій інтрамережі є структура папок, яка містить близько 800 000 файлів, які поділяються на близько 4000 папок. Нам потрібно синхронізувати це з невеликою групою машин у наших ДМЗ. Глибина споруди дуже мала (вона ніколи не перевищує двох рівнів глибини).

Більшість файлів ніколи не змінюються, кожен день з'являється кілька тисяч оновлених файлів і 1-2 тисячі нових файлів. Дані - це дані історичної звітності, які зберігаються там, де вихідні дані були очищені (тобто це доопрацьовані звіти, для яких вихідні дані є достатньо старими, щоб ми їх архівували та видаляли). Синхронізація один раз на день є достатньою, враховуючи, що це може відбуватися у розумні часові рамки. Звіти формуються протягом ночі, і ми спочатку синхронізуємо вранці як заплановане завдання.

Очевидно, оскільки так мало файлів змінюється регулярно, ми можемо отримати велику користь від поступової копії. Ми спробували Rsync, але це може зайняти від восьми до дванадцяти годин, щоб виконати операцію "створення списку файлів файлів". Зрозуміло, що ми швидко переростаємо, на що здатний rsync (12-годинний часовий проміжок є занадто довгим).

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

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

Якщо ви можете довірити останню зміну часових позначок файлової системи, ви можете прискорити роботу, поєднавши Rsync з утилітою UNIX / Linux 'find'. 'find' може зібрати список усіх файлів, які показують останні змінені часи протягом минулої доби, а потім передавати ТІЛЬКИ, що скорочує список файлів / каталогів до 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', вона повторюється через певне підкаталог каталогу, шукаючи файли та / або каталоги, які відповідають усім критеріям, які ви вказали. Наприклад, ця команда:

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

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

• будь-які каталоги ("-тип d"),
• з іменем ".svn" ("-ім'я '.svn'"),
• з метаданими, зміненими протягом останніх 24 годин ("-cime -0").

Він друкує повну назву шляху ("-принт") будь-чого, що відповідає цим критеріям на стандартному виході. Параметри '-name', '-type' та '-ctime' називаються "тестами", а параметр '-print' називається "дії". На головній сторінці "знайти" є повний перелік тестів та дій.

Якщо ви хочете бути по-справжньому розумними, ви можете використовувати тест команди 'find' '-cnewer' замість '-ctime', щоб зробити цей процес більш стійким до відмов і гнучким. '-cnewer' перевіряє, чи змінили кожен файл / каталог у дереві свої метадані нещодавно, ніж якийсь довідковий файл. Використовуйте "touch", щоб створити довідковий файл NEXT run на початку кожного запуску, безпосередньо перед "find ... |" команда 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 години через простої або іншу помилку.

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

http://oss.linbit.com/csync2/ призначений для подібних речей, я б спробував це.

Якщо ви використовуєте перемикач -z на rsync, спробуйте запустити без нього. Чомусь я бачив, що це пришвидшило навіть початкове перерахування файлів.

Якщо команда -z вийшла з команди rsync, яка не стискає, так швидше пішов "список файлів прийому", і нам довелося передати близько 500 ГБ. Перш ніж пройшов день із перемикачем -z.