(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.
See the section called “Configuring the rate of synchronization” for configuration suggestions with respect to synchronization.