Создан  demius PM 3 года назад; Обновил  demius PM год и 4 месяца назад

Важная справочная информация по работе с миграциями базы, при апдейте. Часть останется базой знаний, часть важна только для перехода с 0.2.* к 0.3, и потом устареет. Тогда нужно будет часть инфы вынести в какой-то общий документ обслуживания прода, а этот документ оставить архивным

Не интуитивные команды, которые мы постоянно гуглим

docker compose exec -u1000 php bin/console doctrine:migration:migrate - накатить до самого нового состояния
docker compose exec -u1000 php bin/console doctrine:migration:migrate prev - откатить последнюю миграцию
docker compose exec -u1000 php bin/console doctrine:migration:generate - Создать пустую миграцию
docker compose exec -u1000 php bin/console doctrine:migration:diff - Создать миграцию со всеми изменениями в сущностях относительно того, что в БД
docker compose exec -u1000 php bin/console doctrine:migration:execute 'App\\Migrations\\Version20230529175045' --up|--down - накатить конкретную миграцию. Здесь важно, в " заключена команда запускаемая в контейнере, иначе часть аргументов останутся в make. В ' заключена строка с FQCN класса миграции, иначе он её не находит. \\ - экранируем обратный слеш. Вот такой треш.

Эти команды имеют сокращения в makefile вида make back_exec "bin/console doctrine:migration:migrate prev", но они не работают, так как без кавычек ключи команд считаются ключами самого make, а с кавычками теперь они считаются самой командой и ищутся докером целиком, т.е. так исполнять можно только команды без аргументов, вроде make back_exec pwd, толку в чем почти нет.

Важная одноразовая информация.

До версии v0.3 миграции лежали в namespace DoctrineMigrations, хотя располагались по пути src/Migrations В рамках избавления от легаси мы перенесли их в правильный неймспейс App\Migrations, в том числе и на проде, поэтому до деплоя v0.3 миграции в проекте работать не будут. Если вдруг мы все таки решим выпустить какую-то промежуточную версию, со своими миграциями, то перед её деплоем необходимо будет сделать

UPDATE migration_versions
SET version = REPLACE(version, 'App\\', 'Doctrine');

А перед деплоем v0.3

UPDATE migration_versions
SET version = REPLACE(version, 'Doctrine', 'App\\');

соответственно.

На проде я это так рано изменил, так как никаких промежуточных версий не предполагается, а до деплоя v0.3 я об этом забуду.

отслеживание запросов к БД

Информация как включить логирование sql запросов и slow логов в mysql

docker/mysql/my.cnf

[mysqld]
....
general_log = 1
general_log_file = /var/log/mysql/query.log
log-error = /var/log/mysql/error.log
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=0.1

docker-compose.yml

mysql:
  restart: always
  image: mysql:5.7
  volumes:
    - "./docker/mysql/my.cnf:/etc/my.cnf"
    - "mysql-data:/var/lib/mysql"
    - "./docker/mysql/logs:/var/log/mysql" 👈 левая папка это то место где оно пробросится в проекте у меня /docker/mysql/logs

P.S. Обратите внимание на параметр long_query_time=0.1 все что выше этого попадет в slow.log

Таким образом можно как отслеживать как медленные запросы, так и все, чтобы понять какие запросы у нас сильно дублируются и нуждаются в кеше, а какие например кешируются на уровне доктрины. (привет tndt-38)

Комментарии могут оставлять только авторизованные пользователи