Чи є резервна копія бази даних MySQL в Git?

Я намагаюся покращити ситуацію резервного копіювання для свого додатка. У мене є програма Django та база даних MySQL. Я прочитав статтю, в якій пропонується створити резервну копію бази даних в Git.

З одного боку, мені це подобається, оскільки він зберігатиме копію даних та коду синхронізовано.

Але Git призначений для коду, а не для даних. Таким чином, це буде робити багато зайвих робіт, відрізняючи демпфінг MySQL на кожен комітет, що насправді не потрібно. Якщо я стискаю файл перед його збереженням, чи git все ще відрізнятиме файли?

(Дамп-файл на даний момент 100 Мб нестиснений, 5,7 МБ при бізуванні.)

Редагувати: визначення схеми коду та бази даних вже є у Git, це справді ті дані, яких я хвилююсь щодо резервного копіювання.

Перш ніж ви втратите будь-які дані, дозвольте мені спробувати внести цю проблему до системи.

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

Ось деякі проблеми, які я можу передбачити, намагаючись створити резервну копію вашої бази даних в git:

• Сховище різко зросте з кожною "резервною копією". Оскільки git зберігає цілі об'єкти (хоч і стиснуті), а потім розрізняє їх пізніше (наприклад, під час запуску git gc) і зберігає історію назавжди , у вас буде дуже великий обсяг даних, які вам насправді не потрібні або навіть не потрібні. Можливо, вам знадобиться обмежити кількість або тривалість зберігання резервних копій, які ви робите для економії місця на диску або з юридичних причин, але важко видалити старі версії з git repo без великих пошкоджень.
• Відновлення обмежене моментом часу, який ви зберегли у сховищі, і оскільки дані настільки великі, повернення більше тривіального часу може бути повільним. Система резервного копіювання, розроблена для цієї мети, обмежує кількість даних, що зберігаються, потенційно надаючи більш детальну деталізацію, та забезпечує швидше відновлення, скорочуючи час простою у випадку катастрофи. Рішення щодо резервного копіювання даних ( приклад ), що знають базу даних, також можуть забезпечувати постійне резервне копіювання, гарантуючи, що не буде втрачена жодна транзакція.
• Коміти, ймовірно, також будуть повільними та повільнішими у міру зростання бази даних. Пам'ятайте, що git - це, по суті, сховище даних ключових значень, відображене на файлову систему , і, таким чином, підпорядковується характеристикам продуктивності базової файлової системи. За цей проміжок часу можливо в кінцевому підсумку перевищити інтервал резервного копіювання, і в цей момент ви більше не зможете відповідати вашій угоді за угодою. Правильні системи резервного копіювання також потребують більшого часу для резервного копіювання в міру зростання даних, але не настільки різко, оскільки вони автоматично керуватимуть власним розміром на основі налаштованої вами політики збереження.

Незважаючи на те, що, мабуть, є кілька цікавих речей, які ви можете зробити з дампами бази даних, якщо ви помістите його в git, загалом я не можу рекомендувати його для збереження резервних копій. Тим більше, що системи резервного копіювання широко доступні (а багато хто навіть з відкритим кодом) і працюють набагато краще, щоб захистити ваші дані та зробити можливим відновлення якнайшвидшого.

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

Дозвольте припустити, що головна причина, чому ви думаєте про це, - це "зберігати копію даних та коду синхронно", і це означає, що ви переживаєте, що версія 2.0 вашого коду потребує іншої схеми бази даних, ніж версія 1.0 . Більш простим рішенням було б зберігання схеми бази даних як набору SQL-скриптів із CREATEзаявами вздовж вихідного коду у вашому репозиторії Git. Тоді частиною вашої процедури встановлення буде виконання цих скриптів на раніше встановленому сервері баз даних.

Фактичний вміст цих просто CREATE-d таблиць не має нічого спільного з версією вашого вихідного коду. Уявіть, що ви встановлюєте програмне забезпечення версії 1.0 на сервер A і на сервер B, які використовуються в різних компаніях різними командами. Через декілька тижнів зміст таблиць буде дуже різним, навіть якщо схеми точно однакові.

Оскільки ви хочете створити резервну копію вмісту бази даних, я б запропонував вам використовувати сценарій резервного копіювання, який позначає дамп резервної копії з поточною версією програмного забезпечення, до якого належить дамп. Сценарій повинен знаходитись у сховищі GIT (щоб він мав доступ до рядка версії вихідного коду), але самі дампи не належать до системи контролю версій.

Редагувати :

Прочитавши оригінальний пост, який мотивував питання , я вважаю це ще більш сумнівною ідеєю. Ключовим моментом є те, що mysqldumpкоманда перетворює поточний стан БД у ряд операторів SQL INSERT, і GIT може відрізняти їх, отримуючи лише оновлені рядки таблиці.

mysqldumpЧастина звуку, так як це один із способів резервного копіювання , перерахованих в документації в MySQL. Частина GIT - це те, де автор не помічає, що сервери баз даних зберігають журнал транзакцій для відновлення після збоїв, включаючи MySQL . За допомогою цього журналу , а не GIT, ви повинні створювати додаткові резервні копії для вашої бази даних. Це, перш за все, перевага в тому, що ви можете обертати або змивати журнали після відновлення, замість того, щоб розвантажувати сховище GIT у нескінченність і далі ...

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

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

Моє остаточне зауваження щодо резервного копіювання бази даних та GIT: Адміністратору бази даних, коли йому потрібно відновити базу даних, оскільки деякі дані були втрачені, не потрібно перевіряти відмінності між файлом резервного копіювання за 1 день та файлом резервного копіювання на 2 день, йому потрібно просто знати, що саме останній файл резервної копії, який дозволить йому відновити базу даних, без будь-яких помилок і втрати даних, скорочуючи час простою. Дійсно, завдання адміністратора бази даних - зробити доступними для відновлення дані якомога швидше, коли система з якихось причин виходить з ладу. Якщо ви зберігаєте резервні копії бази даних у GIT, пов’язані з вашими комісіями, ви не дозволяєте адміністратору бази даних швидко відновити дані, оскільки ваші резервні копії обмежені часом, який ви зберігаєте у сховищі GIT, та скорочуєте час простою. системи,

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

Не слід зберігати двійкові дані в Git - особливо в базі даних.
Зміни коду та зміни DML бази даних - це абсолютно різні речі.

MySQL та Oracle можуть записувати журнали архівів з метою відновлення до будь-якого моменту часу. Просто створіть резервні копії цих журналів кудись у безпечному місці, і вам буде добре.

Використовувати Git для резервного копіювання цих "архівів журналів" не має сенсу. Журнали архівів у виробничих умовах досить важкі і їх слід видаляти після регулярних повних резервних копій. Крім того, марно їх класти в git - вони вже є сховищем у певному сенсі.