ticdc: add description about ticdc new architecture

TOC.md

@@ -187,7 +187,9 @@
     - [与 Confluent Cloud 和 Snowflake 进行数据集成](/ticdc/integrate-confluent-using-ticdc.md)
     - [与 Apache Kafka 和 Apache Flink 进行数据集成](/replicate-data-to-kafka.md)
   - 参考指南
-    - [TiCDC 架构设计与原理](/ticdc/ticdc-architecture.md)
+    - TiCDC 架构设计与原理
+      - [TiCDC 新架构](/ticdc/ticdc-architecture.md)
+      - [TiCDC 老架构](/ticdc/ticdc-classic-architecture.md)
     - [TiCDC 数据同步能力详解](/ticdc/ticdc-data-replication-capabilities.md)
     - [TiCDC Server 配置参数](/ticdc/ticdc-server-config.md)
     - [TiCDC Changefeed 配置参数](/ticdc/ticdc-changefeed-config.md)

br/backup-and-restore-overview.md

@@ -119,7 +119,7 @@ TiDB 支持将数据备份到 Amazon S3、Google Cloud Storage (GCS)、Azure Blo
 | New collation  | [#352](https://github.com/pingcap/br/issues/352)       | 确保恢复时集群的 `mysql.tidb` 表中 `new_collation_enabled` 变量值和备份时的一致，否则会导致数据索引不一致和 checksum 通不过。更多信息，请参考 [FAQ - BR 为什么会报 `new_collations_enabled_on_first_bootstrap` 不匹配？](/faq/backup-and-restore-faq.md#恢复时为什么会报-new_collation_enabled-不匹配)。 |
 | 全局临时表 | | 确保使用 BR v5.3.0 及以上版本进行备份和恢复，否则会导致全局临时表的表定义错误。 |
 | TiDB Lightning 物理导入模式| |上游数据库使用 TiDB Lightning 物理导入模式导入的数据，无法作为数据日志备份下来。推荐在数据导入后执行一次全量备份，细节参考[上游数据库使用 TiDB Lightning 物理导入模式导入数据的恢复](/faq/backup-and-restore-faq.md#上游数据库使用-tidb-lightning-物理导入模式导入数据时为什么无法使用日志备份功能)。|
-| TiCDC | | BR v8.2.0 及以上版本：如果在恢复的目标集群有 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts) 早于 BackupTS 的 Changefeed，BR 会拒绝执行恢复。BR v8.2.0 之前的版本：如果在恢复的目标集群有任何活跃的 TiCDC Changefeed，BR 会拒绝执行恢复。 |
+| TiCDC | | BR v8.2.0 及以上版本：如果在恢复的目标集群有 [CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts) 早于 BackupTS 的 Changefeed，BR 会拒绝执行恢复。BR v8.2.0 之前的版本：如果在恢复的目标集群有任何活跃的 TiCDC Changefeed，BR 会拒绝执行恢复。 |
 | 向量搜索 | | 确保使用 BR v8.4.0 及以上版本进行备份与恢复。不支持将带有[向量数据类型](/vector-search/vector-search-data-types.md)的表恢复至 v8.4.0 之前的 TiDB 集群。 |
 
 ### 版本间兼容性

releases/release-8.2.0.md

@@ -163,7 +163,7 @@ TiDB 版本：8.2.0
 
 * 使用 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) 导入 CSV 文件时，如果指定 `SPLIT_FILE` 参数将一个大 CSV 文件切分为多个小 CSV 文件来提升并发和导入性能，需显式指定行结束符 `LINES_TERMINATED_BY`，参数的取值为 `\r`、`\n` 或 `\r\n`。如果没有指定行结束符，可能导致 CSV 文件数据解析异常。[#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716)
 
-* 在 BR v8.2.0 之前的版本中，当集群存在 TiCDC 同步任务时，BR 不支持进行[数据恢复](/br/backup-and-restore-overview.md)。从 BR 8.2.0 起，BR 数据恢复对 TiCDC 的限制被放宽：如果所恢复数据的 BackupTS（即备份时间）早于 Changefeed 的 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts)（即记录当前同步进度的时间戳），BR 数据恢复可以正常进行。考虑到 BackupTS 的时间通常较早，此时可以认为绝大部分场景下，当集群存在 TiCDC 同步任务时，BR 都可以进行数据恢复。[#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen)
+* 在 BR v8.2.0 之前的版本中，当集群存在 TiCDC 同步任务时，BR 不支持进行[数据恢复](/br/backup-and-restore-overview.md)。从 BR 8.2.0 起，BR 数据恢复对 TiCDC 的限制被放宽：如果所恢复数据的 BackupTS（即备份时间）早于 Changefeed 的 [CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts)（即记录当前同步进度的时间戳），BR 数据恢复可以正常进行。考虑到 BackupTS 的时间通常较早，此时可以认为绝大部分场景下，当集群存在 TiCDC 同步任务时，BR 都可以进行数据恢复。[#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen)
 
 ### MySQL 兼容性
 
@@ -261,7 +261,7 @@ TiDB 版本：8.2.0
     + Backup & Restore (BR)
 
         - 优化备份功能，提升在大量表备份过程中遇到节点重启、扩容或网络抖动时的备份性能和稳定性 [#52534](https://github.com/pingcap/tidb/issues/52534) @[3pointer](https://github.com/3pointer)
-        - 优化恢复过程中对 TiCDC Changefeed 的细粒度检查，如果 Changefeed 的 [CheckpointTS](/ticdc/ticdc-architecture.md#checkpointts) 晚于数据的备份时间，则不会影响恢复操作，从而减少不必要的等待时间，提升用户体验 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen)
+        - 优化恢复过程中对 TiCDC Changefeed 的细粒度检查，如果 Changefeed 的 [CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts) 晚于数据的备份时间，则不会影响恢复操作，从而减少不必要的等待时间，提升用户体验 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen)
         - 为 [`BACKUP`](/sql-statements/sql-statement-backup.md) 语句和 [`RESTORE`](/sql-statements/sql-statement-restore.md) 语句添加了多个常用参数选项，例如 `CHECKSUM_CONCURRENCY` [#53040](https://github.com/pingcap/tidb/issues/53040) @[RidRisR](https://github.com/RidRisR)
         - 去掉除了 `br log restore` 子命令之外其它 `br log` 子命令对 TiDB `domain` 数据结构的载入，降低内存消耗 [#52088](https://github.com/pingcap/tidb/issues/52088) @[Leavrth](https://github.com/Leavrth)
         - 支持对日志备份过程中生成的临时文件进行加密 [#15083](https://github.com/tikv/tikv/issues/15083) @[YuJuncen](https://github.com/YuJuncen)

ticdc/monitor-ticdc.md

@@ -6,26 +6,134 @@ aliases: ['/zh/tidb/dev/ticdc-grafana-dashboard']
 
 # TiCDC 详细监控指标
 
-使用 TiUP 部署 TiDB 集群时，一键部署的监控系统面板包含 TiCDC 面板。本文档对 TiCDC 监控面板上的各项指标进行详细说明。在日常运维中，运维人员可通过观察 TiCDC 面板上的指标了解 TiCDC 当前的状态。
+本文档对 TiCDC 监控面板上的各项指标进行详细说明。在日常运维中，运维人员可通过观察 TiCDC 面板上的指标了解 TiCDC 当前的状态。
 
 本文档的对指标的介绍基于以下同步任务，即使用默认配置同步数据到 MySQL。
 
 ```shell
 cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://root:123456@127.0.0.1:3306/" --changefeed-id="simple-replication-task"
 ```
 
-下图显示了 TiCDC Dashboard 各监控面板：
+## TiCDC 新架构监控指标
 
-![TiCDC Dashboard - Overview](/media/ticdc/ticdc-dashboard-overview.png)
+[TiCDC 新架构](/ticdc/ticdc-architecture.md)的监控面板 **TiCDC-New-Arch** 暂时未集成到 TiUP 中。要在 Grafana 中查看相关监控信息，你需要手动导入 TiCDC 监控指标文件：
 
-各监控面板说明如下：
+1. 下载 TiCDC 新架构监控指标文件
+
+    ```shell
+    wget https://raw.githubusercontent.com/pingcap/ticdc/refs/heads/release-8.5/metrics/grafana/ticdc_new_arch.json
+    ```
+
+2. 在 Grafana 页面导入下载的监控指标文件
+
+    ![导入监控指标文件](/media/ticdc/ticdc-new-arch-import-grafana.png)
+
+TiCDC 新架构的监控面板主要包括以下部分：
+
+- [**Summary**](#summary-面板)：TiCDC 集群的概要信息
+- [**Server**](#server-面板)：TiDB 集群中 TiKV 节点和 TiCDC 节点的概要信息
+- [**Log Puller**](#log-puller-面板)：TiCDC Log Puller 模块的详细信息
+- [**Event Store**](#event-store-面板)：TiCDC Event Store 模块的详细信息
+- [**Sink**](#sink-面板)：TiCDC Sink 模块的详细信息
+
+### Summary 面板
+
+**Summary** 面板示例如下：
+
+![Summary](/media/ticdc/ticdc-new-arch-metric-summary.png)
+
+**Summary** 面板的各指标说明如下：
+
+- Changefeed Checkpoint Lag：同步任务在下游与上游之间的时序差距
+- Changefeed ResolvedTs Lag：TiCDC 节点内部处理进度与上游数据库的时序差距
+- Upstream Write Bytes/s：上游数据库的写入吞吐量
+- TiCDC Input Bytes/s：TiCDC 每秒从上游接收的数据量
+- Sink Event Row Count/s：TiCDC 每秒向下游写入的数据行数
+- Sink Write Bytes/s：TiCDC 每秒向下游写入的数据量
+- The Status of Changefeeds：各 Changefeed 的状态
+- Table Dispatcher Count：各 Changefeed 对应的 Dispatcher 数量
+- Memory Quota：Event Collector 内存配额及使用量，使用量过大时会导致限流
+
+### Server 面板
+
+**Server** 面板示例如下：
+
+![Server](/media/ticdc/ticdc-new-arch-metric-server.png)
+
+**Server** 面板的各指标说明如下：
+
+- Uptime：TiKV 节点和 TiCDC 节点已经运行的时间
+- Goroutine Count：TiCDC 节点 Goroutine 的个数
+- Open FD Count：TiCDC 节点打开的文件句柄个数
+- CPU Usage：TiCDC 节点使用的 CPU
+- Memory Usage：TiCDC 节点使用的内存
+- Ownership History：TiCDC 集群中 Owner 节点的历史记录
+- PD Leader History：上游 TiDB 集群中 PD Leader 节点的历史记录
+
+### Log Puller 面板
+
+**Log Puller** 面板示例如下：
+
+![Log Puller](/media/ticdc/ticdc-new-arch-metric-log-puller.png)
+
+**Log Puller** 面板的各指标说明如下：
+
+- Input Events/s：TiCDC 每秒收到的事件数
+- Unresolved Region Request Count：TiCDC 已经发送但尚未完成的 Region 增量扫描请求数
+- Region Request Finish Scan Duration：Region 增量扫描的耗时
+- Subscribed Region Count：订阅的 Region 总数
+- Memory Quota：Log Puller 内存配额及使用量，使用量过大会导致限流
+- Resolved Ts Batch Size (Regions)：单个 Resolved Ts 事件包含的 Region 数量
+
+### Event Store 面板
+
+**Event Store** 面板示例如下：
+
+![Event Store](/media/ticdc/ticdc-new-arch-metric-event-store.png)
+
+**Event Store** 面板的各指标说明如下：
+
+- Resolved Ts Lag：Event Store 处理进度与上游数据库的时序差距
+- Register Dispatcher StartTs Lag：Dispatcher 注册请求的 StartTs 与当前时间点之间的时序差距
+- Subscriptions Resolved Ts Lag：Subscription 处理进度与上游数据库的时序差距
+- Subscriptions Data GC Lag：Subscription 数据 GC 进度与当前时间点的时序差距
+- Input Event Count/s：Event Store 每秒处理的事件数
+- Input Bytes/s：Event Store 每秒处理的数据量
+- Write Requests/s：Event Store 每秒执行的写入请求数量
+- Write Worker Busy Ratio：Event Store 写线程的 I/O 时间占总运行时间的比例
+- Compressed Rows/s：Event Store 每秒压缩的数据行数（仅当行大小超过设定阈值时触发压缩）
+- Write Duration：Event Store 写入操作的耗时
+- Write Batch Size：单次写入操作的批量数据大小
+- Write Batch Event Count：单次写入批次中包含的行变更数
+- Data Size On Disk：Event Store 在磁盘上占用的数据总量
+- Data Size In Memory：Event Store 在内存中占用的数据总量
+- Scan Requests/s：Event Store 每秒执行的扫描请求数量
+- Scan Bytes/s：Event Store 每秒扫描的数据量
+
+### Sink 面板
+
+**Sink** 面板示例如下：
+
+![Sink](/media/ticdc/ticdc-new-arch-metric-sink.png)
+
+**Sink** 面板的各指标说明如下：
+
+- Output Row Batch Count：Sink 每批次写入 DML 的平均行数。
+- Output Row Count (per second)：每秒向下游写入的 DML 行数
+- Output DDL Executing Duration：当前节点上对应 Changefeed 执行 DDL Event 的耗时
+- Sink Error Count / m：Sink 模块每分钟的报错信息数量
+- Output DDL Count / Minutes：当前节点上对应 Changefeed 每分钟执行的 DDL 数量
+
+## TiCDC 老架构监控指标
+
+使用 TiUP 部署 TiDB 集群时，一键部署的监控系统面板包含 [TiCDC 老架构](/ticdc/ticdc-classic-architecture.md)监控面板。TiCDC 老架构主要监控面板说明如下：
 
 - [**Server**](#server-面板)：TiDB 集群中 TiKV 节点和 TiCDC 节点的概要信息
 - [**Changefeed**](#changefeed-面板)：TiCDC 同步任务的详细信息
 - [**Events**](#events-面板)：TiCDC 内部数据流转的详细信息
 - [**TiKV**](#tikv-面板)：TiKV 中和 TiCDC 相关的详细信息
 
-## Server 面板
+### Server 面板
 
 **Server** 面板示例如下：
 
@@ -41,7 +149,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro
 - CPU usage：TiCDC 节点使用的 CPU
 - Memory usage：TiCDC 节点使用的内存
 
-## Changefeed 面板
+### Changefeed 面板
 
 **Changefeed** 面板示例如下：
 
@@ -73,7 +181,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro
 
 - Changefeed catch-up ETA：同步完上游写入的数据所需时间的估计值。当上游的写入速度大于 TiCDC 同步速度时，该值可能会异常的大。（由于 TiCDC 的同步速度受到较多因素制约，因此该值仅供参考，不能完全代表实际所需的同步时间。）
 
-## Events 面板
+### Events 面板
 
 **Events** 面板示例如下：
 
@@ -103,7 +211,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro
 - KV client dispatch events/s：TiCDC 节点内部 KV client 模块每秒分发数据变更的个数
 - KV client batch resolved size：TiKV 批量发给 TiCDC 的 resolved ts 消息的大小
 
-## TiKV 面板
+### TiKV 面板
 
 **TiKV** 面板示例如下：