blocks|key|353398|text|问题在于Liquibase中SequenceExists的错误实现。因为使用这些语句的变更集花费了很长时间，并且被意外中止。然后，下一次尝试执行liquibase+scripts时，锁就被持有了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353399|++<changeSet+author="user"+id="123">
++++<preConditions+onFail="CONTINUE">
++++++<not><sequenceExists+sequenceName="SEQUENCE_NAME_SEQ"+/></not>
++++</preConditions>
++++<createSequence+sequenceName="SEQUENCE_NAME_SEQ"/>
++</changeSet>|code-block|syntax|javascript|353400|一种解决方法是使用普通SQL来检查：|353401|++<changeSet+author="user"+id="123">
++++<preConditions+onFail="CONTINUE">
++++++++++++<sqlCheck+expectedResult="0">
++++++++++++++select+count(*)+from+user_sequences+where+sequence_name+=+'SEQUENCE_NAME_SEQ';
++++++++++++</sqlCheck>
++++</preConditions>
++++<createSequence+sequenceName="SEQUENCE_NAME_SEQ"/>
++</changeSet>|353402|Lockdata存储在表DATABASECHANGELOCK中。要解除锁定，只需将1更改为0，或者删除该表并重新创建。|353403|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

The problem was the buggy implementation of SequenceExists in Liquibase. Since the changesets with these statements took a very long time and was accidently aborted. Then the next try executing the liquibase-scripts the lock was held.

<pre><code> &lt;changeSet author="user" id="123"&gt;
 &lt;preConditions onFail="CONTINUE"&gt;
 &lt;not&gt;&lt;sequenceExists sequenceName="SEQUENCE_NAME_SEQ" /&gt;&lt;/not&gt;
 &lt;/preConditions&gt;
 &lt;createSequence sequenceName="SEQUENCE_NAME_SEQ"/&gt;
 &lt;/changeSet&gt;
</code></pre>

A work around is using plain SQL to check this instead:

<pre><code> &lt;changeSet author="user" id="123"&gt;
 &lt;preConditions onFail="CONTINUE"&gt;
 &lt;sqlCheck expectedResult="0"&gt;
 select count(*) from user_sequences where sequence_name = 'SEQUENCE_NAME_SEQ';
 &lt;/sqlCheck&gt;
 &lt;/preConditions&gt;
 &lt;createSequence sequenceName="SEQUENCE_NAME_SEQ"/&gt;
 &lt;/changeSet&gt;
</code></pre>

Lockdata is stored in the table DATABASECHANGELOCK. To get rid of the lock you just change 1 to 0 or drop that table and recreate.

blocks|key|135615|text|有时，如果更新应用程序突然停止，则锁仍然卡住。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|135616|然后运行|135617|UPDATE+DATABASECHANGELOGLOCK+SET+LOCKED=0,+LOCKGRANTED=null,+LOCKEDBY=null+where+ID=1;|code-block|syntax|javascript|135618|对数据库有帮助。|135619|您可能还需要用LOCKED=FALSE替换LOCKED=0。|offset|length|style|CODE|135620|或者您可以简单地删除DATABASECHANGELOGLOCK表，它将被重新创建。|135621|entityMap^0|0|0|0|0|7|C|L|8|0|A|L|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]|$M|11|N|12|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@$M|14|N|15|O|P]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|T|$]]

Sometimes if the update application is abruptly stopped, then the lock remains stuck.
Then running
<pre class="lang-sql prettyprint-override"><code>UPDATE DATABASECHANGELOGLOCK SET LOCKED=0, LOCKGRANTED=null, LOCKEDBY=null where ID=1;
</code></pre>
against the database helps.
You may also need to replace <code>LOCKED=0</code> with <code>LOCKED=FALSE</code>.
Or you can simply drop the <code>DATABASECHANGELOGLOCK</code> table, it will be recreated.

