-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any chance for replication factor > 1 support? #9
Comments
We currently does not have plans for it as we have stopped using replication factor quite a while ago. We are running setup where carbon-c-relay create multiple copies of the same metrics. This gives us more predictability for their placement on a stores, and more predictable failure scenario when you have more than one store failure. Another pros will be back-filling of data after a failure. With replication factor = 1 and equally sized rings it easy to find the source host for back-fill. |
@azhiltsov That sounds interesting. Could you elaborate a bit on your setup? Do you have multiple carbon clusters for that copy-based "replication"? |
https://fosdem.org/2017/schedule/event/graphite_at_scale/ - there are more information there. But TLDR:
You can think about that as about Raid5 vs. Raid10, with an exception that if you'll loose n+1 server when you have RF= n you won't loose all the data, but only portion of it. |
@aptituz our carbon-c-relay config snippet would look like this:
the 'match' section above is what actually creates two replicas. |
And how is this handled on the other side of the stack? Is graphite-web/carbonapi/carbonzipper or whatever is used to query the data just configured to use the hosts of both clusters? |
You just query all the servers from a carbonzipper. |
Thanks! :) |
So happy to see someone has picked up the project. Wondering if supporting replication is on the roadmap.
The text was updated successfully, but these errors were encountered: