Liquibaseロック-理由？

Oracleサーバーに対して多数のliquibaseスクリプトを実行すると、これが発生します。SomeComputerは私です。

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)

同時セッション/トランザクションの数に達している可能性がありますか？誰かがアイデアを持っていますか？

更新アプリケーションが突然停止した場合、ロックがスタックしたままになることがあります。

その後、実行

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

データベースに役立ちます。

または、単にDATABASECHANGELOGLOCKテーブルを削除して、再作成することもできます。

2020年6月の編集

このアドバイスに従わないでください。それは長年にわたって多くの人々にトラブルを引き起こしています。それはずっと前に私のために働き、私はそれを誠実に投稿しましたが、明らかにそれを行う方法ではありません。DATABASECHANGELOCKテーブルにはデータを含める必要があるため、テーブルからすべてを削除することはお勧めできません。

たとえば、Leos Literakはこれらの指示に従い、サーバーは起動に失敗しました。

元の答え

強制終了したliquibaseプロセスがDATABASECHANGELOGLOCKテーブルのロックを解放していないことが原因である可能性があります。そして、

DELETE FROM DATABASECHANGELOGLOCK;

あなたを助けるかもしれません。

編集： @Adrian Berの答えはこれよりも良い解決策を提供します。これを行うのは、彼の解決策の実行に問題がある場合のみです。

問題は、LiquibaseのSequenceExistsのバグのある実装でした。これらのステートメントを含むチェンジセットは非常に長い時間がかかり、誤って中止されたためです。次に、ロックが保持されていたliquibase-scriptsを実行してみます。

  <changeSet author="user" id="123">
    <preConditions onFail="CONTINUE">
      <not><sequenceExists sequenceName="SEQUENCE_NAME_SEQ" /></not>
    </preConditions>
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/>
  </changeSet>

回避策は、代わりにプレーンSQLを使用してこれをチェックすることです。

  <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>

LockdataはテーブルDATABASECHANGELOCKに格納されます。ロックを取り除くには、1を0に変更するか、そのテーブルを削除して再作成します。

Liquibaseの実行に使用される環境については言及されていません。Spring Boot 2の場合はliquibase.lockservice.StandardLockService、直接SQLステートメントを実行する必要なしに拡張できるため、よりクリーンになります。例えば：

/**
 * 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();
    }
}

コードはロックの解放を強制しています。これは、エラーが発生した場合やデバッグが中止された場合にリリース呼び出しが呼び出されない可能性があるテスト設定で役立ちます。

クラスはliquibase.extパッケージ内に配置する必要があり、Spring Boot 2自動構成によってピックアップされます。

テーブルDATABASECHANGELOGLOCKの切り捨てまたは削除が機能しない場合があります。私はPostgreSQLデータベースを使用していて、この問題に何度も遭遇しました。私が解決することは、そのデータベースのバックグラウンドで実行されている準備済みステートメントをロールバックすることです。準備されたすべてのステートメントをロールバックして、リキベースの変更を再試行してください。

SQL：

SELECT gid FROM pg_prepared_xacts WHERE database='database_name';

上記のステートメントがレコードを返す場合、次のSQLステートメントを使用してその準備済みステートメントをロールバックします。

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';

手動またはクエリを使用して、テーブルを安全に削除できます。自動的に再作成されます。

DROP TABLE DATABASECHANGELOGLOCK;

これがOPの問題ではなかったことに感謝しますが、最近、別の原因でこの問題に遭遇しました。参考までに、SQL ServerでLiquibase Mavenプラグイン（liquibase-maven-plugin：3.1.1）を使用していました。

とにかく、データベースを切り替えるスクリプトの1つに誤ってSQL Serverの "use"ステートメントをコピーして貼り付けたため、liquibaseがを実行してを更新DATABASECHANGELOGLOCKし、正しいデータベースでロックを取得しましたが、データベースを切り替えて変更を適用しました。正しいデータベースで変更やリキベースの監査を確認できなかっただけでなく、もちろん、リキベースを再度実行したときに、ロックを取得できませんでした。ロックが「間違った」データベースで解放されたためです。 「正しい」データベースでまだロックされています。ロックを解除する前にliquibaseがロックがまだ適用されていることを確認することを期待していましたが、それはliquibaseのバグ（まだ確認していません）かもしれませんが、それ以降のバージョンでは対処できる可能性があります！とはいえ、機能と見なすことができると思います！

かなりの男子生徒のエラーですが、同じ問題が発生した場合に備えて、ここで発生させます。