[rt-users] [rt-announce] RT 2.0.11pre1 / How to recover from brokenness caused by 2.0.10

[Josh Krikke]

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
> "$ticket_id"
>
>     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