[rt-users] [rt-announce] RT 2.0.11pre1 / How to recover from brokenness caused by 2.0.10
krikke at macatawa.org
Wed Dec 26 15:46:06 EST 2001
So, if we have upgraded to 2.0.10, but not merged anything, and then upgraded
to 2.0.11pre1, we should be safe (without having to do any database restores)?
On Wednesday 26 December 2001 03:14 pm, you wrote:
> RT 2.0.11pre1 is now available. The _only_ change from 2.0.10 is that it
> won't cause all unmerged tickets to "disappear" from search listings after
> a merge.
> If you got bitten by the bug in 2.0.10, I'm really quite sorry.
> There are two ways to get your database back to where it should be:
> 1) Restore your database from the last known-good nightly backups.
> (The night before you installed 2.0.10)
> Make a copy of your database update logs.
> Discard everything before you made the backup.
> Look through them for a long series of "Update Tickets SET
> EffectiveId....." statements.
> Remove those statements.
> Replay everything else at the database.
> 2) WARNING: This is somewhat more dangerous, since it involves straight
> database munging You should make a backup of your RT database before
> proceeding and check it over CAREFULLY afterward.
> mysqldump rt2 > rt-premunging-backup
> Figure out what ticket is still showing up in ticket listings. If
> you've merged multiple tickets since installing 2.0.10, repeat the "UPDATE"
> statement below for each of them.
> Make a note of its ticket id. You'll need it below, where I say
> mysql rt2
> UPDATE Tickets Set EffectiveId = id where EffectiveId = $ticket_id
> On Wed, Dec 26, 2001 at 02:25:48PM -0500, Jesse Vincent wrote:
> > There's a bug in the merge functionality that changes in 2.0.10 tickled.
> > I'm still tracking it down, but it looks like the system is incorrectly
> > setting some metadata related to a merge for too many tickets when a user
> > anually merges a ticket. I suspect this has been going on for quite a
> > while and that 2.0.10 is the first release that actually relies on this
> > metadata for stripping merged tickets out of search displays.
> > It looks like it should be relatively painless to restore your database
> > to a good state if this bug hit you
> > More info to come later.
> > -j
> > On Wed, Dec 26, 2001 at 07:32:56AM -0800, Rob Mitzel wrote:
> > > Hi everyone,
> > >
> > > I figured I'd give 2.0.10 an install on our production machine. So I
> > > checked the deps, made the new ones, installed, everything looked
> > > great. However, now, we're getting a reproducable error:
> > >
> > > Say I go into a queue, and it has 5 new tickets, 4 on the exact same
> > > subject or whatever. So I go into ticket #3, and merge it with ticket
> > > #2, which is the same. It tells me it's merged. From that point on,
> > > no matter what I do, it makes all the other new tickets dissappear, and
> > > it just shows the ticket I merged, nothing else. no changing of the
> > > search parameters will help, the search just thinks that 1 ticket is
> > > the only ticket in the entire db. If I type in an individual ticket #
> > > and go to it, it's fine...
> > >
> > > Of course, I'm doing this after having just been woken up after 2 hours
> > > of sleep by a frantic guy in my NOC, so...:)
> > >
> > > Help!!! Please? :(
> > >
> > > -Rob.
> > >
> > >
> > > _______________________________________________
> > > rt-users mailing list
> > > rt-users at lists.fsck.com
> > > http://lists.fsck.com/mailman/listinfo/rt-users
> > --
> > http://www.bestpractical.com/products/rt -- Trouble Ticketing. Free.
> > _______________________________________________
> > rt-users mailing list
> > rt-users at lists.fsck.com
> > http://lists.fsck.com/mailman/listinfo/rt-users
Josh Krikke krikke at macatwa.org
MacNet Sysadmin Holland, MI
GnuPG Fingerprint: AC6F 13AC F945 CC45 BDFC 509E 8F41 9549 64DD 95DB
My public key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x64DD95DB
More information about the rt-users