Periodic Compactor keeps revisions up to 2 * periodInHour

[yudai]

Hi, I have a question about the periodic compactor.

Issue Observed

ETCD servers keep revisions older than a configured retention hours.

Issue Detail

The Periodic compactor runs a compaction every periodInHour.

This means:

• Just after a compaction: etcd has revisions since periodInHour ago
• Just before a compaction: etcd has revisions since 2 * periodInHour ago

Impact for Operation

Estimating DB usage is difficult with larger auto compaction retention hours.

For example, with 24 hours retention, etcd sometimes has revisions made last 24 hours (just after a compaction), and sometimes revisions made last 48 hours (just before a compaction). So even when you set 24 hour retention time, you need to estimate the usage of 48 hours.

This makes dealing with the 8GB max db size pretty harder. Also defrag takes much time after a compaction with longer retention hours.

Suggested Resolution

To make the compactor run a compaction every hour, which keeps revisions up to periodInHour + 1 (this might be good to prevent spikes by large compactions?).

Side Note

I assume that the compactor is supposed to run a compaction every hour from the beginning? Because, t.revs and getRev() are not necessary for the current behavior.

Question

Is the current behavior of the periodic compacter intended?
If not, I'll send a PR to fix it.

[heyitsanthony]

@yudai Sounds like a better way to do it. Submit a PR? Thanks!

[yudai]

Oops, push -f messed up somehow. Hoping these references will be removed by GC(?).

Created a PR anyway.