There can sometimes be a lot of confusion and complexity about the DRBD® configuration value al-extents (activity log extents). We have written this blog post to shed some light on the subject. We hope you find it useful.
Imagine a node having a DRBD resource in the secondary role. When it crashes, gets powered down, or loses 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 precisely what data has to be transferred to get it Up-to-Date again.
Now, when the node with the Primary role crashes, no one can say with certainty which blocks have been changed on its storage but hasn’t been sent to the secondary, or vice-versa.
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 the data consistent with the other node.
The 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. 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 will cause more data to be re-synced in case of a primary crash.
So, for the most part, people are happily choosing a bigger activity log; in the 8.3 series, the maximum value is 3833. For 8.4, the limit rose to 6433, and who knows what 9.0 will bring? Contact the team if you want to discuss anything within this article.
