Makes sense. This is a non issue in 0.8, see this -
https://issues.apache.org/jira/browse/KAFKA-155#comment-13607766

Thanks,
Neha


On Wed, Mar 20, 2013 at 8:41 AM, Jason Rosenberg <j...@squareup.com> wrote:

> I think might be cool, would be to have a feature where by you can tell a
> broker to stop accepting new data produced to it, but still allow consumers
> to consume from it.
>
> That way, you can roll out new brokers to a cluster, turn off producing to
> the old nodes, then wait for the log retention period, and then remove the
> old nodes from the cluster.
>
> Does that make sense?  Could it be easily done?
>
> Or is all this a non-issue anyway in 0.8?
>
> Maybe I should just wait for 0.8 to be ready, before doing my migration
> anyway.....
>
> Jason
>
> On Wed, Mar 20, 2013 at 6:42 AM, Neha Narkhede <neha.narkh...@gmail.com
> >wrote:
>
> > The zookeeper connection URL with namespace can be
> > zkhost1:123,zkhost2:123/newnamespace
> >
> > The wiki is up to date for Kafka 0.7.2. There is no officially supported
> > feature to do that sort of migration, I suggested one approach that I
> could
> > think of :-)
> >
> > Thanks,
> > Neha
> >
> > On Tuesday, March 19, 2013, Jason Rosenberg wrote:
> >
> > > I can do most of that I presume.
> > >
> > > It looks like to set up a separate namespace for zk, I can add /path at
> > the
> > > end of each node:port in my zkconnect string, e.g.:
> > >  zkhost1:123/newnamespace,zkhost2:123/newnamespace
> > > right?
> > >
> > > For mirroring, there's some vague documentation here:
> > > https://cwiki.apache.org/KAFKA/kafka-mirroring-mirrormaker.html
> > > Is this the most up to date approach for 0.7.2?  Set up a MirrorMaker
> > > intermediate process that consumes from the old and produces to the
> new?
> > >
> > > I am not able to restart producers one by one (as there are many, on a
> > > rather asynchronous update/restart cycle).  But I can eventually get
> them
> > > migrated over, etc.
> > >
> > > Jason
> > >
> > > On Tue, Mar 19, 2013 at 7:07 PM, Neha Narkhede <
> neha.narkh...@gmail.com
> > <javascript:;>
> > > >wrote:
> > >
> > > > Can you do the following -
> > > >
> > > > 1. Start a mirror Kafka cluster with the new version on a separate
> > > > zookeeper namespace. Configure this to mirror data from the existing
> > > kafka
> > > > cluster.
> > > > 2. Move your consumers to pull data from the mirror
> > > > 3. For each producer, one at a time, change the zookeeper namespace
> to
> > > > point to the mirror and restart the producer.
> > > > 4. Once the producers have moved to mirror cluster, shutdown
> mirroring
> > > and
> > > > old cluster.
> > > >
> > > > Thanks,
> > > > Neha
> > > >
> > > > On Tuesday, March 19, 2013, Jason Rosenberg wrote:
> > > >
> > > > > I need to upgrade some kafka broker servers.  So I need to
> seamlessly
> > > > > migrate traffic from the old brokers to the new ones, without
> losing
> > > > data,
> > > > > and without stopping producers.  I can temporarily stop consumers,
> > etc.
> > > > >
> > > > > Is there a strategy for this?
> > > > >
> > > > > Also, because of the way we are embedding kafka in our framework,
> our
> > > > > brokerId's are auto-generated (based on hostname, etc.), so I can't
> > > > simply
> > > > > copy over broker log files, etc., by transferring an old brokerId
> to
> > a
> > > > new
> > > > > host.
> > > > >
> > > > > Is there a way to change the view of the cluster from the
> producer's
> > > > > standpoint, without doing so from the consumers standpoint?  That
> > way,
> > > > the
> > > > > producers can start writing to the new brokers, while the consumers
> > > drain
> > > > > all data from the old brokers before switching to the new brokers.
> > > > >
> > > > > I don't actually care about ordering of messages, since the
> consumers
> > > are
> > > > > publishing them to a store that will index them properly based on
> > > source
> > > > > timestamp, etc.
> > > > >
> > > > > We are using zk for both producers and consumers connections.
> > > > >
> > > > > This is using 0.7.2.  I assume in 0.8 it will be easier, since with
> > > > > replication, you can phase in the new servers gradually, etc., no?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jason
> > > > >
> > > >
> > >
> >
>

Reply via email to