Etcd key value store retention planning

[allahshukur-ahmadzada]

We are planning to use etcd as key value store based on following doc section. But it is not giving information about how we should calculate etcd retention/compaction time because while we test it after some time etcd grows and its restart takes long time. Anyone can help how we should calculate etcd compaction timing?

[pracucci]

I don't have much experience with etcd as backend for the ring, but at Grafana Labs we use etcd as backend for the HA deduplication and here is an example how we deploy it with the etcd operator:

mimir/operations/mimir-tests/test-defaults-generated.yaml

Lines 1141 to 1172 in 71c6b68

	apiVersion: etcd.database.coreos.com/v1beta2
	kind: EtcdCluster
	metadata:
	annotations:
	etcd.database.coreos.com/scope: clusterwide
	name: etcd
	namespace: default
	spec:
	pod:
	affinity:
	podAntiAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
	- labelSelector:
	matchLabels:
	etcd_cluster: etcd
	topologyKey: kubernetes.io/hostname
	annotations:
	prometheus.io/port: "2379"
	prometheus.io/scrape: "true"
	etcdEnv:
	- name: ETCD_AUTO_COMPACTION_RETENTION
	value: 1h
	labels:
	name: etcd
	resources:
	limits:
	memory: 512Mi
	requests:
	cpu: 500m
	memory: 512Mi
	size: 3
	version: 3.3.13

I think you may be particularly interested to this:

    - name: ETCD_AUTO_COMPACTION_RETENTION
      value: 1h