Вопросы Теги

Хранение файлов, синхронизировавших через два сервера

Обычно Вы просто пишете сценарий в него и помещаете, делают запись крона для сценария, таким образом, это работает так часто, как Вы хотите. Существует набор примеров здесь.

Интенсивный курс резервного копирования базы данных для программиста:

  • Вы хотите, чтобы дампы или были выполнены с другого сервера (по крайней мере), или были скопированы в другой сервер. Идеально они переходят к другому географическому положению.
  • Другая опция состоит в том, чтобы сделать все это локально и затем иметь Ваше резервное копирование на магнитную ленту быть резервным копированием тех дампов. С этим удостоверьтесь Вы время это право. Например, если Вы выводите, происходит прямо после ленты создают резервную копию (и Вы ежедневно копируете), и затем Ваш сервер перестает работать прямо, прежде чем резервное копирование на магнитную ленту запускается, Ваши данные будут близки 48 старых часов. Это немного сбивает с толку, но если Вы тянете временную шкалу, она имеет смысл (или возможно цикл с оператором сна, если Вы - программист :-)). Так в основном удостоверьтесь выполнения дампа перед резервным копированием на магнитную ленту.
  • Всегда хорошо иметь несколько версий резервного копирования.

Плохо:

outfile = ''
i = 0
while backup:
    version = i % 7;
    //In this case, the dump is from from the previous iteration of loop
    Tape_Backup(outfile); 
    DB_Dump(outfile=strcat('dump.' + version + '.tar.gz'));
    Sleep(1 day);

Хороший:

outfile = ''
i = 0
while backup:
    version = i % 7;
    DB_Dump(outfile=strcat('dump.' + version + '.tar.gz'));
    Tape_Backup(outfile);
    Sleep(1 day);

1
задан 9 February 2012 в 23:23
5 ответов

У нас есть аналогичная установка с nginx перед серверами приложений ruby. В этом сценарии мы используем блеск. Веб-серверы с балансировкой нагрузки - это серверы gluster, а серверы приложений - клиенты gluster.

Gluster использует FUSE, поэтому его может быть проще запустить в среде VPS.

1
ответ дан 3 December 2019 в 16:50

Лучше, чем запускать rsync каждые три секунды (или что-то подобное), запускать rsync всякий раз, когда файлы действительно изменяются. Это легко сделать с помощью incron . Incron похож на cron, но вместо того, чтобы указывать что-то вроде «запускать каждую минуту», вы можете сказать «запускать каждый раз при изменении файла». Вы можете указать incrontab следующим образом: 

/path/to/webroot IN_MODIFY,IN_CREATE rsync -az $@/$# user@otherserver:$@/$#
/path/to/webroot IN_DELETE rsync --delete $@ user@otherserver:$@
3
ответ дан 3 December 2019 в 16:50

http://www.csync.org/ похож на rsync, но разработан с учетом этой конкретной ситуации; Я думаю, вам все равно может понадобиться что-то для его запуска, например incron

1
ответ дан 3 December 2019 в 16:50

Ваши исходные файлы меняются так часто, что вы даже можете подумать о rsyncing каждые 3 секунды, или это динамически генерируемые файлы?

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

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

1
ответ дан 3 December 2019 в 16:50

Просто наткнулся на этот ответ, когда искал собственное решение. Проблема с incron в том, что он не контролирует подкаталоги и папки.

Альтернативой является lsyncd: http://code.google.com/p/lsyncd/

0
ответ дан 3 December 2019 в 16:50

Теги

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