[DRBD-user] migration strategy?

Florian Haas florian at hastexo.com
Fri Nov 18 21:02:54 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 11/18/11 19:33, Miles Fidelman wrote:
> Florian,
> Thanks!  Exactly what I was looking for.  A couple of follow-ups if I
> migth:


> Florian Haas wrote:
>> On 11/18/11 16:56, Miles Fidelman wrote:
>> 1. Shut down one of the old nodes, have Pacemaker take over all cluster
>> services to the other.
>> 2. Bring up the first of the new nodes. Do not start cluster services
>> yet.
>> 3. Sync DRBD. DRBD 8.3. will happily talk to 8.0.14.
> I'm assuming you're suggesting that I do this by:
> - dropping the secondary on the old node
> - adding a new secondary on the new node
> - syncing


> Which leaves an uncomfortably long period when there's only one
> definitive copy of the volumes (not horrible, as the underlying disks
> are RAIDed, but still).  Or are you suggesting something else?

No, I am suggesting exactly that. You could dramatically shorten that
"uncomfortably long period" by preseeding your new Secondary using
truck-based replication -- see below for details. Sadly, that is not
available in 8.0 (in reality it's actually possible, but with a metadata
hack you really don't want to do). That being said, considering the
servers are a few years old, I would assume that the data set isn't huge
by today's standards, and so I'm unsure whether that period is even that
long. Consider that you can haul about 175GB over a 1GbE link in an hour
without even much impacting I/O speed on your Primary (with sync
throttled to 50 MB/s). If the latter is of no concern because you're in
a downtime window, you could do twice as much, or the same in half the time.

> For the future, what would be the sequence for using 3-node (stacked)
> setup for this kind of migration (i.e., going from 2 nodes to 3 nodes
> and then back to 2), and am I correct that this is not possible with
> DRBD 8.0.14?

You are correct about that; prior to 8.3 stacked resources weren't a
possibility. Again, under the covers they were, but you would only be
able to do that using the low-level utilities as the drbdadm parser
didn't support the "stacked" syntax.

In fact, for a future migration like that you _may_ be using a stacked
setup, but really what I would do is probably the same procedure, except
creating a snapshot off your old secondary, preseeding the new one with
that (you could be doing that with netcat without ever taking the old
secondary down), and then just syncing the delta when you bring the new
one up. That's the purpose of truck-based replication, explained in more
detail here:


I tend to think that that's more comfortable, and easier to use, than a
temporary 3-node setup, but then again that may just be my personal

Hope this is helpful.


Need help with DRBD?

More information about the drbd-user mailing list