Как лучше всего синхронизировать физические файлы, используемые на двух разных серверах?
Возможно, кто-то сталкивался со схожей задачей.
Итак, у нас есть «основной» сервер, где тусуются пользователи, и есть «тестовый» сервер, где также есть пользователи, но уже (как понятно из названия) тестируют его (обычные пользователи туда доступа не имеют).
Среда на обоих серверах одинаковая: debian, nginx, php-fpm, sphinx, percona mysql. При этом СУБД фактически одна для обеих машин (одни данные) — что дает одних и тех же пользователей, данные о них, их записи и т.д. и т.п.
Вопрос звучит следующим образом: как синхронизировать на обоих серверах физические данные (файлы изображений, флешек — что загружают пользователи, как тестовые, так и обычные)? То есть необходимо, чтобы добавленные файлы на основном сервере появлялись на тестовом, а добавленные на тесте дублировались на основной.
Файлы уже сейчас занимают 2+Gb, в день прибавляется по 50-70Mb.
P.S. пробовали rsync (с ключами на апдейт и рекурсию) — обновление идет более 10 минут, что уже ненормально.
P.P.S. попробовали и sshfs+symlinks — часть кэш-файлов (текстовых), что инклудятся — падают на Permission denied (php-fpm в этом случае на root перевести не удалось), как впрочем и новозагружаемые файлы (на том сервере, где находится symlink).
Ну тогда все-таки советую посмотреть в сторону GlusterFS. На дебиан прикручивается шустро, работает более-менее стабильно. У нас 1 высоконагруженый проект на 25-30 миллионов юзеров работает на ней.
spacediver, При высоких нагрузках и активной выкладке файлов/контента загруженность ЦПУ возрастает довольно сильно, что вцелом сказывается на работе серверов, но отказа сервиса по причине GlusterFS не было ни разу. Так что тут можно употребить что бОлее стабильно, чем менее =)
Используйте csync2.
Как плюс, csync2 подходит для достаточно тяжелых проектах. Конфиги можно разделить на несколько частей, и эти части запускать с разной периодичностью, также не нагружает систему при таких нагрузках.
Как вариант — прикрутить GlusterFS и каталоги юзеров размещать на данном разделе. Её минус — обновление проходит при обращении или листинге файлов и жрет ЦПУ при нехилых нагрузках. Как костыль — засунуть в cron ls -R на каждые 5 минут. Вообще она хороша, но есть некоторые недочеты, которые приходится допиливать самим.
Может, вы как-то неправильно используете rsync? Там же есть разные проверки, чтобы не копировать лишнее, а синхронизировать 70 Мб — это вообще смешная задача для нее.
Также, советую поменять схему репликации, незачем с тестового сервера (возможно, ошибочные) данные копировать на боевой.
а нельзя ли убрать опцию «c»? тогда не будет считаться контрольная сумма, а изменённость будет определяться по разнице размеров и времени изменения. Я думаю это самое дорогое в вашем варианте.
Используем lsyncd на проектах с большим количеством файлов и объемов (сотни гб) — все отлично. Для синхронизации внутри используется rsync — вообще он быстро работает на уже синхронизированном каталоге, 10 мин — это на первый запуск только может быть.
