Likibaz kilidi - nedenleri?

Bir Oracle sunucusuna karşı çok sayıda liquibase-script çalıştırırken bunu alıyorum. BazıBilgisayar benim.

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)

Eşzamanlı oturum / işlem sayısına ulaşılmış olabilir mi? Herhangi bir fikri olan var mı?

Bazen güncelleme uygulaması aniden durdurulursa, kilit takılı kalır.

Sonra koşuyor

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

veritabanı karşı yardımcı olur.

Ya da sadece DATABASECHANGELOGLOCKmasayı bırakabilirsiniz, yeniden oluşturulacaktır.

Haziran 2020'yi düzenle

Bu tavsiyelere uymayın. Yıllar boyunca birçok insan için sorun yarattı. Uzun zaman önce benim için çalıştı ve iyi niyetle yayınladım, ama açıkça yapmanın yolu bu değil. DATABASECHANGELOCK tablosunun içinde bir şeyler olması gerekir, bu yüzden sadece her şeyi ondan silmek kötü bir fikirdir.

Örneğin Leos Literak bu talimatları izledi ve sunucu başlatılamadı.

Orijinal cevap

Muhtemelen DATABASECHANGELOGLOCK tablosundaki kilidini serbest bırakmayan öldürülmüş bir likibaz işleminden kaynaklanmaktadır. Sonra,

DELETE FROM DATABASECHANGELOGLOCK;

size yardımcı olabilir.

Edit: @Adrian Ber'in cevabı bundan daha iyi bir çözüm sunuyor. Bunu ancak çözümünü yaparken herhangi bir sorun yaşarsanız yapın.

Sorun, Liquibase'deki SequenceExists'in buggy uygulamasıydı. Bu ifadelerle yapılan değişiklik setleri çok uzun zaman aldığından ve yanlışlıkla iptal edildi. Daha sonra kilidin tutulduğu likibaz betikleri çalıştırmayı deneyin.

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

Bu soruna geçici bir çözüm, bunu denetlemek için düz SQL kullanıyor:

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

Kilit verileri DATABASECHANGELOCK tablosunda saklanır. Kilitten kurtulmak için sadece 1'den 0'a değiştirirsiniz veya o masayı düşürüp yeniden yaratırsınız.

Likibazın yürütülmesi için hangi ortamın kullanıldığı belirtilmemiştir. Spring Boot 2 olması durumunda liquibase.lockservice.StandardLockService, daha temiz olan doğrudan SQL ifadeleri çalıştırmaya gerek kalmadan genişletmek mümkündür . Örneğin:

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

Kod kilidin serbest bırakılmasını zorunlu kılıyor. Bu, hata durumunda yayın çağrısının çağrılmayabileceği test kurulumlarında veya hata ayıklama iptal edildiğinde faydalı olabilir.

Sınıf liquibase.extpakete konulmalıdır ve Spring Boot 2 otomatik yapılandırması tarafından alınacaktır.

Bazen DATABASECHANGELOGLOCK tablosunun kesilmesi veya düşürülmesi işe yaramaz. PostgreSQL veritabanını kullanıyorum ve bu sorunla pek çok kez karşılaştım. Çözmek için yaptığım bu veritabanı için arka planda çalışan hazırlanan ifadeleri geri almaktır. Hazırlanan tüm ifadeleri geri almayı deneyin ve likibaz değişikliklerini tekrar deneyin.

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database='database_name';

Yukarıdaki ifade herhangi bir kayıt döndürürse, bu hazırlanan ifadeyi aşağıdaki SQL ifadesiyle geri alın.

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';

Tabloyu manuel olarak veya sorguyu kullanarak güvenle silebilirsiniz. Otomatik olarak yeniden oluşturulur.

DROP TABLE DATABASECHANGELOGLOCK;

Bunun OP'nin sorunu olmadığını takdir ediyorum, ancak son zamanlarda farklı bir nedenden dolayı bu sorunla karşılaştım. Referans olarak, SQL Server ile Liquibase Maven eklentisini (liquibase-maven-plugin: 3.1.1) kullanıyordum.

Her neyse, yanlışlıkla bir SQL Server "use" deyimini veritabanlarımı değiştiren komut dosyalarımızdan birine yapıştırdım, böylece liquibase çalışıyor ve güncelleniyor DATABASECHANGELOGLOCK , kilidi doğru veritabanında elde ediyor, ancak değişiklikleri uygulamak için veritabanlarını değiştiriyordu. Değişikliklerimi veya likibaz denetimimi doğru veritabanında göremiyorum, ama elbette, likibazı tekrar çalıştırdığımda, kilit "yanlış" veritabanında serbest bırakıldığı için kilidi alamadı. hala "doğru" veritabanında kilitli. Kilidin serbest bırakılmadan önce hala uygulandığını kontrol etmek için likibaz beklerdim ve belki de bu likibazda bir hata (henüz kontrol etmedim), ancak daha sonraki sürümlerde de ele alınabilir! Bununla birlikte, sanırım bir özellik olarak düşünülebilir!

Biraz okul çocuğu hatası, biliyorum, ama aynı problemle karşılaşması durumunda burada ortaya çıkarıyorum!