blocks|key|135681|text|我很感谢这不是OP的问题，但我最近遇到了这个问题，原因不同。作为参考，我在SQL+Server中使用了Liquibase+Maven插件(liquibase+maven-+plugin+:3.1.1)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|135682|无论如何，我错误地将SQL+Server+"use“语句复制并粘贴到我的一个切换数据库的脚本中，因此，liquibase正在运行并更新DATABASECHANGELOGLOCK，获取正确数据库中的锁，然后切换数据库以应用更改。我不仅在正确的数据库中看不到我的更改或liquibase审计，而且当然，当我再次运行liquibase时，它无法获得锁，因为锁已经在“错误的”数据库中被释放，因此仍然被锁定在“正确的”数据库中。我本以为liquibase会在释放锁之前检查锁是否还在应用，也许这是liquibase中的一个bug+(我还没有检查过)，但它很可能会在以后的版本中得到解决！也就是说，我认为它可以被认为是一个特性！|offset|length|style|CODE|135683|我知道这是一个相当幼稚的错误，但我在这里提出它，以防有人遇到同样的问题！|135684|entityMap^0|0|1V|L|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

I appreciate this wasn't the OP's issue, but I ran into this issue recently with a different cause. For reference, I was using the Liquibase Maven plugin (liquibase-maven-plugin:3.1.1) with SQL Server.

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 <code>DATABASECHANGELOGLOCK</code>, 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!

Quite a bit of a schoolboy error, I know, but I raise it here in case anyone runs into the same problem!

blocks|key|353568|text|有时截断或删除表DATABASECHANGELOGLOCK不起作用。我使用的是PostgreSQL数据库，遇到过很多次这个问题。我要解决的问题是回滚在后台为该数据库运行的准备好的语句。尝试回滚所有准备好的语句，然后再次尝试更改liquibase。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353569|SQL：|353570|SELECT+gid+FROM+pg_prepared_xacts+WHERE+database='database_name';|code-block|syntax|javascript|353571|如果上述语句返回任何记录，则使用以下SQL语句回滚该预准备语句。|353572|ROLLBACK+PREPARED+'gid_obtained_from_above_SQL';|353573|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

Sometimes truncating or dropping the table DATABASECHANGELOGLOCK doesn't work. I use PostgreSQL database and came across this issue a lot of times. What I do for solving is to rollback the prepared statements running in background for that database. Try to rollback all the prepared statements and try the liquibase changes again.

SQL:

<pre><code>SELECT gid FROM pg_prepared_xacts WHERE database='database_name';
</code></pre>

If above statement returns any record, then rollback that prepared statement with following SQL statement.

<pre><code>ROLLBACK PREPARED 'gid_obtained_from_above_SQL';
</code></pre>

blocks|key|353623|text|没有提到使用哪个环境来执行Liquibase。如果是Spring+Boot2，则可以扩展liquibase.lockservice.StandardLockService而不需要运行直接的SQL语句，这要干净得多。例如：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|353624|/**
+*+This+class+is+enforcing+to+release+the+lock+from+the+database.
+*
+*/
+public+class+ForceReleaseLockService+extends+StandardLockService+{

++++@Override
++++public+int+getPriority()+{
++++++++return+super.getPriority()%2B1;
++++}

++++@Override
++++public+void+waitForLock()+throws+LockException+{
++++++++try+{
++++++++++++super.forceReleaseLock();
++++++++}+catch+(DatabaseException+e)+{
++++++++++++throw+new+LockException("Could+not+enforce+getting+the+lock.",+e);
++++++++}
++++++++super.waitForLock();
++++}
}|code-block|syntax|javascript|353625|代码强制释放锁。这在测试设置中很有用，在这种设置中，在出现错误或调试中止时可能不会调用release调用。|353626|该类必须放在liquibase.ext包中，并将由Spring+Boot2自动配置获取。|353627|entityMap^0|18|15|0|0|0|6|D|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|P|$]]

It is not mentioned which environment is used for executing Liquibase. In case it is Spring Boot 2 it is possible to extend <code>liquibase.lockservice.StandardLockService</code> without the need to run direct SQL statements which is much cleaner. E.g.:

<pre><code>/**
 * This class is enforcing to release the lock from the database.
 *
 */
 public class ForceReleaseLockService extends StandardLockService {

 @Override
 public int getPriority() {
 return super.getPriority()+1;
 }

 @Override
 public void waitForLock() throws LockException {
 try {
 super.forceReleaseLock();
 } catch (DatabaseException e) {
 throw new LockException("Could not enforce getting the lock.", e);
 }
 super.waitForLock();
 }
}
</code></pre>

The code is enforcing the release of the lock. This can be useful in test set-ups where the release call might not get called in case of errors or when the debugging is aborted.

The class must be placed in the <code>liquibase.ext</code> package and will be picked up by the Spring Boot 2 auto configuration.

