Provide more information why DATABASECHANGELOGLOCK was inserted

Tarun Pandey shared this idea 18 months ago
Idea Logged

Can we please get additional information inserted when DATABASECHANGELOGLOCK is put in the DB.

For example ;

-Process that inserted the row (start-up/upgrade)

-Where it came from (local/node2)

-Timestamp of insertion

Right now, when Yellowfin starts up, or runs an upgrade, the DATABASECHANGELOGLOCK row is inserted to ensure there dupe processes are not trying to update the DB. This will then be removed post start-up or upgrade. This is good.

However.. in cases of failed startups and upgrades, that DATABASECHANGELOGLOCK row will not remove. Yes there are underlying reasons for this, but it's near impossible to identify if that record was inserted due to a bad node 3 months ago.

Comments (2)

photo
1

Hey Tarun I've officially logged this in our system for future review, I too agree this should be something worth implementing in order to help us better understand why this record got inserted so we don't remove it blindly before upgrading.


I'll keep you posted on any future updates.


Regards,

David

photo
1

Hi David,

We are seeing same issue in our container environment due to sudden restart of SR POD. Now, due to this lock, POD is not getting restarted automatically. Thanks!

photo
1

Thanks for the feedback Manish. You're going to have to remove these rows in these scenarios, and see if you can dig a bit deeper into understanding how they got there in the first place. They should only be stuck rows when something goes wrong, e.g. Failed startup, so I suspect those failed startups can be captured and trigger the removal of the record.


In any case we will keep you posted on further updates.


Regards,David

photo