* if the virtual machine has only one CPU. Adding a second CPU increases the number of transferred entries before the initialization gets stuck. So it may me some thread/transaction  contention or deadlock.
* if the replication agreement uses SSL(port 636) or TLS(port389). Using port 389 with LDAP protocol instead of TLS/SSL increases the number of transferred entries before the initialization gets stuck. Sometimes the initialization even ends successfully in this case.
* decreasing nsslapd-db-checkpoint-interval (say, to 5 seconds) also gets the problem worse
This indicates the issue is in the BDB?
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??