Don't know. My hypotheses are :
* using plugin transactions compared to 1.2.10.x
* bdb version? but even with compat-db-47 and 1.2.10 the problem still happens on CentOS7, though much less frequently. It never happens with 1.2.10 with rpm bdb on CentOS5.
* change from  mozilla ldap libraries to openldap libraries?

seems to be some sort of thread or transaction contention that is reduced when i add CPUs/increase checkpoint interval. It really looks like the master server just does not send entries any more at some moment... SSL/TLS slows the things down so less entries are sent before everything gets stuck...

I'll get back with more information (stacktraces) tomorrrow.
Another version :
insufficient entropy generation speed for TLS/SSL total update (/dev/urandom vs blocking /dev/random), especially in VMs??


it is possible the VM system is running out of entropy, and apps to experience long delays, to verify:
cat /proc/sys/kernel/random/entropy_avail

one way to fix this is to use and run the haveged service on the KVM guest, that can be downloaded from EPEL

it can also depends on the VM configuration, for example if using KVM and libvirt (recent version), use the KVM host entropy is with a configuration similar to this:
  <rng model='virtio'>
     <backend model='random'>/dev/random</backend>
     <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
   </rng>
</devices>
without that config, my test RHEL 7 KVM guest has quite a low entropy.
and the entropy will depends on the cpu characteristics.
Thank you Marc.  I'll try checking the entropy pool state during the total on-line import. We are using VMWare for virtualization, so there is no simple way to expose host /dev/random to the guest VMs... However i've had this problem (stucked initial replication) even with LDAP/389 replica protocol, though it happened much less frequently. Anyway, i've made a ticket for this problem: https://fedorahosted.org/389/ticket/47942