diff --git a/TOC.md b/TOC.md index 5b15c8f5bb1a..2a093477a45b 100644 --- a/TOC.md +++ b/TOC.md @@ -484,14 +484,17 @@ - [概述](/ticdc/ticdc-overview.md) - [安装部署](/ticdc/deploy-ticdc.md) - [运维管理](/ticdc/manage-ticdc.md) - - [故障诊断](/ticdc/troubleshoot-ticdc.md) - - [监控指标](/ticdc/monitor-ticdc.md) - - [报警规则](/ticdc/ticdc-alert-rules.md) - - [TiCDC Open API](/ticdc/ticdc-open-api.md) - - [TiCDC Open Protocol](/ticdc/ticdc-open-protocol.md) - - [TiCDC Canal-JSON Protocol](/ticdc/ticdc-canal-json.md) - - [TiCDC Avro Protocol](/ticdc/ticdc-avro-protocol.md) - - [将 TiDB 集成到 Confluent Platform](/ticdc/integrate-confluent-using-ticdc.md) + - 监控告警 + - [监控指标](/ticdc/monitor-ticdc.md) + - [报警规则](/ticdc/ticdc-alert-rules.md) + - [故障处理](/ticdc/troubleshoot-ticdc.md) + - 参考指南 + - [TiCDC Open API](/ticdc/ticdc-open-api.md) + - [TiCDC Open Protocol](/ticdc/ticdc-open-protocol.md) + - [TiCDC Avro Protocol](/ticdc/ticdc-avro-protocol.md) + - [TiCDC Canal-JSON Protocol](/ticdc/ticdc-canal-json.md) + - [将 TiDB 集成到 Confluent Platform](/ticdc/integrate-confluent-using-ticdc.md) + - [常见问题解答](/ticdc/ticdc-faq.md) - [术语表](/ticdc/ticdc-glossary.md) - TiUniManager - [概述](/tiunimanager/tiunimanager-overview.md) diff --git a/_index.md b/_index.md index 6f5e9d458c79..b609e44f8f89 100644 --- a/_index.md +++ b/_index.md @@ -86,7 +86,7 @@ aliases: ['/docs-cn/dev/','/docs-cn/','/docs-cn/stable/'] - [SQL 诊断](/information-schema/information-schema-sql-diagnostics.md) - [热点问题处理](/troubleshoot-hot-spot-issues.md) - [磁盘 I/O 过高](/troubleshoot-high-disk-io.md) -- [TiCDC 常见问题](/ticdc/troubleshoot-ticdc.md) +- [TiCDC 故障处理](/ticdc/troubleshoot-ticdc.md) - [TiFlash 常见问题](/tiflash/troubleshoot-tiflash.md) diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md index b26e83c34db5..fcbea948c4fe 100644 --- a/faq/migration-tidb-faq.md +++ b/faq/migration-tidb-faq.md @@ -14,7 +14,7 @@ aliases: ['/docs-cn/dev/faq/migration-tidb-faq/'] - [TiDB Binlog 常见问题](/tidb-binlog/tidb-binlog-faq.md) - [TiDB Lightning 常见问题](/tidb-lightning/tidb-lightning-faq.md) - [Data Migration 常见问题](/dm/dm-faq.md) -- [TiCDC 常见问题和故障处理](/ticdc/troubleshoot-ticdc.md) +- [TiCDC 常见问题](/ticdc/ticdc-faq.md) ## 全量数据导出导入 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 680255b37cdd..6d8bec06fb55 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -236,7 +236,7 @@ aliases: ['/zh/tidb/dev/incremental-replication-between-clusters/'] 3. 重新开启 GC。 - TiCDC 可以保证 GC 只回收已经同步的历史数据。因此，创建完从上游到下游集群的 changefeed 之后，就可以执行如下命令恢复集群的垃圾回收功能。详情请参考 [TiCDC GC safepoint 的完整行为](/ticdc/troubleshoot-ticdc.md#ticdc-gc-safepoint-的完整行为是什么)。 + TiCDC 可以保证 GC 只回收已经同步的历史数据。因此，创建完从上游到下游集群的 changefeed 之后，就可以执行如下命令恢复集群的垃圾回收功能。详情请参考 [TiCDC GC safepoint 的完整行为](/ticdc/ticdc-faq.md#ticdc-gc-safepoint-的完整行为是什么)。 {{< copyable "sql" >}} diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index 308e39ff90aa..cdba1bd5305f 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -449,4 +449,5 @@ tiup cluster display tidb-test 如果你已同时部署了 [TiCDC](/ticdc/ticdc-overview.md)，接下来可参阅以下文档： - [TiCDC 任务管理](/ticdc/manage-ticdc.md) -- [TiCDC 常见问题](/ticdc/troubleshoot-ticdc.md) +- [TiCDC 故障处理](/ticdc/troubleshoot-ticdc.md) +- [TiCDC 常见问题](/ticdc/ticdc-faq.md) diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md index 662bf11d5af6..7b8dd6f0778b 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -255,7 +255,7 @@ summary: 了解如何配置一个 TiDB 集群以及该集群的 TiDB 或 MySQL 3. 重新开启 GC。 - TiCDC 可以保证未同步的历史数据不会被回收。因此，创建完从上游到下游集群的 changefeed 之后，就可以执行如下命令恢复集群的垃圾回收功能。详情请参考 [TiCDC GC safepoint 的完整行为](/ticdc/troubleshoot-ticdc.md#ticdc-gc-safepoint-的完整行为是什么)。 + TiCDC 可以保证未同步的历史数据不会被回收。因此，创建完从上游到下游集群的 changefeed 之后，就可以执行如下命令恢复集群的垃圾回收功能。详情请参考 [TiCDC GC safepoint 的完整行为](/ticdc/ticdc-faq.md#ticdc-gc-safepoint-的完整行为是什么)。 {{< copyable "sql" >}} diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index 920555930114..8c45c4a858dc 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -55,7 +55,7 @@ cdc server --pd=http://10.0.10.25:2379 --log-file=ticdc_3.log --addr=0.0.0.0:830 - `pd`：TiCDC 监听的 PD 节点地址，用 `,` 来分隔多个 PD 节点地址。 - `config`：可选项，表示 TiCDC 使用的配置文件地址。TiCDC 从 v5.0.0 开始支持该选项，TiUP 从 v1.4.0 开始支持在部署 TiCDC 时使用该配置。 - `data-dir`：指定 TiCDC 使用磁盘储存文件时的目录。目前 Unified Sorter 会使用该目录储存临时文件，建议确保该目录所在设备的可用空间大于等于 500 GiB。更详细的说明参见 [Unified Sorter](/ticdc/manage-ticdc.md#unified-sorter-功能)。对于使用 TiUP 的用户，本选项可以通过配置 [`cdc_servers`](/tiup/tiup-cluster-topology-reference.md#cdc_servers) 中的 `data_dir` 来指定或默认使用 `global` 中 `data_dir` 路径。 -- `gc-ttl`：TiCDC 在 PD 设置的服务级别 GC safepoint 的 TTL (Time To Live) 时长，和 TiCDC 同步任务所能够停滞的时长。单位为秒，默认值为 `86400`，即 24 小时。注意：TiCDC 同步任务的停滞会影响 TiCDC GC safepoint 的推进，即会影响上游 TiDB GC 的推进，详情可以参考 [TiCDC GC safepoint 的完整行为](/ticdc/troubleshoot-ticdc.md#ticdc-gc-safepoint-的完整行为是什么)。 +- `gc-ttl`：TiCDC 在 PD 设置的服务级别 GC safepoint 的 TTL (Time To Live) 时长，和 TiCDC 同步任务所能够停滞的时长。单位为秒，默认值为 `86400`，即 24 小时。注意：TiCDC 同步任务的停滞会影响 TiCDC GC safepoint 的推进，即会影响上游 TiDB GC 的推进，详情可以参考 [TiCDC GC safepoint 的完整行为](/ticdc/ticdc-faq.md#ticdc-gc-safepoint-的完整行为是什么)。 - `log-file`：TiCDC 进程运行时日志的输出地址，未设置时默认为标准输出 (stdout)。 - `log-level`：TiCDC 进程运行时的日志级别，默认为 `"info"`。 - `ca`：TiCDC 创建 TLS 连接时使用的 CA 证书文件路径，PEM 格式，可选。 diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index 9daed030851f..f424aa6644fd 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -23,7 +23,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 处理方法： - 参考 [`TiCDC 同步任务出现中断`](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断) 的处理方法。 + 参考 [TiCDC 同步任务出现中断](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断)的处理方法。 ### `cdc_resolvedts_high_delay` @@ -37,7 +37,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 处理方法： - 该告警与同步任务中断类似，可参考 [`TiCDC 同步任务出现中断`](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断) 的处理方法。 + 该告警与同步任务中断类似，可参考 [TiCDC 同步任务出现中断](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断)的处理方法。 ### `ticdc_processor_exit_with_error_count` @@ -51,7 +51,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 处理方法： - 参考 [`TiCDC 同步任务出现中断`](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断) 的处理方法。 + 参考 [TiCDC 同步任务出现中断](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断)的处理方法。 ## 警告级别报警项 @@ -111,7 +111,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 处理方法： - 参考 [`TiCDC 同步任务出现中断`](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断) 的处理方法。 + 参考 [TiCDC 同步任务出现中断](/ticdc/troubleshoot-ticdc.md#ticdc-同步任务出现中断)的处理方法。 ### `ticdc_puller_entry_sorter_sort_bucket` @@ -181,7 +181,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 处理方法： - MySQL 报错的情况较多，参考[`TiCDC 常见问题和故障处理`](/ticdc/troubleshoot-ticdc.md)。 + MySQL 报错的情况较多，参考 [TiCDC 故障处理](/ticdc/troubleshoot-ticdc.md)。 ### `ticdc_memory_abnormal` diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md new file mode 100644 index 000000000000..f2ae07ff544e --- /dev/null +++ b/ticdc/ticdc-faq.md @@ -0,0 +1,254 @@ +--- +title: TiCDC 常见问题解答 +summary: 了解 TiCDC 相关的常见问题。 +--- + +# TiCDC 常见问题解答 + +本文档总结了使用 TiCDC 时经常遇到的问题。 + +> **注意：** +> +> 本文档 `cdc cli` 命令中指定 PD 地址为 `--pd=http://10.0.10.25:2379`，用户在使用时需根据实际地址进行替换。 + +## TiCDC 创建任务时如何选择 start-ts？ + +首先需要理解同步任务的 `start-ts` 对应于上游 TiDB 集群的一个 TSO，同步任务会从这个 TSO 开始请求数据。所以同步任务的 `start-ts` 需要满足以下两个条件： + +- `start-ts` 的值需要大于 TiDB 集群当前的 `tikv_gc_safe_point`，否则创建任务时会报错。 +- 启动任务时，需要保证下游已经具有 `start-ts` 之前的所有数据。对于同步到消息队列等场景，如果不需要保证上下游数据的一致，可根据业务场景放宽此要求。 + +如果不指定 `start-ts` 或者指定 `start-ts=0`，在启动任务的时候会去 PD 获取一个当前 TSO，并从该 TSO 开始同步。 + +## 为什么 TiCDC 创建任务时提示部分表不能同步？ + +在使用 `cdc cli changefeed create` 创建同步任务时会检查上游表是否符合[同步限制](/ticdc/ticdc-overview.md#同步限制)。如果存在表不满足同步限制，会提示 `some tables are not eligible to replicate` 并列出这些不满足的表。用户选择 `Y` 或 `y` 则会继续创建同步任务，并且同步过程中自动忽略这些表的所有更新。用户选择其他输入，则不会创建同步任务。 + +## 如何查看 TiCDC 同步任务的状态？ + +可以使用 `cdc cli` 查询同步任务的状态。例如： + +{{< copyable "shell-regular" >}} + +```shell +cdc cli changefeed list --pd=http://10.0.10.25:2379 +``` + +上述命令输出如下： + +```json +[{ + "id": "4e24dde6-53c1-40b6-badf-63620e4940dc", + "summary": { + "state": "normal", + "tso": 417886179132964865, + "checkpoint": "2020-07-07 16:07:44.881", + "error": null + } +}] +``` + +* `checkpoint`：即为 TiCDC 已经将该时间点前的数据同步到了下游。 +* `state` 为该同步任务的状态： + * `normal`：正常同步。 + * `stopped`：停止同步（手动暂停或出错）。 + * `removed`：已删除任务。 + +> **注意：** +> +> 该功能在 TiCDC 4.0.3 版本引入。 + +## TiCDC 的 `gc-ttl` 是什么？ + +从 TiDB v4.0.0-rc.1 版本起，PD 支持外部服务设置服务级别 GC safepoint。任何一个服务可以注册更新自己服务的 GC safepoint。PD 会保证任何晚于该 GC safepoint 的 KV 数据不会在 TiKV 中被 GC 清理掉。 + +在 TiCDC 中启用了这一功能，用来保证 TiCDC 在不可用、或同步任务中断情况下，可以在 TiKV 内保留 TiCDC 需要消费的数据不被 GC 清理掉。 + +启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，也可以[通过 TiUP 修改](/ticdc/manage-ticdc.md#使用-tiup-修改-ticdc-配置) TiCDC 的 `gc-ttl`，默认值为 24 小时。在 TiCDC 中这个值有如下两重含义： + +- 当 TiCDC 服务全部停止后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间。 +- TiCDC 中某个同步任务中断或者被手动停止时所能停滞的最长时间，若同步任务停滞时间超过 `gc-ttl` 所设置的值，那么该同步任务就会进入 `failed` 状态，无法被恢复，并且不会继续影响 GC safepoint 的推进。 + +以上第二种行为是在 TiCDC v4.0.13 版本及之后版本中新增的。目的是为了防止 TiCDC 中某个同步任务停滞时间过长，导致上游 TiKV 集群的 GC safepoint 长时间不推进，保留的旧数据版本过多，进而影响上游集群性能。 + +> **注意：** +> +> 在某些应用场景中，比如使用 Dumpling/BR 全量同步后使用 TiCDC 接增量同步时，默认的 `gc-ttl` 为 24 小时可能无法满足需求。此时应该根据实际情况，在启动 TiCDC server 时指定 `gc-ttl` 的值。 + +## TiCDC GC safepoint 的完整行为是什么 + +TiCDC 服务启动后，如果有任务开始同步，TiCDC owner 会根据所有同步任务最小的 checkpoint-ts 更新到 PD service GC safepoint，service GC safepoint 可以保证该时间点及之后的数据不被 GC 清理掉。如果 TiCDC 中某个同步任务中断、或者被用户主动停止，则该任务的 checkpoint-ts 不会再改变，PD 对应的 service GC safepoint 最终会停滞在该任务的 checkpoint-ts 处不再更新。 + +如果该同步任务停滞的时间超过了 `gc-ttl` 指定的时长，那么该同步任务就会进入 `failed` 状态，并且无法被恢复，PD 对应的 service GC safepoint 就会继续推进。 + +TiCDC 为 service GC safepoint 设置的存活有效期为 24 小时，即 TiCDC 服务中断 24 小时内恢复能保证数据不因 GC 而丢失。 + +## 如何理解 TiCDC 时区和上下游数据库系统时区之间的关系？ + +||上游时区| TiCDC 时区| 下游时区 | +| :-: | :-: | :-: | :-: | +| 配置方式 | 见[时区支持](/configure-time-zone.md) | 启动 ticdc server 时的 `--tz` 参数 | sink-uri 中的 `time-zone` 参数 | +| 说明 | 上游 TiDB 的时区，影响 timestamp 类型的 DML 操作和与 timestamp 类型列相关的 DDL 操作。 | TiCDC 会将假设上游 TiDB 的时区和 TiCDC 时区配置相同，对 timestamp 类型的列进行相关处理。 | 下游 MySQL 将按照下游的时区设置对 DML 和 DDL 操作中包含的 timestamp 进行处理。| + +> **注意：** +> +> 请谨慎设置 TiCDC server 的时区，因为该时区会用于时间类型的转换。上游时区、TiCDC 时区和下游时区应该保持一致。TiCDC server 时区使用的优先级如下： +> +> - 最优先使用 `--tz` 传入的时区。 +> - 没有 `--tz` 参数，会尝试读取 `TZ` 环境变量设置的时区。 +> - 如果还没有 `TZ` 环境变量，会从 TiCDC server 运行机器的默认时区。 + +## 创建同步任务时，如果不指定 `--config` 配置文件，TiCDC 的默认的行为是什么？ + +在使用 `cdc cli changefeed create` 命令时如果不指定 `--config` 参数，TiCDC 会按照以下默认行为创建同步任务： + +* 同步所有的非系统表 +* 开启 old value 功能 +* 不同步不包含[有效索引](/ticdc/ticdc-overview.md#同步限制)的表 + +## TiCDC 是否支持输出 Canal 格式的变更数据？ + +支持。要开启 Canal 格式输出，只需在 `--sink-uri` 中指定 protocol 为 `canal` 即可，例如： + +{{< copyable "shell-regular" >}} + +```shell +cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="kafka://127.0.0.1:9092/cdc-test?kafka-version=2.4.0&protocol=canal" --config changefeed.toml +``` + +> **注意：** +> +> * 该功能在 TiCDC 4.0.2 版本引入。 +> * 目前 TiCDC 仅支持将 Canal 格式的变更数据输出到 MQ 类的 Sink（例如：Kafka，Pulsar）。 + +更多信息请参考[创建同步任务](/ticdc/manage-ticdc.md#创建同步任务)。 + +## 为什么 TiCDC 到 Kafka 的同步任务延时越来越大？ + +* 请参考[如何查看 TiCDC 同步任务的状态？](#如何查看-ticdc-同步任务的状态)检查下同步任务的状态是否正常。 +* 请适当调整 Kafka 的以下参数： + * `message.max.bytes`，将 Kafka 的 `server.properties` 中该参数调大到 `1073741824` (1 GB)。 + * `replica.fetch.max.bytes`，将 Kafka 的 `server.properties` 中该参数调大到 `1073741824` (1 GB)。 + * `fetch.message.max.bytes`，适当调大 `consumer.properties` 中该参数，确保大于 `message.max.bytes`。 + +## TiCDC 把数据同步到 Kafka 时，是把一个事务内的所有变更都写到一个消息中吗？如果不是，是根据什么划分的？ + +不是，根据配置的分发策略不同，有不同的划分方式，包括 `default`、`row id`、`table`、`ts`。更多请参考[同步任务配置文件描述](/ticdc/manage-ticdc.md#同步任务配置文件描述)。 + +## TiCDC 把数据同步到 Kafka 时，能在 TiDB 中控制单条消息大小的上限吗？ + +可以通过 `max-message-bytes` 控制每次向 Kafka broker 发送消息的最大数据量（可选，默认值 10MB）；通过 `max-batch-size` 参数指定每条 kafka 消息中变更记录的最大数量，目前仅对 Kafka 的 `protocol` 为 `open-protocol` 时有效（可选，默认值 `16`）。 + +## TiCDC 把数据同步到 Kafka 时，一条消息中会不会包含多种数据变更？ + +会，一条消息中可能出现多个 `update` 或 `delete`，`update` 和 `delete` 也有可能同时存在。 + +## TiCDC 把数据同步到 Kafka 时，如何查看 TiCDC Open protocol 输出变更数据中的时间戳、表名和库名？ + +这些信息包含在 Kafka 消息的 Key 中，比如： + +```json +{ + "ts":, + "scm":, + "tbl":, + "t":1 +} +``` + +更多信息请参考 [Open protocol Event 格式定义](/ticdc/ticdc-open-protocol.md#event-格式定义) + +## TiCDC 把数据同步到 Kafka 时，如何确定一条消息中包含的数据变更发生在哪个时间点？ + +把 Kafka 消息的 Key 中的 `ts` 右移 18 位即得 unix timestamp。 + +## TiCDC Open protocol 如何标示 null 值？ + +Open protocol 的输出中 type = 6 即为 null，比如： + +| 类型 | Code | 输出示例 | 说明 | +| :---------- | :--- | :------ | :-- | +| Null | 6 | `{"t":6,"v":null}` | | + +更多信息请参考 [Open protocol Event 格式定义](/ticdc/ticdc-open-protocol.md#column-的类型码)。 + +## 如何区分 TiCDC Open Protocol 中的 Row Changed Event 是 `INSERT` 事件还是 `UPDATE` 事件？ + +如果没有开启 Old Value 功能，用户无法区分 TiCDC Open Protocol 中的 Row Changed Event 是 `INSERT` 事件还是 `UPDATE` 事件。如果开启了 Old Value 功能，则可以通过事件中的字段判断事件类型： + +* 如果同时存在 `"p"` 和 `"u"` 字段为 `UPDATE` 事件 +* 如果只存在 `"u"` 字段则为 `INSERT` 事件 +* 如果只存在 `"d"` 字段则为 `DELETE` 事件 + +更多信息请参考 [Open protocol Row Changed Event 格式定义](/ticdc/ticdc-open-protocol.md#row-changed-event)。 + +## TiCDC 占用多少 PD 的存储空间 + +TiCDC 使用 PD 内部的 etcd 来存储元数据并定期更新。因为 etcd 的多版本并发控制 (MVCC) 以及 PD 默认的 compaction 间隔是 1 小时，TiCDC 占用的 PD 存储空间与 1 小时内元数据的版本数量成正比。在 v4.0.5、v4.0.6、v4.0.7 三个版本中 TiCDC 存在元数据写入频繁的问题，如果 1 小时内有 1000 张表创建或调度，就会用尽 etcd 的存储空间，出现 `etcdserver: mvcc: database space exceeded` 错误。出现这种错误后需要清理 etcd 存储空间，参考 [etcd maintaince space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。推荐使用这三个版本的用户升级到 v4.0.9 及以后版本。 + +## TiCDC 支持同步大事务吗？有什么风险吗？ + +TiCDC 对大事务（大小超过 5 GB）提供部分支持，根据场景不同可能存在以下风险： + ++ 当 TiCDC 内部处理能力不足时，可能出现同步任务报错 `ErrBufferReachLimit`。 ++ 当 TiCDC 内部处理能力不足或 TiCDC 下游吞吐能力不足时，可能出现内存溢出 (OOM)。 + +当遇到上述错误时，建议将包含大事务部分的增量数据通过 BR 进行增量恢复，具体操作如下： + +1. 记录因为大事务而终止的 changefeed 的 `checkpoint-ts`，将这个 TSO 作为 BR 增量备份的 `--lastbackupts`，并执行[增量备份](/br/br-usage-backup.md#备份-tidb-集群增量数据)。 +2. 增量备份结束后，可以在 BR 日志输出中找到类似 `["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]` 的日志，记录其中的 `BackupTS`。 +3. 执行[增量恢复](/br/br-usage-restore.md#恢复增量备份数据)。 +4. 建立一个新的 changefeed，从 `BackupTS` 开始同步任务。 +5. 删除旧的 changefeed。 + +## 同步 DDL 到下游 MySQL 5.7 时为什么时间类型字段默认值不一致？ + +比如上游 TiDB 的建表语句为 `create table test (id int primary key, ts timestamp)`，TiCDC 同步该语句到下游 MySQL 5.7，MySQL 使用默认配置，同步得到的表结构如下所示，timestamp 字段默认值会变成 `CURRENT_TIMESTAMP`： + +{{< copyable "sql" >}} + +```sql +mysql root@127.0.0.1:test> show create table test; ++-------+----------------------------------------------------------------------------------+ +| Table | Create Table | ++-------+----------------------------------------------------------------------------------+ +| test | CREATE TABLE `test` ( | +| | `id` int(11) NOT NULL, | +| | `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, | +| | PRIMARY KEY (`id`) | +| | ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | ++-------+----------------------------------------------------------------------------------+ +1 row in set +``` + +产生表结构不一致的原因是 `explicit_defaults_for_timestamp` 的[默认值在 TiDB 和 MySQL 5.7 不同](/mysql-compatibility.md#默认设置)。从 TiCDC v5.0.1/v4.0.13 版本开始，同步到 MySQL 会自动设置 session 变量 `explicit_defaults_for_timestamp = ON`，保证同步时间类型时上下游行为一致。对于 v5.0.1/v4.0.13 以前的版本，同步时间类型时需要注意 `explicit_defaults_for_timestamp` 默认值不同带来的兼容性问题。 + +## 使用 TiCDC 创建同步任务时将 `enable-old-value` 设置为 `true` 后，为什么上游的 `INSERT`/`UPDATE` 语句经 TiCDC 同步到下游后变为了 `REPLACE INTO`？ + +TiCDC 创建 changefeed 时会默认指定 `safe-mode` 为 `true`，从而为上游的 `INSERT`/`UPDATE` 语句生成 `REPLACE INTO` 的执行语句。 + +目前用户暂时无法修改 `safe-mode` 设置，因此该问题暂无解决办法。 + +## 数据同步下游的 Sink 为 TiDB 或 MySQL 时，下游数据库的用户需要哪些权限？ + +Sink 为 TiDB 或 MySQL 时，下游数据库的用户需要以下权限： + +- `Select` +- `Index` +- `Insert` +- `Update` +- `Delete` +- `Create` +- `Drop` +- `Alter` +- `Create View` + +如果要同步 `recover table` 到下游 TiDB，需要有 `Super` 权限。 + +## 为什么 TiCDC 需要使用磁盘，什么时候会写磁盘，TiCDC 能否利用内存缓存提升同步性能？ + +TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆积的数据。TiCDC 正常运行期间都需要写入磁盘，但这通常不是同步吞吐和同步延时的瓶颈，写磁盘对延时影响在百毫秒内。TiCDC 也利用了内存来提升加速读取磁盘中的数据，以提升同步性能。 + +## 为什么在使用了 TiDB Lightning 和 BR 恢复了数据之后，TiCDC 同步会出现卡顿甚至卡住？ + +目前 TiCDC 还没完全适配 TiDB Lightning 和 BR，请避免在使用 TiCDC 同步的表上使用 TiDB Lightning 和 BR。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 9a0b45f0767d..19cf7d4a19c1 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -91,7 +91,7 @@ TiCDC 从 4.0.8 版本开始，可通过修改任务配置来同步**没有有 - 暂不支持单独使用 RawKV 的 TiKV 集群。 - 暂不支持在 TiDB 中[创建 SEQUENCE 的 DDL 操作](/sql-statements/sql-statement-create-sequence.md)和 [SEQUENCE 函数](/sql-statements/sql-statement-create-sequence.md#sequence-函数)。在上游 TiDB 使用 SEQUENCE 时，TiCDC 将会忽略掉上游执行的 SEQUENCE DDL 操作/函数，但是使用 SEQUENCE 函数的 DML 操作可以正确地同步。 -- 对上游存在较大事务的场景提供部分支持，详见 [TiCDC 是否支持同步大事务？有什么风险吗？](/ticdc/troubleshoot-ticdc.md#ticdc-支持同步大事务吗有什么风险吗) +- 对上游存在较大事务的场景提供部分支持，详见 [TiCDC 是否支持同步大事务？有什么风险吗？](/ticdc/ticdc-faq.md#ticdc-支持同步大事务吗有什么风险吗) > **注意：** > @@ -153,6 +153,7 @@ TiCDC 从 v5.3.0 开始支持[全局临时表](/temporary-tables.md#全局临时 如果 TiCDC 的上游集群包含全局临时表，下游集群也必须是 TiDB 5.3.0 及以上版本，否则同步报错。 -## TiCDC 常见问题 +## TiCDC 常见问题与故障处理 -在使用 TiCDC 过程中经常遇到的问题以及相对应的解决方案请参考 [TiCDC 常见问题](/ticdc/troubleshoot-ticdc.md)。 +- 使用 TiCDC 过程中经常遇到的问题，请参考 [TiCDC 常见问题](/ticdc/troubleshoot-ticdc.md)。 +- 使用 TiCDC 过程中遇到的故障及解决，请参考 [TiCDC 故障处理](/ticdc/troubleshoot-ticdc.md)。 diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index bf6180ab500e..9e30b8397e8b 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -1,63 +1,17 @@ --- -title: TiCDC 常见问题和故障处理 +title: TiCDC 故障处理 +summary: 了解如何解决使用 TiCDC 时经常遇到的问题。 aliases: ['/docs-cn/dev/ticdc/troubleshoot-ticdc/','/docs-cn/dev/reference/tools/ticdc/troubleshoot/'] --- -# TiCDC 常见问题和故障处理 +# TiCDC 故障处理 -本文档总结了在使用 TiCDC 过程中经常遇到的问题，给出合适的运维方法。本文档还总结了常见的运行故障，并给出相对应的解决方案。 +本文档总结了使用 TiCDC 过程中常见的运行故障及解决方案。 > **注意：** > > 本文档 `cdc cli` 命令中指定 PD 地址为 `--pd=http://10.0.10.25:2379`，用户在使用时需根据实际地址进行替换。 -## TiCDC 创建任务时如何选择 start-ts？ - -首先需要理解同步任务的 `start-ts` 对应于上游 TiDB 集群的一个 TSO，同步任务会从这个 TSO 开始请求数据。所以同步任务的 `start-ts` 需要满足以下两个条件： - -- `start-ts` 的值需要大于 TiDB 集群当前的 `tikv_gc_safe_point`，否则创建任务时会报错。 -- 启动任务时，需要保证下游已经具有 `start-ts` 之前的所有数据。对于同步到消息队列等场景，如果不需要保证上下游数据的一致，可根据业务场景放宽此要求。 - -如果不指定 `start-ts` 或者指定 `start-ts=0`，在启动任务的时候会去 PD 获取一个当前 TSO，并从该 TSO 开始同步。 - -## 为什么 TiCDC 创建任务时提示部分表不能同步？ - -在使用 `cdc cli changefeed create` 创建同步任务时会检查上游表是否符合[同步限制](/ticdc/ticdc-overview.md#同步限制)。如果存在表不满足同步限制，会提示 `some tables are not eligible to replicate` 并列出这些不满足的表。用户选择 `Y` 或 `y` 则会继续创建同步任务，并且同步过程中自动忽略这些表的所有更新。用户选择其他输入，则不会创建同步任务。 - -## 如何查看 TiCDC 同步任务的状态？ - -可以使用 `cdc cli` 查询同步任务的状态。例如： - -{{< copyable "shell-regular" >}} - -```shell -cdc cli changefeed list --pd=http://10.0.10.25:2379 -``` - -上述命令输出如下： - -```json -[{ - "id": "4e24dde6-53c1-40b6-badf-63620e4940dc", - "summary": { - "state": "normal", - "tso": 417886179132964865, - "checkpoint": "2020-07-07 16:07:44.881", - "error": null - } -}] -``` - -* `checkpoint`：即为 TiCDC 已经将该时间点前的数据同步到了下游。 -* `state` 为该同步任务的状态： - * `normal`：正常同步。 - * `stopped`：停止同步（手动暂停或出错）。 - * `removed`：已删除任务。 - -> **注意：** -> -> 该功能在 TiCDC 4.0.3 版本引入。 - ## TiCDC 同步任务出现中断 ### 如何判断 TiCDC 同步任务出现中断？ @@ -79,10 +33,10 @@ cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id 28c43ffc-23 上述命令的输出中 `admin-job-type` 标志这个同步的任务的状态： -* `0`: 任务进行中，没有被人为停止。 -* `1`: 任务暂停，停止任务后所有同步 `processor` 会结束退出，同步任务的配置和同步状态都会保留，可以从 `checkpoint-ts` 恢复任务。 -* `2`: 任务恢复，同步任务从 `checkpoint-ts` 继续同步。 -* `3`: 任务已删除，接口请求后会结束所有同步 `processor`，并清理同步任务配置信息。同步状态保留，只提供查询，没有其他实际功能。 +- `0`: 任务进行中，没有被人为停止。 +- `1`: 任务暂停，停止任务后所有同步 `processor` 会结束退出，同步任务的配置和同步状态都会保留，可以从 `checkpoint-ts` 恢复任务。 +- `2`: 任务恢复，同步任务从 `checkpoint-ts` 继续同步。 +- `3`: 任务已删除，接口请求后会结束所有同步 `processor`，并清理同步任务配置信息。同步状态保留，只提供查询，没有其他实际功能。 ### 如何处理 TiCDC 同步任务的中断？ @@ -112,30 +66,6 @@ cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id 28c43ffc-23 升级 TiDB 集群和 TiCDC 集群到最新版本。该 OOM 问题在 **v4.0.14 及之后的 v4.0 版本，v5.0.2 及之后的 v5.0 版本，更新的版本**上已得到缓解。 -## TiCDC 的 `gc-ttl` 是什么？ - -从 TiDB v4.0.0-rc.1 版本起，PD 支持外部服务设置服务级别 GC safepoint。任何一个服务可以注册更新自己服务的 GC safepoint。PD 会保证任何晚于该 GC safepoint 的 KV 数据不会在 TiKV 中被 GC 清理掉。 - -在 TiCDC 中启用了这一功能，用来保证 TiCDC 在不可用、或同步任务中断情况下，可以在 TiKV 内保留 TiCDC 需要消费的数据不被 GC 清理掉。 - -启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，也可以[通过 TiUP 修改](/ticdc/manage-ticdc.md#使用-tiup-修改-ticdc-配置) TiCDC 的 `gc-ttl`，默认值为 24 小时。在 TiCDC 中这个值有如下两重含义： - -- 当 TiCDC 服务全部停止后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间。 -- TiCDC 中某个同步任务中断或者被手动停止时所能停滞的最长时间，若同步任务停滞时间超过 `gc-ttl` 所设置的值，那么该同步任务就会进入 `failed` 状态，无法被恢复，并且不会继续影响 GC safepoint 的推进。 - -以上第二种行为是在 TiCDC v4.0.13 版本及之后版本中新增的。目的是为了防止 TiCDC 中某个同步任务停滞时间过长，导致上游 TiKV 集群的 GC safepoint 长时间不推进，保留的旧数据版本过多，进而影响上游集群性能。 - -> **注意** -> 在某些应用场景中，比如使用 Dumpling/BR 全量同步后使用 TiCDC 接增量同步时，默认的 `gc-ttl` 为 24 小时可能无法满足需求。此时应该根据实际情况，在启动 TiCDC server 时指定 `gc-ttl` 的值。 - -## TiCDC GC safepoint 的完整行为是什么 - -TiCDC 服务启动后，如果有任务开始同步，TiCDC owner 会根据所有同步任务最小的 checkpoint-ts 更新到 PD service GC safepoint，service GC safepoint 可以保证该时间点及之后的数据不被 GC 清理掉。如果 TiCDC 中某个同步任务中断、或者被用户主动停止，则该任务的 checkpoint-ts 不会再改变，PD 对应的 service GC safepoint 最终会停滞在该任务的 checkpoint-ts 处不再更新。 - -如果该同步任务停滞的时间超过了 `gc-ttl` 指定的时长，那么该同步任务就会进入 `failed` 状态，并且无法被恢复，PD 对应的 service GC safepoint 就会继续推进。 - -TiCDC 为 service GC safepoint 设置的存活有效期为 24 小时，即 TiCDC 服务中断 24 小时内恢复能保证数据不因 GC 而丢失。 - ## 如何处理 TiCDC 创建同步任务或同步到 MySQL 时遇到 `Error 1298: Unknown or incorrect time zone: 'UTC'` 错误？ 这是因为下游 MySQL 没有加载时区，可以通过 [mysql_tzinfo_to_sql](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html) 命令加载时区，加载后就可以正常创建任务或同步任务。 @@ -192,132 +122,14 @@ cdc cli changefeed create --sink-uri="mysql://root@127.0.0.1:3306/?time-zone=CST > > 在中国，CST 通常表示中国标准时间，使用时请注意甄别。 -## 如何理解 TiCDC 时区和上下游数据库系统时区之间的关系？ - -||上游时区| TiCDC 时区| 下游时区 | -| :-: | :-: | :-: | :-: | -| 配置方式 | 见[时区支持](/configure-time-zone.md) | 启动 ticdc server 时的 `--tz` 参数 | sink-uri 中的 `time-zone` 参数 | -| 说明 | 上游 TiDB 的时区，影响 timestamp 类型的 DML 操作和与 timestamp 类型列相关的 DDL 操作。 | TiCDC 会将假设上游 TiDB 的时区和 TiCDC 时区配置相同，对 timestamp 类型的列进行相关处理。 | 下游 MySQL 将按照下游的时区设置对 DML 和 DDL 操作中包含的 timestamp 进行处理。| - -> **注意：** -> -> 请谨慎设置 TiCDC server 的时区，因为该时区会用于时间类型的转换。上游时区、TiCDC 时区和下游时区应该保持一致。TiCDC server 时区使用的优先级如下： -> -> - 最优先使用 `--tz` 传入的时区。 -> - 没有 `--tz` 参数，会尝试读取 `TZ` 环境变量设置的时区。 -> - 如果还没有 `TZ` 环境变量，会从 TiCDC server 运行机器的默认时区。 - -## 创建同步任务时，如果不指定 `--config` 配置文件，TiCDC 的默认的行为是什么？ - -在使用 `cdc cli changefeed create` 命令时如果不指定 `--config` 参数，TiCDC 会按照以下默认行为创建同步任务： - -* 同步所有的非系统表 -* 开启 old value 功能 -* 不同步不包含[有效索引](/ticdc/ticdc-overview.md#同步限制)的表 - ## 如何处理升级 TiCDC 后配置文件不兼容的问题？ 请参阅[配置文件兼容注意事项](/ticdc/manage-ticdc.md#配置文件兼容性的注意事项)。 -## TiCDC 是否支持输出 Canal 格式的变更数据？ - -支持。要开启 Canal 格式输出，只需在 `--sink-uri` 中指定 protocol 为 `canal` 即可，例如： - -{{< copyable "shell-regular" >}} - -```shell -cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="kafka://127.0.0.1:9092/cdc-test?kafka-version=2.4.0&protocol=canal" --config changefeed.toml -``` - -> **注意：** -> -> * 该功能在 TiCDC 4.0.2 版本引入。 -> * 目前 TiCDC 仅支持将 Canal 格式的变更数据输出到 MQ 类的 Sink（例如：Kafka，Pulsar）。 - -更多信息请参考[创建同步任务](/ticdc/manage-ticdc.md#创建同步任务)。 - -## 为什么 TiCDC 到 Kafka 的同步任务延时越来越大？ - -* 请参考[如何查看 TiCDC 同步任务的状态？](/ticdc/troubleshoot-ticdc.md#如何查看-ticdc-同步任务的状态)检查下同步任务的状态是否正常。 -* 请适当调整 Kafka 的以下参数： - * `message.max.bytes`，将 Kafka 的 `server.properties` 中该参数调大到 `1073741824` (1 GB)。 - * `replica.fetch.max.bytes`，将 Kafka 的 `server.properties` 中该参数调大到 `1073741824` (1 GB)。 - * `fetch.message.max.bytes`，适当调大 `consumer.properties` 中该参数，确保大于 `message.max.bytes`。 - -## TiCDC 把数据同步到 Kafka 时，是把一个事务内的所有变更都写到一个消息中吗？如果不是，是根据什么划分的？ - -不是，根据配置的分发策略不同，有不同的划分方式，包括 `default`、`row id`、`table`、`ts`。更多请参考[同步任务配置文件描述](/ticdc/manage-ticdc.md#同步任务配置文件描述)。 - -## TiCDC 把数据同步到 Kafka 时，能在 TiDB 中控制单条消息大小的上限吗？ - -可以通过 `max-message-bytes` 控制每次向 Kafka broker 发送消息的最大数据量（可选，默认值 10MB）；通过 `max-batch-size` 参数指定每条 kafka 消息中变更记录的最大数量，目前仅对 Kafka 的 `protocol` 为 `open-protocol` 时有效（可选，默认值 `16`）。 - -## TiCDC 把数据同步到 Kafka 时，一条消息中会不会包含多种数据变更？ - -会，一条消息中可能出现多个 `update` 或 `delete`，`update` 和 `delete` 也有可能同时存在。 - -## TiCDC 把数据同步到 Kafka 时，如何查看 TiCDC Open protocol 输出变更数据中的时间戳、表名和库名？ - -这些信息包含在 Kafka 消息的 Key 中，比如： - -```json -{ - "ts":, - "scm":, - "tbl":
, - "t":1 -} -``` - -更多信息请参考 [Open protocol Event 格式定义](/ticdc/ticdc-open-protocol.md#event-格式定义) - -## TiCDC 把数据同步到 Kafka 时，如何确定一条消息中包含的数据变更发生在哪个时间点？ - -把 Kafka 消息的 Key 中的 `ts` 右移 18 位即得 unix timestamp。 - -## TiCDC Open protocol 如何标示 null 值？ - -Open protocol 的输出中 type = 6 即为 null，比如： - -| 类型 | Code | 输出示例 | 说明 | -| :---------- | :--- | :------ | :-- | -| Null | 6 | `{"t":6,"v":null}` | | - -更多信息请参考 [Open protocol Event 格式定义](/ticdc/ticdc-open-protocol.md#column-的类型码)。 - ## TiCDC 启动任务的 start-ts 时间戳与当前时间差距较大，任务执行过程中同步中断，出现错误 `[CDC:ErrBufferReachLimit]`，怎么办？ 自 v4.0.9 起可以尝试开启 unified sorter 特性进行同步；或者使用 BR 工具进行一次增量备份和恢复，然后从新的时间点开启 TiCDC 同步任务。TiCDC 将会在后续版本中对该问题进行优化。 -## 如何区分 TiCDC Open Protocol 中的 Row Changed Event 是 `INSERT` 事件还是 `UPDATE` 事件？ - -如果没有开启 Old Value 功能，用户无法区分 TiCDC Open Protocol 中的 Row Changed Event 是 `INSERT` 事件还是 `UPDATE` 事件。如果开启了 Old Value 功能，则可以通过事件中的字段判断事件类型： - -* 如果同时存在 `"p"` 和 `"u"` 字段为 `UPDATE` 事件 -* 如果只存在 `"u"` 字段则为 `INSERT` 事件 -* 如果只存在 `"d"` 字段则为 `DELETE` 事件 - -更多信息请参考 [Open protocol Row Changed Event 格式定义](/ticdc/ticdc-open-protocol.md#row-changed-event)。 - -## TiCDC 占用多少 PD 的存储空间 - -TiCDC 使用 PD 内部的 etcd 来存储元数据并定期更新。因为 etcd 的多版本并发控制 (MVCC) 以及 PD 默认的 compaction 间隔是 1 小时，TiCDC 占用的 PD 存储空间与 1 小时内元数据的版本数量成正比。在 v4.0.5、v4.0.6、v4.0.7 三个版本中 TiCDC 存在元数据写入频繁的问题，如果 1 小时内有 1000 张表创建或调度，就会用尽 etcd 的存储空间，出现 `etcdserver: mvcc: database space exceeded` 错误。出现这种错误后需要清理 etcd 存储空间，参考 [etcd maintaince space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。推荐使用这三个版本的用户升级到 v4.0.9 及以后版本。 - -## TiCDC 支持同步大事务吗？有什么风险吗？ - -TiCDC 对大事务（大小超过 5 GB）提供部分支持，根据场景不同可能存在以下风险： - -+ 当 TiCDC 内部处理能力不足时，可能出现同步任务报错 `ErrBufferReachLimit`。 -+ 当 TiCDC 内部处理能力不足或 TiCDC 下游吞吐能力不足时，可能出现内存溢出 (OOM)。 - -当遇到上述错误时，建议将包含大事务部分的增量数据通过 BR 进行增量恢复，具体操作如下： - -1. 记录因为大事务而终止的 changefeed 的 `checkpoint-ts`，将这个 TSO 作为 BR 增量备份的 `--lastbackupts`，并执行[增量备份](/br/br-usage-backup.md#备份-tidb-集群增量数据)。 -2. 增量备份结束后，可以在 BR 日志输出中找到类似 `["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]` 的日志，记录其中的 `BackupTS`。 -3. 执行[增量恢复](/br/br-usage-restore.md#恢复增量备份数据)。 -4. 建立一个新的 changefeed，从 `BackupTS` 开始同步任务。 -5. 删除旧的 changefeed。 - ## 当 changefeed 的下游为类 MySQL 数据库时，TiCDC 执行了一个耗时较长的 DDL 语句，阻塞了所有其他 changefeed，应该怎样处理？ 1. 首先暂停执行耗时较长的 DDL 的 changefeed。此时可以观察到，这个 changefeed 暂停后，其他的 changefeed 不再阻塞了。 @@ -357,19 +169,13 @@ TiCDC 对大事务（大小超过 5 GB）提供部分支持，根据场景不同 ## 使用 TiCDC 创建 changefeed 时报错 `[tikv:9006]GC life time is shorter than transaction duration, transaction starts at xx, GC safe point is yy` -解决方案：需要执行 `pd-ctl service-gc-safepoint --pd ` 命令查询当前的 GC safepoint 与 service GC safepoint。如果 GC safepoint 小于 TiCDC changefeed 同步任务的开始时间戳 `start-ts`，则用户可以直接在 `cdc cli create changefeed` 命令后加上 `--disable-gc-check` 参数创建 changefeed。 +执行 `pd-ctl service-gc-safepoint --pd ` 命令查询当前的 GC safepoint 与 service GC safepoint。如果 GC safepoint 小于 TiCDC changefeed 同步任务的开始时间戳 `start-ts`，可以直接在 `cdc cli create changefeed` 命令后加上 `--disable-gc-check` 参数创建 changefeed。 如果 `pd-ctl service-gc-safepoint --pd ` 的结果中没有 `gc_worker service_id`： -+ 如果 PD 的版本 <= v4.0.8，详见 [PD issue #3128](https://github.com/tikv/pd/issues/3128)。 -+ 如果 PD 是由 v4.0.8 或更低版本滚动升级到新版，详见 [PD issue #3366](https://github.com/tikv/pd/issues/3366)。 -+ 对于其他情况，请将上述命令执行结果反馈到 [AskTUG 论坛](https://asktug.com/tags/ticdc)。 - -## 使用 TiCDC 创建同步任务时将 `enable-old-value` 设置为 `true` 后，为什么上游的 `INSERT`/`UPDATE` 语句经 TiCDC 同步到下游后变为了 `REPLACE INTO`？ - -TiCDC 创建 changefeed 时会默认指定 `safe-mode` 为 `true`，从而为上游的 `INSERT`/`UPDATE` 语句生成 `REPLACE INTO` 的执行语句。 - -目前用户暂时无法修改 `safe-mode` 设置，因此该问题暂无解决办法。 +- 如果 PD 的版本 <= v4.0.8，详见 [PD issue #3128](https://github.com/tikv/pd/issues/3128)。 +- 如果 PD 是由 v4.0.8 或更低版本滚动升级到新版，详见 [PD issue #3366](https://github.com/tikv/pd/issues/3366)。 +- 对于其他情况，请将上述命令执行结果反馈到 [AskTUG 论坛](https://asktug.com/tags/ticdc)。 ## 使用 TiCDC 同步消息到 Kafka 时 Kafka 报错 `Message was too large` @@ -403,49 +209,3 @@ cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --start-ts 4152 cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379 ``` - -## 同步 DDL 到下游 MySQL 5.7 时间类型字段默认值不一致 - -比如上游 TiDB 的建表语句为 `create table test (id int primary key, ts timestamp)`，TiCDC 同步该语句到下游 MySQL 5.7，MySQL 使用默认配置，同步得到的表结构如下所示，timestamp 字段默认值会变成 `CURRENT_TIMESTAMP`： - -{{< copyable "sql" >}} - -```sql -mysql root@127.0.0.1:test> show create table test; -+-------+----------------------------------------------------------------------------------+ -| Table | Create Table | -+-------+----------------------------------------------------------------------------------+ -| test | CREATE TABLE `test` ( | -| | `id` int(11) NOT NULL, | -| | `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, | -| | PRIMARY KEY (`id`) | -| | ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | -+-------+----------------------------------------------------------------------------------+ -1 row in set -``` - -产生表结构不一致的原因是 `explicit_defaults_for_timestamp` 的[默认值在 TiDB 和 MySQL 5.7 不同](/mysql-compatibility.md#默认设置)。从 TiCDC v5.0.1/v4.0.13 版本开始，同步到 MySQL 会自动设置 session 变量 `explicit_defaults_for_timestamp = ON`，保证同步时间类型时上下游行为一致。对于 v5.0.1/v4.0.13 以前的版本，同步时间类型时需要注意 `explicit_defaults_for_timestamp` 默认值不同带来的兼容性问题。 - -## 数据同步下游的 Sink 为 TiDB 或 MySQL 时，下游数据库的用户需要哪些权限？ - -Sink 为 TiDB 或 MySQL 时，下游数据库的用户需要以下权限： - -- `Select` -- `Index` -- `Insert` -- `Update` -- `Delete` -- `Create` -- `Drop` -- `Alter` -- `Create View` - -如果要同步 `recover table` 到下游 TiDB，需要有 `Super` 权限。 - -## 为什么 TiCDC 需要使用磁盘，什么时候会写磁盘，TiCDC 能否利用内存缓存提升同步性能？ - -TiCDC 需要磁盘是为了缓冲上游写入高峰时下游消费不及时堆积的数据。TiCDC 正常运行期间都需要写入磁盘，但这通常不是同步吞吐和同步延时的瓶颈，写磁盘对延时影响在百毫秒内。TiCDC 也利用了内存来提升加速读取磁盘中的数据，以提升同步性能。 - -# 为什么在使用了 TiDB Lightning 和 BR 恢复了数据之后，TiCDC 同步会出现卡顿甚至卡住？ - -目前 TiCDC 还没完全适配 TiDB Lightning 和 BR，请避免在使用 TiCDC 同步的表上使用 TiDB Lightning 和 BR。