[DRBD-user] Any way to jump over initial sync ?

[Julien Escario]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Many many thanks for the detailled procedure.

I'll try in a few days with drbd9 and will let you know if something has to be
changed (mainly because resources are created on the fly on each side).

Julien

Le 29/08/2018 à 14:32, David Bruzos a écrit :
> Hi, I have lots of experience skipping the initial sync with ZFS zvols and 
> drbd 8.4.x.  I have been using the "drbdadm -- --clear-bitmap 
> new-current-uuid <RESOURCE>" for years and never had a problem.  This is 
> why it works:
> 
> 1. New ZFS volumes are guaranteed to return only zero data for unwritten 
> blocks, so two new volumes are always in sync, if they have not been 
> written to. 2. Also, if you have a VM base image on two hosts, you can 
> clone the volumes in the image on each host and also skip the initial
> sync, because both clones will be identical.  Of course, I am asuming that
> the base image was replicated via ZFS streams. 3. LVM volumes and most
> other volume types will not work well, because they don't guarantee new
> volumes to be zero-filled.  However, depending on your use case, it is
> often better to zero-fill your volumes manually (E.G. cat /dev/zero
> >/dev/vg/vol0) and skip the sync.  It does not seem reasonable, but given
> the storage and network characteristics at play, it could be much much
> better than doing an actual DRBD sync. 4. If in doubt, run a drbd verify
> until you feel confidence in your process.
> 
> * Typical way to skip the sync (at least this is my proven method):
> 
> # drbdadm create-md <resource>  -  (do this on both nodes) # drbdadm up 
> <resource>  -  (do this on both nodes) # drbdadm -- --clear-bitmap 
> new-current-uuid <resource>  -  (do this on secondary node) # drbdadm 
> primary <resource>  -  (do this on primary node) # cat /proc/drbd  - 
> (Enjoy!)
> 
> In my opinion, having to replicate multi-tb volumes is an incredible waste 
> of time and resources, if it can be safely avoided.  I've talked to many 
> people that patiently wait while their giant 4 TB VM volumes do their 
> initial sync and hog their environment's I/O in the process...
> 
> I hope this helps you and others out there who are looking for a better 
> way...
> 
> David
> 
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJbhrW0AAoJEOWv2Do/Mctu8TMP/3DYV8A+azXZLeq1AfRk/VE0
Db5rJkgjeNRvCIFdpr49m+bcFlrA/++Evlf/TdDnWH03Rq0rg8L44oEX9dN3aAqg
9QJpcPduXYaWpvBAOx3dD2RLpKhiHPUWFyMLBEXV9+X4fK8RbvXSMj/hTt9xQs1C
Zf801bn5hlwl3m0o0kloWh2XdkAteG3t9E5WbUvb+6B+Qkn+/VkWtJ/gRKIQZv8H
3mvO/5kV3YcIaoP6vmVvKo37fH2A7Sj3AfpIUsOUCrLrqoW6vJbMXnW7SjfbkhVg
vVlMNRRxDmfwGHqYQHUJDgOMJexVBZXxRUY7xcUJ4eSZ3HG/pG8r8Us9RBLp39SS
DKDABmVhjbtHMQMXiLCBYyXj74hHfEON0SSW6UHWb+UVBbMyZrf93KJvRBD56dfv
LspkZrb3mQ0q4TImG/MbTswMs0RraJUZqbmj9WALyPYTGTV/ORsE+g0KMV8gnTXM
4u4go9z5VQoDTah+aTcE3wpzdyDstd5i5p1CSMSeW/g9u1V5r2zKO6r39V4YRu14
Zoyv6J55y3+vmH25jqvIBJUkOaDsDCAlWWwE9pfyFPKQc/MmArGUWMuitKD0cgiP
vTSaJ4hm+xFFiXgjLUNxvCyMVSgCmhLVnccsjiL1LTCvCav3QscfYZ6K6dBtIdxA
NrmvY3d5zGDw7MW8VzvU
=J/C6
-----END PGP SIGNATURE-----