What purpose does DATABASECHANGELOCK serve?

What purpose does DATABASECHANGELOCK serve?

The reason a databasechangeloglock is important is that it ensures that the database is not in a bad state.

This record is inserted under 2 scenarios:

    1. Yellowfin start-up process.

This is when Yellowfin checks the DB schema vs code version to ensure additional scripts are not needed to run.

The row is cleared on successful startup.

    2. Upgrade process.

This is to ensure nothing else is trying to write to the database during the upgrade it is cleared post upgrade.

How do I determine I'm being affected by a DATABASECHANGELOCK issue?

If facing an issue on startup, you will see something along these lines this in the yellowfin.log;

  liquibase.exception.LockException:
Could not acquire change log lock. Currently locked by yellowfin-7445b95844-j2642  
(10.104.31.144) since 5/12/19, 12:27 AM at liquibase.lockservice.StandardLockService.waitForLock(StandardLockService.java:190)

 liquibase.exception.LockException:
Could not acquire change log lock. Currently locked by yellowfin-7445b95844-j2642     (10.104.31.144) since 5/12/19, 12:27 AM

You can also check for a lock by executing the following query against your configuration database:

    SELECT * FROM DATABASECHANGELOGLOCK

The query result will be something like:

Will Yellowfin remove this flag prior to upgrading?

No. Based on the above there could be a valid reason why the row is there and will need to be addressed. For example, if start-up failed, don't bother trying to upgrade as YF doesn't actually work.

If the upgrade failed, running it a second time will most likely run into the same issue, until upgrade issue has been resolved.

Can this flag be removed prior to running an upgrade? 

Sure. Though keep in mind it's worth looking at the above scenarios to ensure you don't run into the same issue.

If in a clustered environment, you will also need to make sure that you don't have any nodes starting before running the upgrade, because if this does happen, you will face DB corruption issues, as there will be nothing stopping the updater and start up process to modify the same records.

So if you wanted to remove this row prior to upgrading, you can, though please ensure you have also looked into why the flag was there in the first place;

1. Was there a previous failed upgrade. Has that been resolved prior to upgrading again?
2. Do you have any stuck nodes in the start-up process?