Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, Thank you for the input on how to tackle this in a reasonable manner. I have a few questions in regards to the some of the directions: On Apr 18, 2008, at 3:51 AM, Lars Ellenberg wrote: > On Fri, Apr 18, 2008 at 11:24:23AM +0200, Leroy van Logchem wrote: >> >>> faced with the issue of needing to replace the current hard-drives >>> with much larger ones and need to do this while keeping the MySQL >>> instance available. >> >> To avoid: >> - mixing up the partitions > > hm? > >> - tricky filesystem growing > > ok, if you cannot online-grow, that would be a problem. > but otherwise, say you are on recent and prepared ext3, > or on xfs anyways, where is the "trickyness"? > >> - running out of time during the migration > > why do you see a problem there? > >> You could: >> >> 1) Make sure the secondary node does not reconnect by: >> -- Changing /etc/drbd.conf ip and/or port numbers to none existing >> ones >> -- Disable automatic starting of drbd and heartbeat etc >> 2) Replace the disks and configure the partitions for drbd usage >> -- Perhaps setup seperate metadata >> 3) Manually get drbd running >> -- Force to primary >> -- Create the filesystem(s) >> -- Mount it >> 4) Copy the currently running MySQL to your new setup >> -- By means of rsync and mysqlhotcopy >> -- Change the bind-address so you can test >> >> When it's running fine again then re-enable the service startup and >> prepare the final fail-over: >> >> 1) Stop everything on the new setup and get back to the original >> configuration files >> 2) After a final hotcopy, pull the plug on the old primary >> 3) Let the new setup start as primary >> >> (this should be scripted to have the smallest gap possible) >> >> Now the server with the smaller disks can be upgraded. Only redo the >> partitioning steps, so skip the mkfs. During the long initial sync >> you >> might want to limit the bandwidth ( force changing speeds by >> disconnect/reconnect and drbdadm adjust all etc.. verify by watching >> /proc/drbd ). I'm not really seeing the above mentioned directions from Leroy as keeping the database server up and available for requests for the entire duration of the maintenance, but yours, from what I can tell, seems to provide that capability. > perfectly fine recipe. > > however, I would > > stop heartbeat and drbd on secondary. > disable their initscripts (e.g. chmod -x) > [segno] > preferably find a way to attach both new and old disks to this box > dd_rescue /dev/old/lower-level /dev/new/lower-level > dd_rescue /dev/old/meta-data /dev/new/meta-data I'm assuming this is going to make the new (larger) hard drives look exactly like the smaller hard drives. Is the 'drbdadm resize' mentioned below, that will increase the size of the partitions and take advantage of the new space available for the /data and /logs partitions I have setup in the DRBD config? > disconnect the old devices > reconfigure drbd to use the new storage > drbdadm attach > should come up as Secondary/Unknown Consistent/DUnknown, > or Secondary/Unknown UpToDate/DUnknown, > depending on your configuration > drbdadm adjust I've read some posts online that lead me to believe that drbdadm adjust may be problematic with DRBD version 7. Can you elaborate on that? If I indeed have something to worry about, do you recommend that I upgrade our DRBD systems to version 8 before attempting this type of maintenance? If so, do you have any supported documentation that you recommend for the upgrade? > wait for the (incremental) sync > re-enable init scripts, start heartbeat on upgraded node > [coda] > do a switchover Is there another way to accomplish this without having to have both the old drives and new drives lit up in a box at the same time? The standard configuration for these boxes, are 2 disks, with a RAID-1 setup, mirroring the two disks. This means I could probably pull a drive, put in the newer (larger) drive, perform the steps you mentioned above, shut down the box, pull out the second old (smaller) drive, put in the newer drive, light up the machine, and let RAID sync the second disk with the first one. However, if you know of a way to do this without having the old and new disks in the box at the same time, I would be interested in knowing how? > dal segno al coda for other now secondary node > > drbdadm resize (on both boxes). > wait for sync of new data area > online-grow file system on primary box. > > start a low-bandwidth verify from the secondary. What exactly is a 'low-bandwidth verify'? :) > -- > : Lars Ellenberg http://www.linbit.com : > : DRBD/HA support and consulting sales at linbit.com : > : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : > : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : > __ > please don't Cc me, but send to list -- I'm subscribed > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user Thank you again for your help, Clint