There is quite a bit of confusion about the DRBD® configuration value
al-extents (activity log extents), so here’s another shot at explaining it.
Imagine a node having a DRBD resource in the
secondary role. When it crashes, gets powered down, or looses connection to the primary for any other reason, the primary will remember the changed blocks in its bitmap; so when the secondary node connects to the primary again, the primary can tell exactly what data has to be transferred to get it
Now, when the node with the
Primary role crashes, no one can say with certainty which blocks have been changed on its storage, but haven’t been sent to the secondary, or vice-versa.
So the primary has to persistently remember which blocks it touched lately, so that on a crash it can ask the secondary node (which might have been promoted to primary in the meantime) for these blocks; they are fetched and written to the crashed primaries’ storage, to get its data consistent with the other node.
al-extents value defines how big the hot area (=active set) can get. As the AL has to be stored on persistent storage, each change to this set has to be written to the meta-data area, before the actual data can be written – and waiting for that can slow down DRBD. So you can choose between
- a small activity log – this might make DRBD slower during load;
- or a big activity log, which will cause more data to be re-synced in case of a primary crash.
So, for the most part people are happy choosing a bigger activity log; in the 8.3 series the maximum value is 3833; for 8.4 the limit got raised to 6433, and who knows what 9.0 brings? 😉