database changelog - Blocco Liquibase - ragioni?





changeset runonchange (6)


Probabilmente è a causa di un processo di liquibase ucciso che non ha rilasciato il blocco sulla tabella DATABASECHANGELOGLOCK. Poi,

DELETE FROM DATABASECHANGELOGLOCK;

potrebbe aiutarti.

Modifica: @Adrian Ber's answer fornisce una soluzione migliore di questa. Fallo solo se hai problemi a fare la sua soluzione.

Ottengo questo quando eseguo un sacco di script di liquibase contro un server Oracle. SomeComputer sono io.

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)

Potrebbe essere che il numero di sessioni / transazioni simultanee sia raggiunto? Qualcuno ha qualche idea?




Apprezzo che questo non fosse il problema dell'OP, ma di recente ho riscontrato questo problema con una causa diversa. Per riferimento, stavo usando il plugin Liquibase Maven (liquibase-maven-plugin: 3.1.1) con SQL Server.

Ad ogni modo, avevo erroneamente copiato e incollato un'istruzione "uso" di SQL Server in uno dei miei script che cambiava i database, quindi liquibase era in esecuzione e aggiornava DATABASECHANGELOGLOCK , acquisendo il blocco nel database corretto, ma poi cambiando i database per applicare le modifiche . Non solo non potevo vedere le mie modifiche o l'audit di liquibase nel database corretto, ma naturalmente, quando ho eseguito nuovamente il liquibase, non è stato possibile acquisire il blocco, poiché il blocco era stato rilasciato nel database "errato", e così è stato ancora bloccato nel database "corretto". Mi sarei aspettato che il liquibase verificasse che il lucchetto fosse ancora applicato prima di rilasciarlo, e forse questo è un bug in liquibase (non ho ancora controllato), ma potrebbe essere risolto nelle versioni successive! Detto questo, suppongo che potrebbe essere considerato una caratteristica!

Un po 'un errore da scolaro, lo so, ma lo sollevo qui nel caso qualcuno si imbatta nello stesso problema!




A volte, se l'applicazione di aggiornamento viene interrotta improvvisamente, il blocco rimane bloccato.

Quindi correre

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

contro il database aiuta.

Oppure puoi semplicemente rilasciare la tabella DATABASECHANGELOGLOCK , verrà ricreata.




Il problema era l'implementazione buggy di SequenceExists in Liquibase. Poiché i changeset con queste affermazioni sono durati molto tempo e sono stati interrotti accidentalmente. Poi il prossimo tentativo di eseguire gli script di liquibase è stato tenuto il blocco.

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

Una soluzione è l'utilizzo di SQL semplice per controllare invece:

  <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 è memorizzato nella tabella DATABASECHANGELOCK. Per sbarazzarti del lucchetto basta cambiare da 1 a 0 o rilasciare quel tavolo e ricrearlo.




A volte il troncamento o il rilascio della tabella DATABASECHANGELOGLOCK non funziona. Io uso il database PostgreSQL e ho trovato questo problema un sacco di volte. Quello che faccio per risolvere è il rollback delle istruzioni preparate in esecuzione in background per quel database. Prova a eseguire il rollback di tutte le istruzioni preparate e prova di nuovo le modifiche di liquibase.

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database='database_name';

Se l'istruzione precedente restituisce alcun record, quindi rollback quella istruzione preparata con la seguente istruzione SQL.

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';



Questo bug esiste in tutte le versioni di MySQL Workbench oltre 6.0 (in questo momento: 6.1, 6.2 e 6.3 hanno il bug).

Downgrade a MySQL Workbench 6.0.x sembra l'unico modo per risolvere questo problema.

Scarica MySQL Workbench 6.0.x: http://dev.mysql.com/downloads/workbench/6.0.html





database oracle liquibase