прокат відрізняється для зберігання високо схожих файлів?

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

У цих дампах один рядок - це єдиний оператор mysql INSERT, тому єдиними відмінностями є цілі рядки та порядок, у якому вони знаходяться у файлі. Якби я їх сортував, фактична різниця від файлу до файла була б дуже мала.

Я шукав, і не знайшов жодного способу сортувати вихід на дамп. Я міг би передати це sortкомандою. Тоді були б довгі довгі блоки однакових ліній.

Тому я намагаюся знайти спосіб зберігати лише різні. Я міг би почати з майстерного дампа і відрізнятись від цього щовечора. Але різниці будуть щовечора більшими. Або я можу зробити прокатки різниць, які окремо були б дуже маленькими, але здається, що для того, щоб обчислити, потрібно більше і довше, якщо мені доведеться щовечора складати головний діф з усієї серії.

Це можливо? За допомогою яких інструментів?

Редагувати Я не запитую, як робити резервні копії mysql. Забудьте на даний момент mysql. Це червона оселедець. Те, що я хочу знати, - це те, як зробити прокрутку серії, що відрізняється від серії файлів. Щовечора ми отримуємо файл (який, як і файл mysqldump ), який на 99% схожий на той, що був до нього. Так, ми gzip їх усіх. Але зайве все це надмірність в першу чергу. Все, що мені справді потрібно, - це відмінності від ночі перед ... що лише на 1% відрізняється від ночі раніше ... і так далі. Тож, про що я хочу, - це зробити серію різниць, тому мені потрібно зберігати лише 1% щовечора.

Два інструменти резервного копіювання, які можуть зберігати двійкові розрізки, - це резервне копіювання rdiff та подвійність . Обидва базуються на них librsync, але вище, ніж вони поводяться зовсім інакше. Rdiff-резервне копіювання зберігає останню копію та реверс різниться, тоді як дублікат зберігає традиційні додаткові розходження. Два інструменти також пропонують різний набір периферійних функцій.

Останнім часом я намагаюся зберігати скиди баз даних у 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. застосувати програму резервного копіювання, що використовує кодування, яка використовує прогорнуту контрольну суму в якості запиту ОП, наприклад, рестик ( https://restic.net/ ) або боргбекап ( 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-резервне копіювання.
3. Виберіть рішення, де структура та вміст вільно поєднуються у форматі, наприклад, файлах arff, як використовується WEKA ( https://www.cs.waikato.ac.nz/ml/weka/arff.html ): структура та типи даних стовпці оголошуватимуться у заголовку файлу, а власне вміст після цього повторюється розділеним оператором @DATA ще раз у формі, схожій на csv. Зараз багато інструментів ETL пропонують зчитувач arff на додаток до роз'єму бази даних. Самі файли знову могли подаватися у звичайні програми резервного копіювання

(Я цього не робив у виробництві.)

Робіть повну резервну копію один раз на день або тиждень. Резервні реле журнали один раз на годину чи день.