How does pool rebalance work between failover pairs?

In ISC DHCP 3.0.x, there was no min-balance parameter - it was introduced in 3.1.x when the mechanism for pool rebalancing was changed.

In 3.0.x, the server attempted to perform rebalance on a pool for every /successful/ allocation. if it could not rebalance the pool itself, it would send a 'POOLREQ' message to the peer. This resulted quite obviously in an awful lot of activity around pool rebalance events; the impact of this was very high on large installations. The server receiving a POOLREQ has no way to know which pool the peer is referring to, so it rebalances all pools.

From 3.1.x, ISC's DHCP moved to a schedule based system. The pool is rebalanced at a time that the server estimates it may be imbalanced (the estimate is based on the expiration time of the oldest lease). The min and max values govern that selection (by default 60/3600 seconds respectively), so rebalance events don't fire too often, nor too infrequently.

The server tries to estimate when the remote-system's pools are going to reach the "max lease misbalance" point at the current estimated rate of change (as measured by the oldest free and backup leases expiration times). It only reduces this estimation, but never below min-balance, so in practical terms it takes the "worst case" pool, the pool that indicates the most near term potential schedule for reaching max-misbalance.

Theoretically, the amount of time between balance events should rise as the expiration times on your free/backup leases become more distant memories of the past, and it should dynamically become more frequent as recent activity makes them more fresh.

If your practice is that leases cycle owners so fast they never get to become memories of the distant past, you can simply raise the min-balance percentage as a workaround. The dhcpd.conf manpage has a section on min-balance and the other parameters that govern pool balance maintenance.