Replies: 1 comment
-
|
The connect.protocol configuration determines how the Connect cluster underneath MirrorMaker2 will act when the number of Connect workers or the number of runnings connectors and tasks changes. With eager all processing is stopped until the workload is redistributed, with sessioned and compatible the redistribution is done incrementally which means it impacts the existing workloads less. Between sessioned and compatible, sessioned is newer and more secure. The Kafka KIP explains in more detail https://cwiki.apache.org/confluence/display/KAFKA/KIP-415%3A+Incremental+Cooperative+Rebalancing+in+Kafka+Connect |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Strimzi mirrormaker2 has parameter connect.protocol which takes values compatible or sessioned or eager. In 3 site mirror make geo redundancy task distribution using kaka connect some times causing cpu load uneven during task execution
By configuring connect.protocol in mirrormaker2 to eager helping to balance the tasks and cpu load also not increasing and it maintained well. What are the implication of connect.protocol when it is configured in mirror maker spec
Beta Was this translation helpful? Give feedback.
All reactions