Re: question about mirror maker
if placing mirror maker in the same datacenter as target cluster, it/consumer will talks to zookeeper in remote/source datacenter. would it more susceptible to network problems? As for the problem commit offset without actually producing/writing msgs to target cluster, it can be solved by disabling auto-commit. and only commit msgs that are actually persisted in target cluster. what do you think of this opposite approach? On Sun, May 11, 2014 at 8:48 PM, Todd Palino tpal...@linkedin.com wrote: Yes, on both counts. Putting the mirror maker in the same datacenter in the target cluster is exactly what we do as well. We also monitor both the consumer lag (by comparing the offsets stored in Zookeeper and the tail offset on the brokers), and the number of dropped and failed messages on the mirror maker producer side. The other thing to do is to make sure to check very carefully when you are changing anything about the producer configuration, to assure that you have not made a mistake. -Todd On 5/11/14, 9:12 AM, Weide Zhang weo...@gmail.com wrote: Hi Todd, Thanks for your answer. with regard to fail over for mirror maker, does that mean if i have 4 mirror maker running in different machines with same consumer group, it will auto load balance if one of the mirror maker fails ? Also, it looks to prevent mirror maker commit wrong (consumer work but not producer) due to cross data center network issue, mirror maker need to be placed along with the target cluster so that this scenario is minimized ? On Sat, May 10, 2014 at 11:39 PM, Todd Palino tpal...@linkedin.com wrote: Well, if you have a cluster in each datacenter, all with the same topics, you can¹t just mirror the messages between them, as you will create a loop. The way we do it is to have a ³local² cluster and an ³aggregate² cluster. The local cluster has the data for only that datacenter. Then we run mirror makers that copy the messages from each of the local clusters into the aggregate cluster. Everything produces into the local clusters, and nothing produces into the aggregate clusters. In general, consumers consume from the aggregate cluster (unless they specifically want only local data). The mirror maker is as fault tolerant as any other consumer. That is, if a mirror maker goes down, the others configured with the same consumer group (we generally run at least 4 for any mirror maker, sometimes up to 10) will rebalance and start back up from the last committed offset. What you need to watch out for is if the mirror maker is unable to produce messages, for example, if the network goes down. If it can still consume messages, but cannot produce them, you will lose messages as the consumer will continue to commit offsets with no knowledge that the producer is failing. -Todd On 5/8/14, 11:20 AM, Weide Zhang weo...@gmail.com wrote: Hi, I have a question about mirror maker. say I have 3 data centers each producing topic 'A' with separate kafka cluster running. if 3 of the data need to be kept in sync with each other, shall i create 3 mirror maker in each data center to get the data from the other two ? also, it mentioned that mirror making is not fault tolerant ? so what will be the behavior of mirror consumer if it went down due to network and back up ? do they catch up with last offset from which they last mirror ? If so, is it enabled by default or I have to configure ? Thanks a lot, Weide
Re: question about mirror maker
Well, if you have a cluster in each datacenter, all with the same topics, you can¹t just mirror the messages between them, as you will create a loop. The way we do it is to have a ³local² cluster and an ³aggregate² cluster. The local cluster has the data for only that datacenter. Then we run mirror makers that copy the messages from each of the local clusters into the aggregate cluster. Everything produces into the local clusters, and nothing produces into the aggregate clusters. In general, consumers consume from the aggregate cluster (unless they specifically want only local data). The mirror maker is as fault tolerant as any other consumer. That is, if a mirror maker goes down, the others configured with the same consumer group (we generally run at least 4 for any mirror maker, sometimes up to 10) will rebalance and start back up from the last committed offset. What you need to watch out for is if the mirror maker is unable to produce messages, for example, if the network goes down. If it can still consume messages, but cannot produce them, you will lose messages as the consumer will continue to commit offsets with no knowledge that the producer is failing. -Todd On 5/8/14, 11:20 AM, Weide Zhang weo...@gmail.com wrote: Hi, I have a question about mirror maker. say I have 3 data centers each producing topic 'A' with separate kafka cluster running. if 3 of the data need to be kept in sync with each other, shall i create 3 mirror maker in each data center to get the data from the other two ? also, it mentioned that mirror making is not fault tolerant ? so what will be the behavior of mirror consumer if it went down due to network and back up ? do they catch up with last offset from which they last mirror ? If so, is it enabled by default or I have to configure ? Thanks a lot, Weide
Re: question about mirror maker
Hi Todd, Thanks for your answer. with regard to fail over for mirror maker, does that mean if i have 4 mirror maker running in different machines with same consumer group, it will auto load balance if one of the mirror maker fails ? Also, it looks to prevent mirror maker commit wrong (consumer work but not producer) due to cross data center network issue, mirror maker need to be placed along with the target cluster so that this scenario is minimized ? On Sat, May 10, 2014 at 11:39 PM, Todd Palino tpal...@linkedin.com wrote: Well, if you have a cluster in each datacenter, all with the same topics, you can¹t just mirror the messages between them, as you will create a loop. The way we do it is to have a ³local² cluster and an ³aggregate² cluster. The local cluster has the data for only that datacenter. Then we run mirror makers that copy the messages from each of the local clusters into the aggregate cluster. Everything produces into the local clusters, and nothing produces into the aggregate clusters. In general, consumers consume from the aggregate cluster (unless they specifically want only local data). The mirror maker is as fault tolerant as any other consumer. That is, if a mirror maker goes down, the others configured with the same consumer group (we generally run at least 4 for any mirror maker, sometimes up to 10) will rebalance and start back up from the last committed offset. What you need to watch out for is if the mirror maker is unable to produce messages, for example, if the network goes down. If it can still consume messages, but cannot produce them, you will lose messages as the consumer will continue to commit offsets with no knowledge that the producer is failing. -Todd On 5/8/14, 11:20 AM, Weide Zhang weo...@gmail.com wrote: Hi, I have a question about mirror maker. say I have 3 data centers each producing topic 'A' with separate kafka cluster running. if 3 of the data need to be kept in sync with each other, shall i create 3 mirror maker in each data center to get the data from the other two ? also, it mentioned that mirror making is not fault tolerant ? so what will be the behavior of mirror consumer if it went down due to network and back up ? do they catch up with last offset from which they last mirror ? If so, is it enabled by default or I have to configure ? Thanks a lot, Weide
question about mirror maker
Hi, I have a question about mirror maker. say I have 3 data centers each producing topic 'A' with separate kafka cluster running. if 3 of the data need to be kept in sync with each other, shall i create 3 mirror maker in each data center to get the data from the other two ? also, it mentioned that mirror making is not fault tolerant ? so what will be the behavior of mirror consumer if it went down due to network and back up ? do they catch up with last offset from which they last mirror ? If so, is it enabled by default or I have to configure ? Thanks a lot, Weide
