rsync --inplace не читает целевой файл?
Я пытаюсь оптимизировать ежедневное резервное копирование снимка LVM большой базы данных MySQL. Это нормально работает, когда я просто cp файлы (от локального RAID к другому локальному RAID) со средней скоростью ~ 100 МБ / с. Но поскольку файлы базы данных (600 ГБ, большая часть в двух файлах по 350 и 250 ГБ) не сильно меняются в течение одного дня, я подумал, что было бы более эффективно копировать только измененные блоки.
я использую
rsync --safe-links --inplace -crptogx -B 8388608 /source/ /destination/
Он действительно работал, был медленнее, чем простая копия, и я не видел активности чтения на целевом диске. Я думал, что rsync будет читать (8 МБ) блоки из источника и назначения, сравните их контрольные суммы и скопируйте исходный блок в целевой файл, только если он был изменен. Я что, ошибаюсь? Почему я не вижу, чтобы rsync считывался из цели, чтобы определить, изменились ли блоки?
Вот несколько графиков:
Использование диска: вы видите, что rsync --inplace (выполненный только для большого файла в последний день) уменьшил "вмятину" в использовании диска / mnt / backup, что означает, что он действительно обновил существующий файл на месте.
Статистика ввода-вывода: бэкап делается с sda на sdb. Почему-то наблюдается огромный пик чтения из источника, за которым следует «нормальная» активность чтения (источник) + запись (цель). Я ожидал одновременного чтения с обоих устройств при небольшой активности записи на целевом устройстве.
То, что вы, вероятно, видите, связано с тем, как изменяются ваши файлы и как rsync вычисляет контрольные суммы. На странице руководства rsync относительно --inplace есть базовое объяснение:
o The efficiency of rsync's delta-transfer algorithm may be reduced if some data in the destination file is overwrit- ten before it can be copied to a position later in the file. This does not apply if you use `--backup`, since rsync is smart enough to use the backup file as the basis file for the transfer.
Поэтому вам, вероятно, не следует использовать --inplace или --backup для сохранения старой копии файла. При этом кажется, что rsync обрабатывает большие файлы довольно неэффективно, поэтому он может быть не лучшим инструментом для работы.
Если вы используете LVM и действительно хотите передать данные моментального снимка, возможно, вам не захочется запускать rsync, который требует значительных вычислений и ввода-вывода с обеих сторон, но скопируйте данные CoW моментального снимка на конечный компьютер, используя lvmsync вместо этого - это избавит вас от циклов ввода-вывода и процессора за счет предположительно большего размера передачи.
Другой подход к проблеме - выполнение контрольных сумм "тупого" блочного устройства (например, с MD5) и передача дифференцирующих блоков, как в этот ответ здесь, на ServerFault или в blockync.py скрипт (Я связал его последний активный форк). Это вообще не будет зависеть от моментальных снимков, но, очевидно, вы захотите создать один на время копии, чтобы обеспечить согласованность ваших данных.
Если вас беспокоит производительность записи вашей базы данных с активными снимками, вы также можете взглянуть на ddsnap который содержит несколько оптимизаций для моментальных снимков и репликации томов, эффективно решающих ваши проблемы.
Я верю ты хочешь --inplace --no-whole-file. Обратите внимание, что для локальных файловых систем --whole-file предполагается (см. справочную страницу rsync). Видеть хороший небольшой тест на unix.SE. Обратите внимание на комментарии.