Блог

#git #git-commit #pre-commit-hook

Вопрос:

 #!/bin/bash  systemname="mysystem" dumppathname=".dbexports/${systemname}_dbdump_$(date  %Y%m%d_%H%M%S).sql"  ./.scripts/dump_database.sh $dumppathname  if test $? -ne 0 then  echo "Dumping database failed. Aborting the commit..."  exit 1 else  git add $dumppathname  exit 0 fi   

 me@mysystem /websitegt; git commit -m "Track database changes, only."  

 Dumping current database 'mywebsite' to '.dbexports/mysystem_dbdump_20211024_132309.sql' On branch master Untracked files:  (use "git add lt;filegt;..." to include in what will be committed)  .dbexports/mysystem_dbdump_20211024_132309.sql  nothing added to commit but untracked files present (use "git add" to track)  

 me@mysystem /websitegt; git commit -m "Track database changes, only. Second time."  

 Dumping current database 'mywebsite' to '.dbexports/mysystem_dbdump_20211024_132323.sql' [master 87cfdb9] Track database changes, only. Second time., 1 uncommited files.  2 files changed, 22630 insertions( )  create mode 100644 .dbexports/mysystem_dbdump_20211024_132309.sql  create mode 100644 .dbexports/mysystem_dbdump_20211024_132323.sql  

Комментарии:

1. Я не могу сказать наверняка, но держу пари , что дамп занимает много времени, и что ваш сценарий фиксирует частичный дамп в том виде, в каком он существует на данный момент. При повторной попытке программное обеспечение БД ставит запрос в очередь и продолжает запись первого файла, но еще не запустило второй. Когда вы попытались в третий раз, программное обеспечение завершило работу со вторым и сразу же приступило к третьему и т. Д.

2. Все это говорит о том, что программное обеспечение для баз данных, как правило, хочет создавать свои собственные резервные копии по-своему: дампы, экспортируемые подобным образом, обычно не предназначены для повседневных целей резервного копирования, и Git, как правило, не подходит для хранения резервных копий БД. Проблема здесь в том, что Git сам по себе является своего рода базой данных, и хранение баз данных внутри баз данных в стиле создания обычно в лучшем случае приводит к низкой производительности.

3. @torek Я сомневаюсь, что это вопрос времени. Экспорт БД выполняется быстро. Его размер составляет всего 1,7 МБ. В сценарии оболочки одна команда выполняется только после возврата предыдущей. И, тем временем, у меня есть два mysqldumps запуска один за другим в сценарии дампа. То же поведение и повторяемость: если до этого в рабочем каталоге вообще не было изменений git commit , git отвечает «ничего не добавлено для фиксации , кроме неотслеживаемых изменений», и два файла дампа отображаются как неотслеживаемые. Следующий git commit сразу же после этого фиксирует все 4 файла дампа, два из предыдущего фиксации и два из этого.

4. @torek Я не использую git для резервного копирования базы данных. Но на самом деле веб-фрейм работает так, как Joomla, и в данном случае Piwigo хранит часть конфигурации в некоторых таблицах базы данных вместе с файлами wirth в файловой системе. Мой рабочий процесс таков: я добавляю компонент, скажем, плагин, на свой сайт разработчика, настраиваю и тестирую. Когда все будет хорошо, я хочу развернуть на сайте prod. Для этого мне нужно применить все изменения в файловой системе (файлы компонентов, файлы конфигурации и т.д.), А также все изменения в базе данных, которые относятся к этому изменению.

5.Ха, хорошо, ну, на данный момент ты далеко за пределами моего опыта работы с этой базой данных. Я также скажу, что выполнение git add внутри крючка предварительной фиксации может сработать, но обычно это плохая идея, потому что это создает потенциальные проблемы с git commit --only и. git commit --include Обычно лучше всего использовать сценарий, который выполняет всю подготовительную работу, а затем запускает свой собственный git commit .