Labels icon
Get icon
OutputValues icon
Fail icon
If icon
Commands icon
Docker icon
Log icon
LoopUntil icon
Exit icon
Pause icon
Set icon
Assert icon
SlackIncomingWebhook icon
Schedule icon

Migrate Kafka consumer groups to a new cluster with exact offsets after MirrorMaker 2

Move Kafka consumer groups to a MirrorMaker 2 target cluster with exact offsets. Prove the records match, approve, set the offsets, verify and roll back.

Categories
Data

MirrorMaker 2 copies topics and writes translated consumer group offsets to the new cluster, but the translation is conservative. On the test clusters it left one group 90 records behind the exact position and another 97 records behind when the target topic already held records. Consumers that start from those offsets read records twice. This flow checks that both clusters hold the same records, finds the exact offset for every committed offset and sets it after an approval.

How it works

  1. inspect compares topics, partition counts and the last record of every partition (timestamp, key and value hash) on both clusters. mode CHECK ends here.
  2. CUTOVER stops when a topic is missing on the target or a group still has members. quiet proves that the source end offsets do not move and wait_for_mirror waits until the last records match.
  3. align finds the target offset that follows the same record as each committed source offset. It tries the same offset first and then scans the target.
  4. approve_cutover (Pause) shows how many partitions move and how many records are not read twice. It asks you to confirm that the producers are stopped.
  5. The flow checks the source again, saves the old offsets in KV and runs apply, which sets the offsets and reads each one back. verify_cutover fails unless the record before every offset is the source record.
  6. ROLLBACK puts the saved offsets back where nobody moved them since.

What you get

Exact offsets on the new cluster with the proof for each partition. A group that is already ahead on the target is refused. The source cluster and its offsets are never changed.

Who it's for

Teams that move Kafka to a new cluster, a new version or another provider with MirrorMaker 2.

Why orchestrate this with Kestra

The Pause form shows the counts of the plan. The KV store keeps the old offsets and the state. A rerun reads the real offsets again and skips the exact ones.

Tested end to end

18 runs on Kestra 2.0.6 with Kafka 3.9.1 as the source and 4.1.0 as the target and MirrorMaker 2 4.1.0 with the identity policy. The flow validates clean on 2.0.5 but the runs were not repeated there. Covered: a missing topic, a producer that kept writing, a group with members, records that arrived during the approval, a target group with members, consumers that moved the offsets before a rollback and a group ahead on the target. SASL, TLS and transactions were not run.

Prerequisites

MirrorMaker 2 must already replicate the topics with the identity replication policy, so topic names match. Docker workers must reach both clusters.

Secrets

SLACK_WEBHOOK_URL. Client properties for SASL or TLS go into the two SECRET inputs.

Inputs

source_bootstrap and target_bootstrap. topics_regex and groups_regex choose what to compare and move. dry_run defaults to true and auto_remediate to false.

Quick start

  1. Run CHECK and read the tables.
  2. Run CUTOVER with the defaults to see the plan and the records you save.
  3. Stop the producers and the consumers, run it with dry_run false and auto_remediate true and approve.
  4. Start the consumers on the new cluster.

How to extend

Each record read starts a small JVM, so raise parallelism for big clusters. Keys that contain a pipe and binary values are compared as text. Add a notification in onPause.

Links

This blueprint was created by zkasuran.

See How

New to Kestra?

Use blueprints to kickstart your first workflows.