бросать diff для хранения очень похожих файлов?

На работе мы делаем ночной дамп наших баз данных mysql. Изо дня в день, я бы предположил, что почти 90-95% данных являются дубликатами, увеличиваясь с течением времени. (Черт возьми, на данный момент некоторые, вероятно, 99%)

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

Я искал, и я не нашел способа отсортировать вывод по дампу. Я мог бы передать это через sortкоманду, хотя. Тогда будут длинные, длинные блоки одинаковых линий.

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

Это возможно? Какими инструментами?

Изменить Я не спрашиваю, как сделать резервные копии MySQL. Забудьте MySQL на данный момент. Это красная сельдь. То, что я хочу знать, - это как сделать серию динамических изменений из серии файлов. Каждую ночь мы получаем файл (который является файлом mysqldump ), который на 99% похож на предыдущий. Да, мы сжимаем их все. Но избыточно иметь всю эту избыточность в первую очередь. Все, что мне действительно нужно, - это отличия от прошлой ночи ... которая на 1% отличается от прошлой ночи ... и так далее. Итак, что мне нужно, так это сделать серию различий, поэтому мне нужно хранить только 1% каждую ночь.

Два инструмента резервного копирования, которые могут хранить двоичные различия, - это rdiff-backup и duplicity . Обе основаны librsync, но, кроме того, они ведут себя совершенно по-разному. Rdiff-backup хранит последние копии и обратные различия, в то время как Dupility хранит традиционные инкрементные различия. Два инструмента также предлагают различный набор периферийных функций.

В последнее время я пытался хранить дампы базы данных в git. Это может оказаться непрактичным, если ваши дампы базы данных очень большие, но это работает для меня для небольших баз данных (сайтов Wordpress и т. П.).

Мой скрипт резервного копирования примерно:

cd /where/I/keep/backups && \
mysqldump > backup.sql && \
git commit -q -m "db dump `date '+%F-%T'`" backup.sql

Вы можете сделать что-то вроде этого (с a.sqlвашей еженедельной резервной копией).

mysqldump > b.sql
diff a.sql b.sql > a1.diff
scp a1.diff backupserver:~/backup/

Ваши разностные файлы станут больше к концу недели.

Мое предложение, однако, просто gzip его (используйте gzip -9для максимального сжатия). Мы делаем это в данный момент, и это дает использование 59 МБ gz-файла, в то время как оригинал составляет 639 МБ.

Существует несколько возможных подходов, в зависимости от размера и фактического текстового сходства дампов базы данных:

1. применить дедуплицирующую программу резервного копирования, которая использует скользящую контрольную сумму в качестве запросов OP, например restic ( https://restic.net/ ) или borgbackup ( https://borgbackup.readthedocs.io/ ) на неизмененные дампы. Обе системы позволяют даже монтировать определенную версию резервной копии через FUSE и работать так называемым навсегда инкрементным способом.
2. Отделите структуру базы данных от контента, подобно тому, как ребята из NCBI делают это для своих довольно больших генетических баз данных. То есть: вы должны создать SQL-сценарии для создания схемы базы данных (например, ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_schema/ ) и отдельно хранить содержимое таблиц в любом из них. открытый текст или сжатый двоичный формат без операторов вставки (как это сделано в ftp://ftp.ncbi.nlm.nih.gov/snp/organisms/human_9606_b151_GRCh38p7/database/organism_data/) например, в виде значений табуляции или запятых. Конечно, для этого требуется отдельная процедура импорта, которая создала бы операторы вставки как раз вовремя для импорта данных обратно в базу данных, т.е. восстановления из резервной копии. В случае, если ваша СУБД предлагает импортер CSV-файла, требование дополнительного скрипта, описанного выше, может быть опущено. Таким образом, сокращенные текстовые файлы могут быть снова переданы в вышеупомянутые или другие обычные программы резервного копирования, такие как rdiff-backup.
3. Выберите решение, в котором структура и контент слабо связаны, используя формат, подобный файлам arff, которые использует WEKA ( https://www.cs.waikato.ac.nz/ml/weka/arff.html ): структура и типы данных столбцы будут объявлены в заголовке файла, а фактическое содержимое будет затем разделено оператором @DATA еще раз в csv-подобной форме. Многие инструменты ETL в настоящее время предлагают считыватель arff в дополнение к разъему базы данных. Сами файлы снова могут быть загружены в обычные программы резервного копирования

(Я не сделал это в производстве.)

Делайте полное резервное копирование один раз в день или неделю. Резервное копирование релейных журналов один раз в час или день.