Вопросы Теги

Как переместить данные с сервера на сервер с как можно меньше временем простоя?

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

   International support is available with this package.   Native  lan‐
   guage  manual pages are accessible (if available on your system) via
   use of locale functions.  To activate such support, it is  necessary
   to  set either $LC_MESSAGES, $LANG or another system dependent envi‐
   ronment variable to your language locale, usually specified  in  the
   POSIX 1003.1 based format:

   <language>[_<territory>[.<character-set>[,<version>]]]

   If  the  desired  page  is available in your locale, it will be dis‐
   played in lieu of the standard (usually American English) page.
3
07.11.2013, 16:29
3 ответа

Можно сделать это с чем-то как Aufs или Unionfs.

Обе этих файловых системы являются файловыми системами "объединения". Вы сделали бы что-то такой как

  • Смонтируйте старый NAS в /mnt/old
  • Смонтируйте новый NAS в /mnt/new
  • Смонтируйте файловую систему объединения в /mnt/nas с /mnt/new сверху /mnt/old.
  • Любой доступ к /mnt/nas/foo/bar будет сначала искать /mnt/new/foo/bar, и если это не будет там, то отступит к /mnt/old/foo/bar. При изменении файла он скопирует оригинал с /mnt/old на /mnt/new и затем измените /mnt/new версия.
  • После того, как файловая система объединения смонтирована, можно работать rsync от /mnt/old кому: /mnt/new. Это может быть сделано, в то время как система жива. Доступ /mnt/nas начнет поднимать файлы от /mnt/new поскольку rsync помещает их там.
2
27.01.2020, 21:28
  • 1
    Разве это не вызовет crouption, если очередь попытается записать одновременно rsync, делает? Или возвращение, если очередь пишет прежде rsync (или недостающие данные, если rsync только копирует более новый)? –  coteyr 07.11.2013, 20:05
  • 2
    Единственная возможная проблема состоит в том, если unionfs создает файл в то же самое время rsync, делает. Но из сценария в вопросе эта привычка происходят. Однако, если этот ответ применяется к другим ситуациям, это могла бы быть проблема да. То, что Вы смогли делать (я не попробовал), touch каждый файл на /mnt/nas. Операция записи должна заставить это копировать файл. Однако это изменит все время изменения. –  Patrick 07.11.2013, 22:21

Как насчет того, чтобы продолжиться как это:

  1. 1-й Rsync
  2. Сделайте ответ qmail 421 Service not available, closing transmission channel в баннере
  3. 2-й Rsync
  4. Восстановите исходную конфигурацию qmail (или переключитесь на другой сервер, я не уверен, что получил ту часть),

Таким образом, Вы полагались бы на то, что клиенты повторят позже для поставки электронной почты.

0
27.01.2020, 21:28
  • 1
    Мы уже стоим в очереди почта, поступающая в другом устройстве так, чтобы ответ не был необходим. Наше главное беспокойство является временем простоя самой системы нашим клиентам, пытающимся получить доступ к их почте. 16 часов просто не приемлемы, и наш текущий план мог предоставить немедленный доступ, но не к вещам, которые они, возможно, просто имели. –  Mythics 07.11.2013, 19:28

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

Если Вы не собирающийся случайным образом удалять письма необходимо остановить записи к системе хранения, или путем ответа 421, 450, или 452. Лично я выбрал бы 450 "Недоступных почтовых ящиков пользователей".

Так, я был бы Rsync, сопровождаемый путем возврата 450, сопровождаемый rsync и наконец изменением среды хранения.

Помните, что электронная почта, как предполагается, не надежна. Как просто предполагалось, чувствовали его тот путь. Отказ принять сообщение означает, что сервер, отправляющий сообщение Вам, должен попробовать еще раз. Обычно это было бы каждые 4 часа в течение 24 часов, но это просто "нормально" и не правило.

Как в стороне, если Вы не использовали NFS (или если сервер NFS доступен как это) Вы могли бы попытаться поместить устройство хранения данных в некоторый кластер, затем просто добавив новое устройство хранения данных к кластеру и удалить старое устройство хранения данных. Это могло быть выполнено с любым некоторым RAID (если на той же машине) или с чем-то как DRBD. Так как идея - это, Вы просто следуете за нормальной процедурой обновления сервера добавления нового сервера к кластеру, даете ее, время для "нагоняния" затем удаляет старый сервер.

0
27.01.2020, 21:28
  • 1
    я довольно люблю кластерную идею, но я должен буду, конечно, исследовать его. Я все еще немного плохо знаком с миром unix/linux, таким образом, мне может потребоваться некоторое время. Мы уже стоим в очереди почта, поступающая в другом устройстве так, чтобы ответ не был бы необходим. Наше главное беспокойство является временем простоя самой системы нашим клиентам, пытающимся получить доступ к их почте. 16 часов просто не приемлемы. –  Mythics 07.11.2013, 19:27
  • 2
    Этому, вероятно, придется быть, если Ваша система не была разработана для масштабирования. Нормальный материал сервера этого размера, должен быть в кластере. Нет никакого способа безопасно копировать данные (кроме некоторого кластера), не останавливая запись новых данных. Если Вы не останавливаете новые входящие данные, Вы рискуете повреждением. Исследуйте кластер, это - Ваш лучший выбор, но все еще потребует, чтобы время простоя установило. Однако, по крайней мере, этот путь, у Вас не будет времени простоя "следующим разом". –  coteyr 07.11.2013, 20:03

Теги

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