On Wednesday 18 February 2009 17:57:16 Karl Denninger wrote: > ian j hart wrote: > > On Friday 13 February 2009 08:40:27 Goran Lowkrantz wrote: > >> Hi, > >> > >> When have done this, MySQL is OK but Berkley and PostgreSQL need > >> dump/restore. > >> > >> /glz > > > > [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 <mandr...@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 > >>> mandr...@fark.com > > I have been able to come up with a procedure that works.
It's a while back, but I believe this matches what I did. I built the same major/minor revision, just in case it made any difference. > > 1. Load a new hard disk with the 64-bit code. Perform a buildworld and > buildkernel, and installkernel and installworld to this disk to verify > that it will install and run. You now have a "base" disk to use for > migration. > > 2. Make sure you have a backup (:-)) Not optional. I broke the mirror and took a backup and I actually checked the backup. > > 3. Boot the migration hard disk as the system disk and mount the subject > machine's disk drive(s) under /mnt. > > 4. Do "make DESTDIR=/mnt installkernel" and "make DESTDIR=/mnt > installworld" > > 5. Shut down and disconnect migration disk. > > 6. Boot SINGLE USER and verify that the system boots, you can fsck -p > the disks, and mount them. The system should boot and run. > > 7. Come up multiuser but with any services necessary to the world > offline. Some of your packages may blow up when started. If so, > portupgrade SHOULD fix it, but this is not consistent. I had to > manually dump the ports tree and rebuild a few installed ports due to > what appear to be broken dependancies, but not many. I put "ports" in rc.conf.local. Makes it simple to disable them all. IIRC I deleted them all and did pkg_add -r, which is quick enough if you don't have X. Save a listing first, of course. > > Postgresql 32-bit runs fine without recompilation after doing this. It > is arguably preferrable to recompile; doing so requires a dump/restore > of the data as the 32 and 64-bit code will NOT run off the same binary > data store. > > Attempting to "make instalkernel" on an "in-place" basis resulted in a > system that booted but failed immediately due to loader conflicts; there > was no way to get the rest of the codeset loaded if you make that mistake. > > The "migration disk" approach appears to work fine. -- ian j hart _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
