[DRBD-user] Any way to jump over initial sync ?
david.bruzos at jaxport.com
Wed Aug 29 17:21:49 CEST 2018
Yeah, no problem. Hopefully it helps you with 9. It will be great if you update with DRBD9 specific details...
David Bruzos (Systems Administrator)
Jacksonville Port Authority
2831 Talleyrand Ave.
Jacksonville, FL 32206
Cell: (904) 625-0969
Office: (904) 357-3069
Email: david.bruzos at jaxport.com
On Wed, Aug 29, 2018 at 05:03:21PM +0200, Julien Escario wrote:
> -----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).
> 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-----
> -----END PGP SIGNATURE-----
> drbd-user mailing list
> drbd-user at lists.linbit.com
Please note that under Florida's public records law (F.S. 668.6076), most
to or from the Jacksonville Port Authority are
public records, available to the public and media
upon request. Your email
communications may therefore be subject to public disclosure. If you have
received this email in error, please notify the sender by return email and
without forwarding to others.
More information about the drbd-user