A lot of questions in here - I'll try to answer as best I can.
The second way to do it is using the built in releaseLocks command, which is available as a maven goal: https://www.liquibase.org/documentation/maven/maven_releaselocks.html
Steve Donie
Principal Software Engineer
Liquibase Community Engagement
Datical, Inc. http://www.datical.com/
The first issue with the databasechangeloglock - this sometimes happens when an update operation is interrupted. There are two ways to unlock it - one is using SQL directly in whatever SQL tool you use, and to run "
UPDATE DATABASECHANGELOGLOCK SET LOCKED=0" This is described a bit more in the documentation at https://www.liquibase.org/documentation/databasechangeloglock_table.htmlThe second way to do it is using the built in releaseLocks command, which is available as a maven goal: https://www.liquibase.org/documentation/maven/maven_releaselocks.html
Next issue -you mention that you think the commands are failing because the checksums are not correct - that may also be the case, but it is unrelated to the lock. If the error mentions something about the lock, then that is your issue, but if the error message mentions checksums, then that is the issue.
In all cases, when asking for help, including the error message makes it easier to provide assistance.
So, if you are having issues with the checksums, the first thing to remember is that after a changeset is deployed to a database, you should never change that changeset in the changelog again, unless you want to get into a manual fix process. If you deploy a changeset to a database, and then discover that there is something wrong with that changeset, your options are either to roll back that changeset in all environments where it has been deployed, alter the changeset, and then re-deploy, or else write a new changeset that fixes the issue with the first changeset.
It sounds like you think there are checksum issues, but make sure that is the case before moving forward.
You can use the clearChecksums command, but that is kind of like pulling the ejection seat. What that does is update every row in the databasechangelog table, setting the md5sum column to null. If you do an update after, it will re-save the checksums of all ran changeSets AND run any new changeSets like normal. The big edge-case that can trip people up is that since the checksum logic is disabled, any previously ran changeSets with runOnChange=true will NOT be re-run.
It also sounds like you have other issues - people hvae changed the ddatabase manually, and now the changelog doesn't match the actual state of the database. In that case, you should be able to use the diffChangelog command to compare two databases (one that has NOT been manually modified and one that has) and add any necessary changes to your changelog, which you can then mark as 'deployed' in the manually modified database using the changeLogSync command.
If you have any further questions, please reply here with more details and I'll do my best to help.
Steve Donie
Principal Software Engineer
Liquibase Community Engagement
Datical, Inc. http://www.datical.com/