Altinity / Altinity/clickhouse-operator
feature request: read-only replicas service
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.6k
- Forks
- 574
- Avg merge
- 8d 6h
- Merged PRs (30d)
- 6
Description
It would be nice if there was a way in the Operator to define two separate sets of replicas. One for read-write usage, and one for read-only. While these would all be replicas, part of a single shard, and technically all be read-write (from what I understand), the operator could help here be placing specific read-only labels on the CHI that are for Select queries. Then a separate Kubernetes Service resource that only points to those CHI only could be used.
I know this a simple explanation, and gets more complex with multiple shards. There are some ways to do this in the existing operator, but a nice interface in the CRD would be great.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the existing Operator support for replica labels, CHI definitions, and generated Kubernetes Service resources. Trace how multiple shards are represented, then define the CRD and service behavior for separate read-write and read-only replica sets; done means the interface handles the stated multi-shard cases consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, go, kubernetes
- Domain
- databases, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100