您可以手动或使用query安全地删除表。它将被自动重新创建。

DROP TABLE DATABASECHANGELOGLOCK;

我知道这不是OP的问题，但我最近遇到了这个问题，原因不同。作为参考，我在SQL Server上使用了Liquibase Maven插件(Liquibase - Maven -plugin:3.1.1)。

Anyway, I'd erroneously copied and pasted a SQL Server "use" statement into one of my scripts that switches databases, so liquibase was running and updating the DATABASECHANGELOGLOCK, acquiring the lock in the correct database, but then switching databases to apply the changes. Not only could I NOT see my changes or liquibase audit in the correct database, but of course, when I ran liquibase again, it couldn't acquire the lock, as the lock had been released in the "wrong" database, and so was still locked in the "correct" database. I'd have expected liquibase to check the lock was still applied before releasing it, and maybe that is a bug in liquibase (I haven't checked yet), but it may well be addressed in later versions! That said, I suppose it could be considered a feature!

我知道，这是一个学生的错误，但我在这里提出这个问题，以防有人遇到同样的问题!

您可以手动或使用query安全地删除表。它将被自动重新创建。

DROP TABLE DATABASECHANGELOGLOCK;

有时，如果更新应用程序突然停止，那么锁仍然卡住。

然后运行

UPDATE DATABASECHANGELOGLOCK SET LOCKED=0, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

对数据库有帮助。

你可能还需要将LOCKED=0替换为LOCKED=FALSE。

或者您可以简单地删除DATABASECHANGELOGLOCK表，它将被重新创建。

有时截断或删除DATABASECHANGELOGLOCK表不起作用。我使用PostgreSQL数据库，遇到过这个问题很多次。我所做的解决方案是回滚在后台为该数据库运行的准备语句。尝试回滚所有准备好的语句，并再次尝试liqubase更改。

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database='database_name';

如果上面的语句返回任何记录，那么用下面的SQL语句回滚准备好的语句。

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';

2020年6月编辑

不要听从这个建议。多年来，它给许多人带来了麻烦。很久以前它就为我工作了，我真诚地发布了它，但显然不是这样做的方式。DATABASECHANGELOCK表中需要有内容，因此只删除其中的所有内容而不删除表是一个坏主意。

例如，Leos Literak执行了这些指令，但服务器无法启动。

原来的答案

这可能是由于一个被杀死的liqubase进程没有释放它在DATABASECHANGELOGLOCK表上的锁。然后,

DELETE FROM DATABASECHANGELOGLOCK;

也许能帮到你。

编辑:@Adrian Ber的回答提供了一个比这更好的解决方案。只有当你在解他的解时有问题时才这么做。