Date: Fri, 13 Feb 2009 09:40:27 +0100 From: Goran Lowkrantz <goran.lowkrantz@ismobile.com> To: d@delphij.net Cc: freebsd-stable@freebsd.org, Mike Andrews <mandrews@bit0.com>, Karl Denninger <karl@denninger.net> Subject: Re: Upgrade from 32-bit to AMD-64? Message-ID: <2CA7DE699281AFA5DF2BD851@syn> In-Reply-To: <499526E9.3090804@bit0.com> References: <4994CD7B.7040302@denninger.net> <4994D603.2060406@delphij.net> <4994D931.4060508@denninger.net> <4994DACC.1040801@delphij.net> <4994DBC1.2000309@denninger.net> <4994DFB0.3060704@delphij.net> <499526E9.3090804@bit0.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, When have done this, MySQL is OK but Berkley and PostgreSQL need=20 dump/restore. /glz --On February 13, 2009 2:53:13 -0500 Mike Andrews <mandrews@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@fark.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ................................................... the future isMobile Goran Lowkrantz <goran.lowkrantz@ismobile.com> System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ...............................................
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2CA7DE699281AFA5DF2BD851>