[rt-users] Migration Prep

Craig Ringer craig at 2ndquadrant.com
Fri Jul 26 00:41:06 EDT 2013

Hash: SHA1

On 07/26/2013 12:32 AM, Kevin Falcone wrote:
> On Wed, Jul 24, 2013 at 08:36:43PM -0700, Paul O'Rorke wrote:
>> From what I've read it seems that the best approach might be to:
>> 1. make a clone of the existing RT, 2. upgrade it to 4.0.13 3. do
>> a mysqldump on the upgraded clone 4. restore the dump on the new
>> server.
> Since you have a new server, upgrading should be easy, if
> something fails, you just start again on the new server.  You're
> not in any way touching production until the final cutover.
> I always:
> Install RT 4.0.14 on the new server mysqldump the old server import
> on the new server run make upgrade-database test turn off the old
> server do a final dump, import, upgrade go forth and rejoice.

I just followed much the same process (with 4.0.15 and PostgreSQL),
except that I used replication (Londiste) to narrow the outage window,
streaming changes from the old to the new server until the moment of

I also used rinetd to redirect traffic from the old server to the new
one, so there'd be no visible outage to people whose DNS hadn't caught
up to the A record change yet. This was necessary because the DNS host
used is unfortunately not able to lower the TTL.

You can do the same thing for mail handling if your RT server receives
mail by direct SMTP, or you can change rt-mailgate in /etc/aliases to
remote-deliver over http directly to the new server and set the Apache
security rules to allow it.

With a little effort you can keep the outage window down to less than
a minute.

- -- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the rt-users mailing list