# CDC Changefeed Lag Keeps Increasing Due to TiKV Address Reuse

Source note: adapted from the Feishu `Storage oncall handbook` <https://pingcap.feishu.cn/wiki/RNzIwCexFiA1uXkRCvzcsIocnVb>.

- Phenomenon:
  - Changefeed lag keeps increasing after a TiKV scale-out or replacement event.
  - TiCDC reports store-version or store-metadata lookup failures for a store ID that no longer exists.
- Trigger / Preconditions:
  - A new TiKV node is started with the same address as a previously scaled-in TiKV node.
  - PD assigns the reused address a new `store_id`.
- Key logs:

```text
[2025/05/01 15:59:07.296 +08:00] [INFO] [shared_stream.go:93] ["event feed check store version fails"] [namespace=default] [changefeed=xxxx] [streamID=15] [storeID=6] [addr=10.107.4.96:20160] [error="[CDC:ErrGetAllStoresFailed]get stores from pd failed: type:UNKNOWN message:\"invalid store ID 6, not found\" "]
```

- Key metrics:
  - Changefeed lag continues to grow after topology change.
  - TiCDC health may remain degraded until metadata is refreshed.
- Root cause:
  - CDC continues to use the old `store_id` associated with the reused address.
  - PD correctly treats the replacement TiKV as a new store, but CDC metadata is stale and fetches the wrong store record.
- Workaround:
  - Restart the CDC node so it refreshes store metadata and rebuilds the correct mapping.
- Fixed version:
  - Refer to the upstream `tiflow#12162` fix status for the exact release line before relying on version-only mitigation.
- Related oncall:
  - v7.5.6 CDC sync stops after restart due to invalid PD endpoint used `APID-11856` / `GTOC-7966`