You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@kafka.apache.org by Péter Sinóros-Szabó <pe...@transferwise.com.INVALID> on 2020/01/08 12:58:43 UTC

Re: MM2 startup delay

Hey,

I did some further debugging on this.

I say that the following happened just before the real huge mirroring
traffic starts:

[2020-01-08 10:48:51,926] INFO Starting with 2294 previously uncommitted
partitions. (org.apache.kafka.connect.mirror.MirrorSourceTask:94)
[2020-01-08 10:48:51,928] INFO [Consumer clientId=consumer-11,
groupId=null] Seeking to offset 0 for partition ...

So I took a thread dump before that and I see that MirrorSourceConnector is
waiting on line 101 in OffsetStorageReaderImpl. It seems that it wait for
the offset backing store (kafka) to fill in the offsets. So it waits there
for minutes. I could not find out why, I hope someone has a clue what may
happen there.

We have about 2800 partitions.

Cheers,
Peter

On Mon, 9 Dec 2019 at 12:28, Péter Sinóros-Szabó <
peter.sinoros-szabo@transferwise.com> wrote:

> Hi,
>
> I am experimenting with Mirror Make 2 in 2.4.0-rc3. It seems to start up
> fine, connects to both source and destination, creates new topics...
> But it does not start to actually mirror the messages until about 12
> minutes after MM2 was started. I would expect it to start mirroring in some
> seconds after startup.
>
> Source cluster has about 2800 partitions, destination cluster is empty.
> Both clusters are in AWS but in different regions.
>
> What may cause the 12 minutes delay?
>
> Config is:
> ---
> clusters = eucmain, euwbackup
> eucmain.bootstrap.servers =
> test-kafka-main-fra01.xx:9092,test-kafka-main-fra02.xx:9092
> euwbackup.bootstrap.servers = 172.30.197.203:9092,172.30.213.104:9092
> eucmain->euwbackup.enabled = true
> eucmain->euwbackup.topics = .*
> eucmain->euwbackup.topics.blacklist = ^(kafka|kmf|__).*
> eucmain->euwbackup.rename.topics = false
> replication.policy.separator = __
> eucmain.client.id = mm2
>
> I do not see any serious errors in the logs that I would think of a cause
> of this.
>
> Thanks,
> Peter
>
>

-- 
 - Sini