RT 2.0.11pre1 / How to recover from brokenness caused by 2.0.10

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_idOn 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…:slight_smile:

Help!!! Please? :frowning:

-Rob.


rt-users mailing list
rt-users@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@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

rt-announce mailing list
rt-announce@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-announce

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…:slight_smile:

Help!!! Please? :frowning:

-Rob.


rt-users mailing list
rt-users@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@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Josh Krikke krikke@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

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)?

To the best of my knowledge, yes.

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

THANK YOU THANK YOU THANK YOU!!!

I just edited the database directly, and everything came back up. THANK
YOU for taking care of this so quickly. You are a gentleman and a
scholar! :slight_smile:

Hope you had a Merry Christmas, by the way, Jesse. And the rest of you,
as well!

-Rob.