nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DR has left inconsistent state

Grant Fidler

Hi guys. A project to upgrade a 6.1 instance accidentally modified the schema on prod to 7.0 (but not the application code - someone forgot to update dbconfig.xml). The prod database was restored to previous best position, but we now have 3 old issues which seemingly still exist outside the database, but not in it. Consequently, the user who created the original issues (and still has them in his open issues) now sees different issues for 2 (i guess the issue numbers have been re-used) whilst the third says it cannot be opened and may have been deleted.

This all makes sense - i'm just wondering what the best way forward here is, in order to leave the application consistent etc. Whether the issues can be removed completely / entered with dud data and closed or something else.

Grateful for any help anyone can offer - this isn't my system and I'm not particularly enjoying the experience!

Regards,

Grant

Accepted answers

All comments

Alexis Robert

Hi @Grant Fidler ,

if you actually restored the database to its previous state, then all your data should be consistent as the issue data etc is only stored in the database.

Have you tried doing a full re-index ? This might only be a cache issue.

Let me know if this helps,

--Alexis

Grant Fidler

Thanks for the response, Alexis. I have indeed run a full re-index, but when I look at 'All Issues' for this particular project, I see duplicated issue numbers for the 3 problem numbers - 1917,1918,1919 (we cloned one of them to see if that changed what the user saw). I say duplicated numbers, as you can see below that the suibjects are different

I might try restarting the services, if I can get some downtime.

Alexis Robert

You should definitely not have duplicate key numbers, that's clearly not right.

What's the URL when you open MUREX-1919 (the TEST one and the Futures one) ?

Grant Fidler

Appreciate your time here Alexis, thank you. The URL is the same:

http://jira.somedomain.com/browse/MUREX-1919

Both 1919 links bring up the 'TEST' data, indeed when I click on the Futures link (i.e. the one which the dB 'lost' post-restore), it just moves down to the 'TEST' one. It's as though the link to 1919 remained post-restore, but the destination has now been replaced by new data.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server