Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Apr 21, 2008 at 10:18:16AM -0700, Clint Rosander wrote: >> 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? in this particular case (coming from unconfigured, going normal operation), the sequence drbdadm attach; verify; drbdadm adjust; was chosen instead of drbdadm up, so you have time to verify the expected outcome of the attach command (expected data on the expected device, expected UUIDs (use drbdadm show-gi), etc. before connecting the peers, which would start a resync. in this situation, whether you do "up" or "attach; adjust" or "attach; syncer; connect" should not matter, and all do exactly the same. >> 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, if your raid can handle different sized disks, the raid1 sync replaces the "dd_rescue" step. * wait for the raid1 to sync up * pull the other drive, wait for the raid1 to sync up * do the same on the other box * go to "drbdadm resize" below. - no switchover necessary, no shutdown necessary > 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? if you just replace the disks, you need to create new drbd meta data, and you need to do a drbd full sync. depends on the actual setup whether * full sync of local disk, then incremental sync of drbd, * or just a full sync of drbd will be less efford. >> 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'? :) you need 8.2.5 or later, you configure syncer rate so low that it has neglectable impact on production, and say "drbdadm verify". that is just to reassure you everything is in sync. -- : 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