You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
etcd v3.3 has already been out of support, so we don't need to talk too much about the old behaviour for 3.3 in https://etcd.io/docs/v3.5/op-guide/maintenance/#auto-compaction. It has no any benefit other than confusing the end users. Instead, we just need to summarize the latest behaviour.
If users still need to look into the historical behavior, they just need to look at 3.4 or older version's document.
The text was updated successfully, but these errors were encountered:
We also need to clarify the recommended configuration --auto-compaction-retention for the auto compaction, it's up to users' use case. If there are frequently updating operations on same resources, then a short period (i.e. 1h or even 30m) might be better, otherwise, daily (24h or 48h or even 72h) might be acceptable. Generally speaking I think 10h could be a good default value.
Also let's clearly clarify that the retention windows. For example, if you set the compaction period as 10h, it means it will always keep roughly 10 hours's history. In oversimplified terms, a record won't be compacted until roughly 10 hours later after it's generated. The motivation is to ensure that the compaction won't affect the slow watchers.
etcd v3.3 has already been out of support, so we don't need to talk too much about the old behaviour for 3.3 in https://etcd.io/docs/v3.5/op-guide/maintenance/#auto-compaction. It has no any benefit other than confusing the end users. Instead, we just need to summarize the latest behaviour.
If users still need to look into the historical behavior, they just need to look at 3.4 or older version's document.
The text was updated successfully, but these errors were encountered: