У меня большой набор данных (+100 ГБ), который можно хранить в файлах. Большинство файлов будут в диапазоне от 5 до 50 000 (80%), затем от 50 до 500 000 (15%) и> 500 000 (5%). Максимальный ожидаемый размер файла - 50 МБ. При необходимости большие файлы можно разделить на более мелкие части. Файлы также могут быть организованы в структуру каталогов.
Если некоторые данные необходимо изменить, мое приложение создает копию, изменяет ее и в случае успеха отмечает ее как последнюю версию. Затем старая версия удаляется. Это аварийно-безопасно (так сказать).
Мне нужно внедрить систему аварийного переключения, чтобы эти данные оставались доступными. Одним из решений является использование системы баз данных Master-Slave, но они хрупкие и вызывают зависимость от технологии баз данных.
Я не системный администратор, но читал про инструкцию rsync. Смотрится очень интересно. Мне интересно, является ли установка некоторых отказоустойчивых узлов и использование rsync от моего мастера ответственным вариантом. Кто-нибудь пробовал это раньше успешно?
i) Если да, следует ли разбивать большие файлы? Является ли rsync умным / эффективным для определения файлов, которые нужно скопировать / удалить? Должен ли я реализовать определенную структуру каталогов, чтобы сделать эту систему эффективной?
ii) Если ведущее устройство выходит из строя и подчиненное устройство берет на себя управление в течение часа (например), обновляет ли мастер снова все так же просто, как запустить rsync в обратном направлении (подчиненное устройство - главному)?
iii) Дополнительный вопрос: есть ли возможность реализовать системы с несколькими мастерами с помощью rsync? Или возможен только главный раб?
Ищу совета, подсказок, опыта и т.д ... Спасибо !!!
Стоит ли разбивать большие файлы?
rsync удобен, но синхронизация очень больших файлов может быть значительно менее эффективной. Вот почему:
Если изменяется только часть файла, то rsync достаточно умен, чтобы отправить только эту часть. Но чтобы выяснить, какую часть отправить, он должен разделить файл на логические фрагменты по X байтов, построить контрольные суммы для каждого фрагмента (с обеих сторон), сравнить фрагменты, отправить различия, а затем заново построить файл на приемный конец.
С другой стороны, если у вас есть куча небольших файлов, которые не меняются, тогда даты и размеры будут совпадать, и rsync пропустит этап контрольной суммы и просто предположит, что файл не изменился. Если мы говорим о большом количестве ГБ данных, вы пропускаете МНОГО операций ввода-вывода и экономите МНОГО времени. Таким образом, даже несмотря на то, что сравнение большего количества файлов связано с дополнительными накладными расходами, это все равно меньше времени, необходимого для фактического читать файлы и сравните контрольные суммы.
Итак, хотя вам нужно как можно меньше файлов, вам также нужно достаточно файлов, чтобы вы не тратили много операций ввода-вывода на работу с неизмененными данными. Я бы рекомендовал разделить данные по логическим границам, которые использует ваше приложение.
делает мастер снова актуальным, так же просто, как запустить rsync наоборот
С точки зрения файловой системы, да. Но у вашего приложения могут быть другие требования, которые усложняют ситуацию. И, конечно же, вы вернетесь к своей последней контрольной точке, на которой вы выполняли синхронизацию со своим ведомым устройством.
Есть ли возможность реализовать системы с несколькими мастерами с помощью rsync?
Технически да, но на этом пути лежит безумие. Если все работает отлично, тогда все будет хорошо. Но при икоте можно начать сталкиваться с проблемами с изменениями (и специально удаляет) синхронизация в неправильном направлении, перезапись ваших хороших файлов плохими, удаление ваших вставленных файлов или повторное появление призраков удаленных файлов. Большинство людей не рекомендуют это делать, но вы можете попробовать, если хотите.
советы, подсказки, опыт
Если вы ищете конфигурацию master / master с синхронизацией на лету, я бы порекомендовал DRBD. Его значительно сложнее настроить и поддерживать, но он намного более эффективен. Он выполняет синхронизацию на уровне блоков самого диска, а не файлов на нем. Чтобы сделать это «в режиме онлайн», вам нужна файловая система, которая может выдерживать такой тип синхронизации, например GFS.
Rsync больше похож на систему моментальных снимков, чем на систему непрерывной синхронизации.
Является ли rsync умным / эффективным при определении файлов для копирования / удаления?
Rsync чрезвычайно эффективен при обнаружении и обновлении файлов. В зависимости от того, как ваши файлы меняются, вы можете обнаружить, что меньшее количество больших файлов намного проще синхронизировать, чем множество маленьких файлов. В зависимости от того, какие параметры вы выберете, при каждом запуске он будет вызывать stat () для каждого файла с обеих сторон, а затем передавать изменения, если файлы разные. Если изменяется только небольшое количество ваших файлов, то этот шаг по поиску измененных файлов может оказаться довольно дорогостоящим. На то, сколько времени занимает rsync, влияет множество факторов. Если вы серьезно настроены попробовать это, вам следует провести много тестов на реальных данных, чтобы увидеть, как все работает.
Если мастер выходит из строя и подчиненное устройство берет на себя управление на час (например), обновляет ли мастер снова все так же просто, как запустить rsync в обратном направлении (подчиненное устройство - главному)?
Должно быть.
Есть ли возможность реализовать системы с несколькими мастерами с помощью rsync?
Unison, в котором используются библиотеки rsync, обеспечивает двунаправленную синхронизацию. Он должен разрешать обновления с обеих сторон. С правильными параметрами он может выявлять конфликты и сохранять резервные копии любых файлов, в которых были внесены изменения на обоих концах.
Не зная подробностей, я не могу сказать вам с уверенностью, что это правильный путь. Возможно, вам придется взглянуть на DRBD или какой-либо другой кластерный подход к устройству / файловой системе, который будет синхронизировать вещи на более низком уровне.