(Re-)synchronization is distinct from device replication. While replication occurs on any write event to a resource in the primary role, synchronization is decoupled from incoming writes. Rather, it affects the device as a whole.
Synchronization is necessary if the replication link has been interrupted for any reason, be it due to failure of the primary node, failure of the secondary node, or interruption of the replication link. Synchronization is efficient in the sense that DRBD does not synchronize modified blocks in the order they were originally written, but in linear order, which has the following consequences:
Synchronization is fast, since blocks in which several successive write operations occurred are only synchronized once.
Synchronization is also associated with few disk seeks, as blocks are synchronized according to the natural on-disk block layout.
During synchronization, the data set on the standby node is partly obsolete and partly already updated. This state of data is called inconsistent.
A node with inconsistent data generally cannot be put into operation, thus it is desirable to keep the time period during which a node is inconsistent as short as possible. The service continues to run uninterrupted on the active node, while background synchronization is in progress.
You may estimate the expected sync time based on the following simple formula:
tsync is the
expected sync time. D is the amount
of data to be synchronized, which you are unlikely to have any
influence over (this is the amount of data that was modified by
your application while the replication link was broken).
R is the rate of synchronization,
which is configurable — bounded by the throughput
limitations of the replication network and I/O subsystem.
The efficiency of DRBD's synchronization algorithm may be further enhanced by using data digests, also known as checksums. When using checksum-based synchronization, then rather than performing a brute-force overwrite of blocks marked out of sync, DRBD reads blocks before synchronizing them and computes a hash of the contents currently found on disk. It then compares this hash with one computed from the same sector on the peer, and omits re-writing this block if the hashes match. This can dramatically cut down synchronization times in situation where a filesystem re-writes a sector with identical contents while DRBD is in disconnected mode.
See the section called “Configuring the rate of synchronization” and the section called “Configuring checksum-based synchronization” for configuration suggestions with regard to synchronization.