Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> <snip> > > Now I need to reboot here, (due to the LVM module), now my gut is > saying it should all be ok, but of course drbd is going to fire up > on reboot, what is my process from here? > > Will it be ok for the reboot, see as this will be the first time > drbd starts on the secondary and connects to the primary? > Nothing bad will happen. Until/If you create the metadata on storage01, drbd will ignore the disk resource. From there, you are just replacing a disk, as in the doc: http://www.drbd.org/users-guide/ch-troubleshooting.html#s-replace-disk-inter nal-metadata. When you attach the resource, the sync will start _and_ it will start in the direction you desire. You may want to create a tiny (few hundred M) resource and go through the steps on it for your own comfort. I set up my entire drbd configuration on a couple of virtual machines before I lit mine for real - and I use them often to answer the "what if xxx happens" questions. Add the definitions to both configuration files. Do the create-md, attach, connect, mount, mkfs on storage00 and put some data on it. When you do the create-md on storage01, the sync will automatically start and whatever you've put on it using storage00 will copy over. Verify by taking down the resource on storage01 and mounting the device locally. You have the entire wire allowed for sync. This will impact live throughput. If the devices are all idle, fine. If the primary is expecting to get anything done while the sync takes place, then throttle that back a bit (actually, a lot). You can temporarily override the syncher speed in an emergency situation, but for normal use maybe 35M would make more sense. Remember, drbd will be running fine during the sync, even if dual-primary! Leave some room for drbd non-sync use of the wire. Command that speeds up sync but doesn't flummox the config files: drbdsetup /dev/drbd<minor> syncer -r 110M Dan in Atlanta