Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 22/10/15 10:50 AM, Lars Ellenberg wrote: > On Thu, Oct 22, 2015 at 01:03:10AM -0400, Digimer wrote: >> On 21/10/15 03:57 PM, Christian Völker wrote: >>> Hi all, >>> >>> just a simple question for my own curiosity. >>> >>> Assume a two node master-slave setup. Disk on the master fails. All >>> reads and writes go through the slave (master remains primary). >>> >>> Now the disk on the primary is replaced and the full sync is started. >>> >>> Now let's say the sync is at 40% and a write occurs which fits into the >>> not yet synced 60% of the disk. >>> >>> Ist the block now written in parallel to both nodes and marked on the >>> primary as "already synced" or does the write affect only the slave and >>> during the remaining sync the block is copied back to the primary? >>> >>> Just curious.... >>> >>> Thanks! >>> >>> Chrischan >> >> Once connected, all new writes are synchronous, yes. Out of sync blocks >> replicate at the resync rate. This is why setting a high resync rate >> will slow down applications writing to DRBD because the bandwidth >> available for new writes is total capacity minus capacity used by resync. > > But yes, any write during resync to no-yet synced, "dirty" blocks > will bring those blocks in sync as well. > > As an extreme example, if you'd just zero-out the full device during > resync, you'd bring it in-sync by application writes. This 'zero-out' trick is exactly what I do for all new DRBD builds. It's a great way, pre-production, to sync DRBD without mucking around trying to force the normal resync rate up (which I wouldn't want in production anyway). -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?