Liquibase uses the DATABASECHANGELOGLOCK table to ensure only one instance of Liquibase runs at a time. If the table does not exist in the database, Liquibase creates one automatically.
When you make a database update, Liquibase reads from the DATABASECHANGELOG table to determine which changesets need to run. To avoid conflicts between concurrent updates—which can happen if multiple developers use the same database instance or if multiple servers in a cluster auto-run Liquibase on startup—the DATABASECHANGELOGLOCK table sets the
LOCKED column to 1 when an update is currently running. If you make another update during this time, Liquibase waits until the lock releases before running it.
|Column||Standard data type||Description|
||INT||ID of the lock. There is currently only one lock.|
||INT||Set to "1" if Liquibase is running against this database. Otherwise set to "0"|
||DATETIME||Date and time that the lock was granted.|
||VARCHAR(255)||Human-readable description of who the lock was granted to.|
Note: If Liquibase does not exit cleanly, the lock row may be left as locked. You can clear out the current lock by running
liquibase release-locks which runs
UPDATE DATABASECHANGELOGLOCK SET LOCKED=0