3 ms·
I've never used Kafka but this post is yet another hard earned lesson in log replication systems where storage tiering should be much higher on the hierarchy o
by rubiquity 5y ago
I've never used Kafka but this post is yet another hard earned lesson in log replication systems where storage tiering should be much higher on the hierarchy of needs than horizontal scaling of individual logs/topics/streams. In my experience the times when you need storage tiering something awful is already happening.
During network partitions or other scenarios where your disks are filling up quickly it's much easier to reason about how to get your log healthy by aggressively offloading to tiered storage and trimming than it is to re-partition (read: reconfigure), which often requires writes to some consensus-backed metadata store, which is also likely experiencing its own issues at that time.
Another great benefit of storage tiering is that you can externally communicate a shorter data retention period than you actually have in practice, while you really put your recovery and replay systems through their paces to get the confidence you need. Tiered storage can also be a great place to bootstrap new nodes from.
- gkop 5y agoCan you link a good article on storage tiering for Kafka?
- lizthegrey 5y agoThe current OSS work is happening here: https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A... The proprietary Confluent stuff is here: https://www.confluent.io/blog/infinite-kafka-storage-in-confluent-platform/ https://www.confluent.io/blog/infinite-kafka-storage-in-conf...