Hi Flavio, Comments below.
On Sat, Jun 18, 2016 at 4:50 PM, Flavio Junqueira <f...@apache.org> wrote: > For acls, you can simply re-run the acl command to re-introduce them, > unless you assume that no record of acls is maintained once they are > introduced. If that's the case, then another way is to simply read > periodically the zk state and keep that information somewhere else to be > extra safe. This seems easier than dealing with raw zk backups. Yes, I think it's not uncommon for users not to have a separate record of Kafka ACLs. It sounds like we need to improve our documentation to cover this area. For topic configs, we would need to contact servers to reconstruct the data. > That makes sense although the mechanism to do that is currently missing as far as I know. It is important to keep in mind that this happens quite rarely, though, and > if such a daunting scenario does happen, it is quite possible that > recovering the zk state is the least important of our problems. If you do > worry about losing too many replicas of anything, be it zk or kafka > brokers, to the point of not being able to recover, then it is indeed > important to have a plan to restore data. Typically we try to avoid these > scenarios by having enough replicas and making sure that we reduce the > chance of correlated events (e.g., by having remote replicas, rack > awareness), for some definition of enough. > Yes, agreed. As discussed offline, another scenario where backups (whether raw or by reading ZK state) or delayed replicas can help is in case of user error. An admin may incorrectly delete all ACLs, for example. One would hope this never happens, but apparently it does (a UK ISP once deleted gigabytes of customers' emails due to an admin error). Ismael
