database - transaction - Cerradura de Liquibase-¿razones?

liquibase runonchange true

Question

Lo entiendo cuando ejecuto muchas secuencias de comandos liquibase contra un servidor Oracle. SomeComputer soy yo.

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)

¿Podría ser que se alcanza el número de sesiones / transacciones simultáneas? Alguien tiene alguna idea?

Answer 1

A veces, truncar o soltar la tabla DATABASECHANGELOGLOCK no funciona. Uso la base de datos PostgreSQL y me encontré con este problema muchas veces. Lo que hago para resolver es deshacer las declaraciones preparadas que se ejecutan en segundo plano para esa base de datos. Intente deshacer todas las declaraciones preparadas y pruebe los cambios de liquibato nuevamente.

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database=''database_name'';

Si la instrucción anterior devuelve un registro, entonces deshaga esa declaración preparada con la siguiente instrucción SQL.

ROLLBACK PREPARED ''gid_obtained_from_above_SQL'';

Answer 2

Agradezco que este no fuera el problema del OP, pero me encontré con este problema recientemente con una causa diferente. Como referencia, estaba usando el complemento Liquibase Maven (liquibase-maven-plugin: 3.1.1) con SQL Server.

De todos modos, había copiado y pegado erróneamente una declaración de "uso" de SQL Server en uno de mis scripts que cambia bases de datos, así que liquibase se estaba ejecutando y actualizando el DATABASECHANGELOGLOCK , adquiriendo el bloqueo en la base de datos correcta, pero cambiando bases de datos para aplicar los cambios . No solo no podía ver mis cambios o liquidar la auditoría en la base de datos correcta, sino que, por supuesto, cuando ejecuté liquibase nuevamente, no pude adquirir el bloqueo, ya que el bloqueo se había liberado en la base de datos "incorrecta", y también aún bloqueado en la base de datos "correcta". Esperaba que liquibase comprobara que el bloqueo todavía se aplicaba antes de liberarlo, y tal vez eso es un error en liquibase (aún no lo he comprobado), ¡pero podría ser abordado en versiones posteriores! Dicho eso, ¡supongo que podría considerarse una característica!

Creo que es un pequeño error de colegial, pero lo planteo aquí en caso de que alguien tenga el mismo problema.

Answer 3

El problema fue la implementación defectuosa de SequenceExists en Liquibase. Dado que los conjuntos de cambios con estas declaraciones tomaron mucho tiempo y fueron abortados accidentalmente. Luego, el siguiente intento de ejecutar los scripts de liquibase, se realizó el bloqueo.

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

Un trabajo alternativo es usar SQL simple para verificar esto en su lugar:

  <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 se almacena en la tabla DATABASECHANGELOCK. Para deshacerse de la cerradura, simplemente cambie de 1 a 0 o suelte esa tabla y vuelva a crearla.

Answer 4

En ocasiones, si la aplicación de actualización se detiene bruscamente, el bloqueo permanece bloqueado.

Luego corriendo

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

contra la base de datos ayuda.

O simplemente puede soltar la tabla DATABASECHANGELOGLOCK , se volverá a crear.

Answer 5

Posiblemente se debe a un proceso de liquibase muerto que no libera su bloqueo en la tabla DATABASECHANGELOGLOCK. Entonces,

DELETE FROM DATABASECHANGELOGLOCK;

podría ayudarte

Editar: @Adrian La respuesta de Ber proporciona una mejor solución que esta. Solo haz esto si tienes problemas para resolverlo.