Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, 2005-09-28 at 16:56 +0000, robert wrote: > I am also trying to find out the proper way to > upgrade to a bigger master primary when the > master computer dies. > > Let say we got drdb working fine. > Both drbd devices on the master and slave computer > are 5GB in size. > > MAster computer get's turned off. > slave computer's drbd0's become primary/unknown. > > now I revived the master computer with a brand new > /dev/hd1 which is 10G. > > I did modprobe on the master computer and created > a drbd0 device. This time, I don't have to > mkfs.ext3 /dev/drbd0 on the master because my slave computer > which is now in the cs:primary/unknown state > will sync all the filesystem > to the master drbd0. > > my question is, will the slave computer sync properly all the data > to the new 10G /dev/drbd0 on the master computer? > or will the master's /dev/drbd0 10G will become a 5G > because the slave's /dev/drbd0 is 5G, it is the smaller of the > two? what are the proper steps in this kind of scenario > when the primary totally dies and you put a bigger primary > /dev/drbd0 device and later wanted to make the slave's /dev/drbd0 > bigger to match the primary's 10G /dev/drbd? Disclaimer: I've only ever done this in the lab, but it's worked for me. Both sides of DRBD must be the same size. So when you bring up the new 10GB drive, DRBD will only use the first 5GB of it. To increase the volume size, you need to switch master over to the larger drive, disconnect the 5GB slave, upgrade the 5GB to a 10GB and bring it back online. At this point you will still have a 5GB volume, but both sides will be capable of upgrading to 10GB. Use the "drbdadm resize" command to grow your volume to 10GB. Both nodes must be online and both will be resized at the same time. But that only resizes the volume, not the filesystem. You will need to use resize2fs to grow your filesystem to match. I've never done this using internal metadata, so I can't say how that would affect the process. Seems inherently error prone. Corey -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20050928/46998617/attachment.pgp>