Options
Log overload from debugging Flyway Maven plugin
eko_joseph
Posts: 3 New member
Hi!
We recently have been dealing with lock wait
timeouts in our deploys when the Flyway Maven plugin tries to acquire a
lock. We have since passed in the debug flag (-X) to help understand the
issue better.
However, on our most recent
deploy (with no migrations) we received a huge text blob in our build
logs that appears to be our baseline in S3. This caused our deploy to
time out as printing the entire baseline to console took 1.5hrs and 5Gb
of log space.
We would like to continue having the debug flag on as there was good data in the 5Gb, but the baseline printout is unacceptable.
My questions are these:
What HTTP data is outgoing at this point when the S3 .sql file is being printed out? Where is it going? My original interpretation was that the baseline was being re-run on our DB. My new interpretation is that migration is actually being received locally by an outgoing HTTP request.
What HTTP data is outgoing at this point when the S3 .sql file is being printed out? Where is it going? My original interpretation was that the baseline was being re-run on our DB. My new interpretation is that migration is actually being received locally by an outgoing HTTP request.
Is it possible to send in other
flags to not print out the contents of the SQL migrations? This S3
migrations seems to be the only one that causes it (and is the only S3
migration we have.)
Example lines:
[07:02:58] : [Step 4/6] [DEBUG] http-outgoing-1 >> GET /V1__our_db_baseline.sql HTTP/1.1
Example lines:
[07:02:58] : [Step 4/6] [DEBUG] http-outgoing-1 >> GET /V1__our_db_baseline.sql HTTP/1.1
[08:28:25] : [Step 4/6] [DEBUG] http-outgoing-5 << "-- Dump completed on 2022-11-04 8:19:53[\r][\n]"
Answers
Hi @eko_joseph
Thank you for reaching out on the Redgate forums regarding your logging inquiry.
Doing some checks with the
<b>-q</b>(--quiet) tag it does appear to suppress the debug logging which may not be optimal for your usage as you would ideally just remove the -X flag and revert to a standard output. It may be possible to test usage of -q in your process to see if it works.Outside this it may be possibly to manually build and configure a logger with SLF4J.
There's documentation on configuring a logger here, but you'd need to source any transitive dependencies yourselves.
Flyway automatically chooses its logger and you can define it manually to use SLF4J as logger using this conf setting:<i>flyway.loggers=slf4j2</i>Then using Logback as an example, you can configure the log level in your logback.xml configuration for Flyway:
This configuration will set the log level for the Flyway logger to INFO, which should significantly reduce the amount of log output while still providing important information.