Git для MySQL

[StalkerClasses]

Вопрос про бд MySQL. Создавая миграции всегда могу быть уверен что они попадут в гит и если база полетит то всегда смогу восстановить структуру запустив команду миграциий.

Но как быть с данными? Есть ли что то типа гита только для MySQL? Как в принципе организуется процесс отслеживания изменений в бд? У меня есть таблица платёжных систем. Случайно удалили 1 из трёх записей и все перестало работать. Если нет бэкапа то я эту запись уже ни как не восстановлю.

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

 

[WMix]

миграция это про изменение структуры, а не про данные.
на случай "случайного" удаления пользуйся backup

 

[AmdY]

Это называются фикстуры https://symfony.com/bundles/DoctrineFixturesBundle/current/index.html
Но надо понимать, что там данные только минимальный набор данных для работы приложения вроде создание пользователя-администратора, групп, справочников и т.д. Ты запустил миграции, запустил фикстуры и получил чистый проект как в нулевой день.

Большая же часть данных генерируется пользователями и для этого нужны бекапы.

 

[Squats]

Случайности не случайны.
Что за плоские темы.
Никогда у Mysql этого не было и не будет.
Для этого есть бекап, чтобы получить дамп и спать спокойно.
Какие ты там изменения отслеживать собрался?!

 

[StalkerClasses]

миграция это про изменение структуры, а не про данные.
на случай "случайного" удаления пользуйся backup

А если БД большая каждый раз выгружать по 500мб?

 

[StalkerClasses]

Случайности не случайны.
Что за плоские темы.
Никогда у Mysql этого не было и не будет.
Для этого есть бекап, чтобы получить дамп и спать спокойно.
Какие ты там изменения отслеживать собрался?!

Любые изменения.

 

[StalkerClasses]

При работе с git у вас всегда проект сохранен. Вы можете найти что то в истории. А в случае с данными например платежьная система могла быть удалена неделю назад. Ещё что то могло быть удалено два дня назад и попробуй найди это все что есть.

Если бы данные только росли в количестве в большую сторону без удаления это один вопрос. Но иногда записи можно удалить случайно или направленно. Не всегда есть флаг удалено.


И здесь пока была затронута тема только удаления данных.

Но есть ещё их обновление. Пользователь редактирует запись плателэной системы - вводит новый ключ и у меня уже нет возможности увидеть старый ключ. Те отсутсвует версионизация.

 

[StalkerClasses]

В том же laravel можно поставить что то типа версионизации для orm. Но это все вряд ли будет учитывать при прямых запросах в БД минуя API orm.

 

[c0dex]

А если БД большая каждый раз выгружать по 500мб?

Мы ничего, и поболее грузим евридей, а ты что, вручную собрался побайтно переносить все? Или на листке распечатать и в сейф положить, чтобы потом если что - набрать вручную?

 

[AmdY]

Мы ничего, и поболее грузим евридей, а ты что, вручную собрался побайтно переносить все? Или на листке распечатать и в сейф положить, чтобы потом если что - набрать вручную?

главное формат даты не попутать, если вы понимаете о чём я.

 

[StalkerClasses]

А синхронизацию между локальной разработкою и продакшином как делаете?

 

[c0dex]

синхронизацию чего?

 

[StalkerClasses]

Есть боевой сайт (файлы + БД)
Есть тестовый сайт для разработки который потом выкачиваю на боевой.
На тестовом сайте я внес изменения в БД (помимо миграций, которые выполню на боевом, я изменил часть данных в БД - например добавил новую запись платежной системы в таблицу) - как мне синхронизировать вот эти данные с боевым сайтом? У меня из вариантов только записать на листочке что на боевом нужно будет внести вот такую запись и постараться не потерять листочек о том, что это нужно сделать.

Когда я разрабатывал на битриксе - мне постоянно и все приходилось для всех наших локальных копий (1 копия - 1 разработчик) вести вот такие листочки - добавил поле в инфоблок у себя и после надо не забыть добавить это на продакшине. Если кто-то забыл внести ручками свои изменения на продакшин в БД - то это звиздец.

 

[c0dex]

Вноси это так же в миграции, будешь выполнять DDL и DML в одном контексте, главное - не забывать как-то делать откаты для таких миграций.

 

[WMix]

например добавил новую запись платежной системы в таблицу

дело хорошее, но это к программе не имеет отношения.

представь, что "запись платежной системы" - это конфиг, а программа - это wordpress.
там же нет банковских счетов?

а вот как ты это себе сохраняешь (backup команды) запиши в отдельный шаг в процедуре CI/CD.

 

[StalkerClasses]

дело хорошее, но это к программе не имеет отношения.

представь, что "запись платежной системы" - это конфиг, а программа - это wordpress.
там же нет банковских счетов?

а вот как ты это себе сохраняешь (backup команды) запиши в отдельный шаг в процедуре CI/CD.

В том то и дело что запись в бд это не конфиг, который залетит в гит в виде файла.

 

[WMix]

есть фича, PayPal. он, если включен, может выполнять pay()_ пофиг по каким паролям,
теперь я могу, просто написать pay(...)

 

[StalkerClasses]

есть фича, PayPal. он, если включен, может выполнять pay()_ пофиг по каким паролям,
теперь я могу, просто написать pay(...)

Мы всё-таки уходим от темы синхронизации данных в базе между прожакшином и локальной копией для разработки.

А также от темы версионизации записей. Про Фикступы услышал но это жёсткое задание данных в базе.

 

[c0dex]

Представь, у нас нет никакой синхронизации данных прод>дев, только структура. Как жить будешь в таком случае?

 

[grigori]

Percona XtraBackup

Percona XtraBackup is an open-source hot backup utility for MySQL - based servers that does not lock your database during the backup. It can back up data from InnoDB, XtraDB, and MyISAM tables on MySQL 5.1 , 5.5, 5.6 and 5.7 servers, as well as Percona Server with XtraDB.

www.percona.com