blocks|key|135859|text|您可以安全地手动或使用查询删除该表。它将被自动重新创建。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|135860|DROP+TABLE+DATABASECHANGELOGLOCK;|code-block|syntax|javascript|135861|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You can safely delete the table manually or using query. It will be recreated automatically.

<pre><code>DROP TABLE DATABASECHANGELOGLOCK;
</code></pre>

blocks|key|353704|text|请让Liquibase处理自己的表。正如user1434769提到的，正确的做法是使用Liquibase的releaseLocks命令。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353705|当使用Gradle时，这将是：gradlew+releaseLocks|offset|length|style|CODE|353706|entityMap^0|0|F|K|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Please let Liquibase handle its own tables. The correct thing to do, as user1434769 mentions, is to use Liquibase's releaseLocks command.
When using Gradle, this would be: <code>gradlew releaseLocks</code>

blocks|key|353741|text|如果@Adrian发布的解决方案不起作用，您可以尝试在包含有关锁的附加信息的INTERFACE_DATABASECHANGELOGLOCK表中执行相同的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353742|UPDATE+INTERFACE_DATABASECHANGELOGLOCK+SET+LOCKED=0,+LOCKGRANTED=null,+LOCKEDBY=null+where+ID=1;|code-block|syntax|javascript|353743|或者干脆清空桌子|353744|TRUNCATE+TABLE+INTERFACE_DATABASECHANGELOGLOCK|353745|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

If the solution posted by @Adrian didn't work, you may try to do the same in the table INTERFACE_DATABASECHANGELOGLOCK which contains additional informations regarding the lock.
<pre><code>UPDATE INTERFACE_DATABASECHANGELOGLOCK SET LOCKED=0, LOCKGRANTED=null, LOCKEDBY=null where ID=1;
</code></pre>
or simply clear the table
<pre><code>TRUNCATE TABLE INTERFACE_DATABASECHANGELOGLOCK
</code></pre>

blocks|key|353801|text|我以前曾在失败后锁仍然存在的情况下截断了DatabaseChangeLogLock表(这通常仍然适用于我)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353802|然而，这个项目(https://github.com/blagerweij/liquibase-sessionlock)现在存在了，它在使用Oracle、PostgreSQL和MySQL时使用本地数据库会话锁来锁定Liquibase。|offset|length|353803|JAR文件可以放到现有的Liquibase+4.x%2B应用程序中，Liquibase会自动检测到它。这将使用会话锁进行锁定..如果应用程序崩溃或在锁被持有的同时被关闭，则自动释放该锁。这可能会阻止锁定状态的发生(如果您使用的是受支持的数据库)|353804|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/blagerweij/liquibase-sessionlock^0|0|8|1F|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

I have previously just truncated the DatabaseChangeLogLock table when a lock remained after failure (and this generally still works for me).
However, this project (<a href="https://github.com/blagerweij/liquibase-sessionlock" rel="nofollow noreferrer">https://github.com/blagerweij/liquibase-sessionlock</a>) now exists, which uses native database session locks for locking Liquibase when using Oracle, PostgreSQL and MySQL.
The JAR file can be dropped into an existing Liquibase 4.x+ application, and will be automatically detected by Liquibase. This will use session locks for locking.. which are automatically released if the application crashes or is shutdown whilst the lock is held. This will potentially stop the locked state from occuring (if you are using one of the supported databases)

I get this when running a lot of liquibase-scripts against a Oracle-server. SomeComputer is me.

<pre class="lang-none prettyprint-override"><code>Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Liquibase Update Failed: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
SEVERE 2013-03-20 16:59:liquibase: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
liquibase.exception.LockException: Could not acquire change log lock. Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
 at liquibase.lockservice.LockService.waitForLock(LockService.java:81)
 at liquibase.Liquibase.tag(Liquibase.java:507)
 at liquibase.integration.commandline.Main.doMigration(Main.java:643)
 at liquibase.integration.commandline.Main.main(Main.java:116)
</code></pre>

Could it be that the number of simultaneous sessions/transactions are reached? Anyone has any ideas?

Liquibase lock - reasons?

SQL数据库

Spring Boot

SQL Server

PostgreSQL

数据库

服务器

MySQL

当我在Oracle服务器上运行大量的liquibase脚本时，我得到了这个问题。SomeComputer就是我。Waiting for changelog lock....Waiting for changelog lock....Waiting for changelog lock....Waiting for ch...

问Liquibase锁-原因？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Liquibase锁-原因？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Liquibase锁-原因？
EN