Upgrade from 32-bit to AMD-64?

Goran Lowkrantz goran.lowkrantz at ismobile.com
Fri Feb 13 01:05:21 PST 2009


Hi,

When  have done this, MySQL is OK but Berkley and PostgreSQL need 
dump/restore.

/glz

--On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews at bit0.com> wrote:

> Xin LI wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Karl Denninger wrote:
>> [...]
>>> I guess I need to schedule the 2-3 hours of downtime..... the reason for
>>> this, by the way, is that I have a dbms app on there that is getting too
>>> RAM hungry for its own good (its a Quadcore CPU) and I'm up against the
>>> RAM limit for 32-bit code.  The board will support more but 32-bit code
>>> won't; ergo, the only way to get beyond this is to go to 64-bit.
>>
>> Oh wait!  One thing you wanted to know is that, some database *can* have
>> different on-disk format for 32-bit and 64-bit binaries.  Be sure to
>> have a dump handy.  Last time I hit this on a MySQL "upgrade" between
>> two servers, and I end up using its replication functionality.  The
>> operation took longer time than I expected at the beginning.
>
> For what it's worth, I did an in-place source upgrade on our MySQL server
> (for the same lack-of-memory reason) and didn't have any on-disk format
> problems.  In fact later on when troubleshooting data corruption problems
> that turned out to be bad hardware, I switched between 32-bit and 64-bit
> mysqld binaries without rebooting or dumping/reimporting the database.
>
> BUT... there was no replication involved.  It wouldn't surprise me if the
> binlog or relay logs were in an architecture specific format. InnoDB and
> MyISAM tables don't appear to be.  This was over a year ago though, so
> test on a scratch box first and you may save yourself a bit of downtime.
>
> The upgrade is a pain, and does have a lot of potential foot-shooting,
> and you have to immediately recompile ALL of your installed ports (and
> anything else not built from ports) to avoid mixing 32-bit and 64-bit
> shared libraries...  and that rebuilding ports time is where most of your
> downtime comes from if it's a production box.
>
> If you're feeling lucky, the procedure's in the list archives somewhere
> and the super-short version is you turn your swap partition into a
> temporary amd64 root filesystem, installworld/kernel into that, boot into
> that, then mount and installworld/kernel on top of the old i386 root
> filesystem from there, then boot into it and recompile all your ports
> (after reclaiming your swap partition for swap).  Or, the way I did it
> last time was to boot into a PXE diskless FreeBSD/amd64 install and use
> that to mount/install over the i386 stuff.
>
> Definitely practice on a scratch system first. :)
>
>
> --
> Mike Andrews
> Server Monkey
> Fark, Inc
> mandrews at fark.com
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"



................................................... the future isMobile

  Goran Lowkrantz <goran.lowkrantz at ismobile.com>
  System Architect, isMobile AB
  Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden
  Mobile: +46(0)70-587 87 82
http://www.ismobile.com ...............................................


More information about the freebsd-stable mailing list