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


18

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

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

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

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

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


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

Ответы:


14

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


1
IIUC, rdiff-backup более привлекателен, поскольку позволяет нормально просматривать резервную копию, в то время как у duplicity есть только старая копия.
Чепанг

Я знаю, что вопрос + вопрос довольно старый, но не могли бы вы добавить пример команд, показывающих, как его использовать? Например, для backup201901.tar.gz, backup201902.tar.gz, ..., backup201912.tar.gz, backup202001.tar.gz. Это было бы полезно для дальнейшего использования.
Basj

В прошлый раз, когда я следовал rdiff-backup, основные разработчики пошли дальше, и проект как бы застоялся, Не знаю, изменилось ли это. Это было также невероятно медленно по сетям, если это имеет значение.
Lizardx

13

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

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

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

Это только магазины различий?
user394

2
Да. Это очень удобно! Вы можете «проверить» файл в любой момент времени, и git автоматически объединит различия, чтобы получить весь файл, существовавший в то время.
Sep332

1
Этот пост (не мой) более детально рассмотрен: viget.com/extend/backup-your-database-in-git. В комментариях подробно рассматриваются плюсы и минусы и предостережения. Я также добавлю, что если вы используете git, вы получаете больше, чем просто возможность откатить версии. Вы также можете пометить дампы или иметь отдельные ветки (dev / prod). Я смотрю на это с помощью git (или вставляю вашу любимую современную систему управления версиями) лучше, чем я, выполняя собственное «решение» diff / gzip. Одно предупреждение об этой статье: не отправляйте свои дампы на github, если вы не хотите, чтобы они были публичными (или вы платите за частное репо).
смочить

1
Git не только хранит различия. Фактически, в первую очередь он хранит полный снимок каждой ревизии, но с различными оптимизациями. Смотрите этот отличный ответ и его вопрос
Tremby

3

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

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

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

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


Мы уже распаковали их :)
user394

1

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

  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 в дополнение к разъему базы данных. Сами файлы снова могут быть загружены в обычные программы резервного копирования

Этот ответ отвечает на вопрос «Как выполнять циклическое резервное копирование дампов базы данных», но не на более общий вопрос «Как создавать резервные копии очень похожих резервных копий», который я и задал
user394

Честно говоря, я подозреваю, что на самом деле вы хотите добиться дедупликации, что упоминается в первом подходе. Может быть, вы хотели бы взглянуть на restic.net/blog/2015-09-12/restic-foundation1-cdc, где это описано, и, может быть, тогда вы хотели бы попробовать их?
JF1

Этот комментарий, подробно изложенный, даст гораздо более подходящий ответ, чем ваш текущий.
user394

-3

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

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


Что такое релейный журнал?
user394
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.