Upgrade from 32-bit to AMD-64?
ian j hart
ianjhart at ntlworld.com
Wed Feb 18 09:46:29 PST 2009
On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote:
> When have done this, MySQL is OK but Berkley and PostgreSQL need
[sorry I'm a bit late]
IIRC system accounting did weird stuff until I adjusted it with rm :)
> --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 ...............................................
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
ian j hart
More information about the freebsd-stable