У нас была миграция пролетного пути, которая возвращалась как неудача в нашей работе с дженкинсами на днях. Когда мы посмотрели на БД, мы обнаружили, что сценарий был применен, но в таблице «schema_version» для скрипта не было создано никакой записи. Мы знаем, что этот сценарий занял много времени, чтобы применить (изменение таблицы с примерно 70M строк), и мы использовали синтаксис SQL, который сделает изменение не блокирующим по крайней мере (ALGORITHM = INPLACE на mysql). Однако, когда сценарий был закончен, пролетной путь вернулся с неудачей дженкинсов и не запускал никаких скриптов после этого длинного.Провальная ложная ошибка
Мы запускаем пролет через плагин gradle (версия 3.2.1) и используя возможность вызова задачи градации. Дженкинс вызывает возможность, которая вызывает град, который вызывает пролет. Не уверен, что это вызвано сроком вылета или невозможным. Мы бы хотели, чтобы это не произошло снова в производстве.
Наше обходное решение заключалось в том, чтобы вручную ввести запись в schema_version, чтобы сценарий не запускался повторно, а затем повторно применяйте миграцию, чтобы скрипты после нее выполнялись.
Мы посмотрели на дБ, и в то же время произошел случайный всплеск соединения, поэтому, возможно, он столкнулся с лимитом соединения, но я решил, что соединение уже будет открытым, если оно запускает скрипт.
продезинфицировать выход из Дженкинс выглядит следующим образом:
TASK: [flyway | run flywayMigrate] ********************************************
<db.server> REMOTE_MODULE command gradle -b /opt/product/rc/flyway-17.5.32.37534.d2bac4a/extracted/flyway.gradle flywayMigrate
failed: [db.server] => {"failed": true, "parsed": false}
invalid output was: SUDO-SUCCESS-plqsdlxwlfkdsujlxdafldpasvtllis
Включен ли MySQL с каким-то протоколом? Скорее всего, это будет binlog для репликации/инкрементного резервного копирования. Если да, проверьте журналы MySQL (например, для binlog используйте утилиту mysqlbinlog для их сброса) и попытайтесь понять, что делает MySQL в это время. Обратите внимание, что binlog будет регистрировать только те обновления, которые на самом деле что-то изменили, поэтому это не даст вам полную картину, но может дать некоторые подсказки. –
спасибо за подсказку. Поскольку это произошло только на нашем производственном сервере, я фактически не имею к нему доступа (заблокирован для обеспечения безопасности). Сценарий преуспел в нашей среде CERT, к которой у меня есть доступ, так что это не хорошо. Я могу заставить кого-то войти в производство, но это удивительно сложно ха-ха. – gnomed