Results 1 to 6 of 6

Thread: Speeding up 4.5->5.0 upgrade

  1. #1
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default Speeding up 4.5->5.0 upgrade

    It looks like my production upgrade is going to take hours, mostly due to scripts/migrate20071206-WidenSizeColumns.pl:

    ALTER TABLE mboxgroup1.mail_item MODIFY COLUMN size BIGINT UNSIGNED NOT NULL ... ALTER TABLE mboxgroup100.mail_item MODIFY COLUMN size BIGINT UNSIGNED NOT NULL

    Are there any my.cnf options that might speed this up? My largest mail_item.idb is 260M, with 343,000 rows.

    Could I perhaps perform these changes on a running 4.5.10 system without downtime? A BIGINT column should be backwards compatible with INT, shouldn't it?

    Or maybe consider (danger!!!) skipping this script? I don't plan to allow items > 2GB any time soon, and it looks like the issue isn't fixed anyway: (Bug #22362) MailItem size must be long instead of int
    Last edited by Rich Graves; 01-03-2008 at 12:49 PM.

  2. #2
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    ...and yes, when they tell you to run under screen or at least nohup, they mean it... currently reverse-engineering the scripts so that I can resume migrate20071206-WidenSizeColumns.pl, which died 80% of the way through...

  3. #3
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    migrate20070302-NullContactVolumeId.pl is another long-running script whose only purpose is to address a potential bug that should never (ok, never is a long time) affect me: Bug 11752 - Zmvolume, can not delete primary message volume.

    That script could be executed before (or after) the 4.5->5.0 software updgrade, reducing the upgrade downtime window by about 20 minutes in my case. I'm nervous about how WidenSizeColumns's MODIFY TABLE would behave on a live system (would that effectively lock the table?), but NullContactVolumeId is just column data, so it seems OK to run at any time.

  4. #4
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    OK, there doesn't seem to be a tremendous level of interest in the forums, but FYI, this was discussed internally in December: Bug 22866 - Need incremental upgrade script for mail item size widening upgrade step

    I'm still wondering how bad it would be to do the size->BIGINT change on a live, running 4.5.10 system. If the mboxgroup[i].mail_item table is locked for writing for 1 minute, are any ZCS components likely to stack up or time out in a ungraceful manner?

    My current inclination is:

    1) Execute the WidenSizeColumns script on the live, running 4.5.10 system, which will have the effect of locking tables for writing, with faith that the system can handle it
    2) Perform the 4.5.10->5.0.1 (soon, I hope) upgrade, disabling both WidenSizeColumns and NullContactVolumeId scripts
    3) On the live, running 5.0 install, execute NullContactVolumeId script

  5. #5
    Join Date
    Jul 2006
    Posts
    623
    Rep Power
    10

    Default

    Schema upgrades are sequential, unless you account for this, running them out of order or disabling them will cause your upgrade to fail. I would advise against it, a failure during schema upgrades is very hard to recover from and will likely cause additional unnecessary downtime while you restore and start over.

    My recommendation is to make sure you have a second external MTA/MX record for your domains, so that mail queues and take the downtime hit during a non-peak hour to upgrade.
    Bugzilla - Wiki - Downloads - Before posting... Search!

  6. #6
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    Rep Power
    9

    Default

    On general principle, I agree, I would advise against decomposing the schema changes. But this particular change is well understood, and is both forwards and backwards compatible.

    What worked perfectly fine for me, and what I would strongly advocate for any other relatively savvy administrator needing to migrate any system where /opt/zimbra/db/data is more than about 10GB (ours is 16GB), is:

    1) While ZCS 4.5.10 is running the recommended full backup, execute ALTER TABLE $group.mail_item MODIFY COLUMN size BIGINT UNSIGNED NOT NULL; for each mboxgroup[1-100]. This results in read-only mailboxes for 1% of your users at a time. In my environment, each $group took just over 1 minute, during which any changes to the mailbox will block, but 1 minute is just barely within the Firefox "script is running too long..." threshold. Affected users can shrug it off as a network glitch.

    2) Execute install.sh.

    3) After the software (zimbra-core, etc) is installed, but before it's configured, edit /opt/zimbra/libexec/scripts/migrate20071206-WidenSizeColumns.pl to remove line 37, "ALTER TABLE $group.mail_item". Leave the "ALTER TABLE $group.revision" and schema version verify/change alone.

    This reduced my downtime by about 60%. WidenSizeColumns is the most time-consuming part of the upgrade by far.

    If you are upgrading from ZCS 4.5.6 or earlier, you will want to combine the contents of migrate20070606-WidenMetadata.pl and migrate20071206-WidenSizeColumns.pl. I had already taken that hit when upgrading from 4.5.6 to 4.5.10, but I can imagine a HUGE and unnecessary delay if run in series.

    Large sites that haven't yet upgraded to 5.0 should vote for Bug 22866 - Need incremental upgrade script for mail item size widening upgrade step

Similar Threads

  1. [SOLVED] Upgrade from 4.5 to 5.0
    By Stergil in forum Installation
    Replies: 2
    Last Post: 10-05-2007, 02:50 PM
  2. Successful Mac OS X upgrade of 4.05 -> 4.5?
    By mbd in forum Installation
    Replies: 3
    Last Post: 02-14-2007, 09:51 PM
  3. Replies: 8
    Last Post: 01-22-2007, 10:54 AM
  4. Upgrade FROM 4.0.5 GA 518 to 4.5 GA 612 Failed
    By jcone in forum Installation
    Replies: 7
    Last Post: 01-18-2007, 08:51 PM
  5. 4.5 Upgrade Question Re Web Clients
    By LMStone in forum Installation
    Replies: 3
    Last Post: 01-17-2007, 01:55 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •