Summary
The architecture diagram on the CDC Overview page (milvus_cdc_overview.md) is out of sync with the page's own prose. The Markdown text already reflects the Milvus 2.6 built-in CDC (WAL forwarder, primary/standby clusters, ReplicateConfiguration), but the embedded image still shows the legacy standalone zilliztech/milvus-cdc service (HTTP Server + Task Executor + Reader/Writer corelib + etcd "Task Meta"). This inconsistency is confusing for users evaluating Milvus 2.6.
Where
What the Markdown says (correct, matches 2.6)
The prose describes "CDC node: A Milvus component that forwards WAL changes from the current primary to standby clusters" and references UpdateReplicateConfiguration, Switchover and Failover flows — all consistent with the in-tree CDC implementation under internal/cdc/ in milvus-io/milvus.
What the diagram shows (stale, matches 2.5)
The PNG still depicts an external service with:
- An HTTP Server in front of a "Task Executor"
- "Task Meta" stored in a CDC-owned etcd
- Reader/Writer "corelib" workers
- Consumer of source Milvus MQ
That topology matches the old zilliztech/milvus-cdc standalone service used with Milvus 2.5. In 2.6 the control plane is UpdateReplicateConfiguration exposed as a gRPC RPC on MilvusService (no HTTP/REST surface), and the dataplane is CreateReplicateStream between source-side CDC and target Proxy.
Suggested fix
Replace assets/cdc-overview.png with a diagram that matches the 2.6 architecture, e.g. (source Streaming Nodes → source CDC Nodes → ReplicateStream RPC → target Proxy → target Streaming Nodes → target WAL). The internal design doc milvus-design-docs/design_docs/cdc/user_docs/assets/cdc-replication-architecture.svg is a reasonable starting point.
Why it matters
Teams doing POC evaluation on Milvus 2.6 sometimes encounter the legacy diagram and conclude (incorrectly) that CDC still exposes an HTTP control-plane API. The Markdown is right; the image just needs to catch up.
Summary
The architecture diagram on the CDC Overview page (
milvus_cdc_overview.md) is out of sync with the page's own prose. The Markdown text already reflects the Milvus 2.6 built-in CDC (WAL forwarder, primary/standby clusters,ReplicateConfiguration), but the embedded image still shows the legacy standalonezilliztech/milvus-cdcservice (HTTP Server + Task Executor + Reader/Writer corelib + etcd "Task Meta"). This inconsistency is confusing for users evaluating Milvus 2.6.Where
site/en/userGuide/tools/milvus-cdc/milvus_cdc_overview.mdassets/cdc-overview.pngWhat the Markdown says (correct, matches 2.6)
The prose describes "CDC node: A Milvus component that forwards WAL changes from the current primary to standby clusters" and references
UpdateReplicateConfiguration,SwitchoverandFailoverflows — all consistent with the in-tree CDC implementation underinternal/cdc/inmilvus-io/milvus.What the diagram shows (stale, matches 2.5)
The PNG still depicts an external service with:
That topology matches the old
zilliztech/milvus-cdcstandalone service used with Milvus 2.5. In 2.6 the control plane isUpdateReplicateConfigurationexposed as a gRPC RPC onMilvusService(no HTTP/REST surface), and the dataplane isCreateReplicateStreambetween source-side CDC and target Proxy.Suggested fix
Replace
assets/cdc-overview.pngwith a diagram that matches the 2.6 architecture, e.g. (source Streaming Nodes → source CDC Nodes → ReplicateStream RPC → target Proxy → target Streaming Nodes → target WAL). The internal design docmilvus-design-docs/design_docs/cdc/user_docs/assets/cdc-replication-architecture.svgis a reasonable starting point.Why it matters
Teams doing POC evaluation on Milvus 2.6 sometimes encounter the legacy diagram and conclude (incorrectly) that CDC still exposes an HTTP control-plane API. The Markdown is right; the image just needs to catch up.