diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 9783f5b65603..419a1a4e564a 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -276,29 +276,36 @@ cdc cli changefeed remove --pd=http://10.0.10.25:2379 --changefeed-id 28c43ffc-2 {{< copyable "shell-regular" >}} ```shell - cdc cli processor query --pd=http://10.0.10.25:2379 --changefeed-id=28c43ffc-2316-4f4f-a70b-d1a7c59ba79f + cdc cli processor query --pd=http://10.0.10.25:2379 --changefeed-id=28c43ffc-2316-4f4f-a70b-d1a7c59ba79f --capture-id=b293999a-4168-4988-a4f4-35d9589b226b ``` ``` { - "status": { - "table-infos": [ - { - "id": 45, - "start-ts": 415241823337054209 - } - ], - "table-p-lock": null, - "table-c-lock": null, - "admin-job-type": 0 - }, - "position": { - "checkpoint-ts": 415241893447467009, - "resolved-ts": 415241893971492865 - } + "status": { + "tables": { + "56": { # 56 表示同步表 id，对应 TiDB 中表的 tidb_table_id + "start-ts": 417474117955485702, + "mark-table-id": 0 # mark-table-id 是用于环形复制时标记表的 id，对应于 TiDB 中标记表的 tidb_table_id + } + }, + "operation": null, + "admin-job-type": 0 + }, + "position": { + "checkpoint-ts": 417474143881789441, + "resolved-ts": 417474143881789441, + "count": 0 + } } ``` +以上命令中： + +- `status.tables` 中每一个作为 key 的数字代表同步表的 id，对应 TiDB 中表的 tidb_table_id； +- `mark-table-id` 是用于环形复制时标记表的 id，对应于 TiDB 中标记表的 tidb_table_id； +- `resolved-ts` 代表当前 processor 中已经排序数据的最大 TSO； +- `checkpoint-ts` 代表当前 processor 已经成功写入下游的事务的最大 TSO； + ## 使用 HTTP 接口管理集群状态和数据同步 目前 HTTP 接口提供一些基础的查询和运维功能。在以下接口描述中，假设 TiCDC server 的监听 IP 地址为 `127.0.0.1`，端口为 `8300`（在启动 TiCDC server 时通过 `--addr=ip:port` 指定绑定的 IP 和端口）。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 564bee693e2d..607ffb2a0b88 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -42,6 +42,29 @@ TiCDC 的系统架构如下图所示： - MySQL 协议兼容的数据库，提供最终一致性支持。 - 以 TiCDC Open Protocol 输出到 Kafka，可实现行级别有序、最终一致性或严格事务一致性三种一致性保证。 +### 同步顺序保证和一致性保证 + +#### 数据同步顺序 + +- TiCDC 对于所有的 DDL/DML 都能对外输出**至少一次**。 +- TiCDC 在 TiKV/TiCDC 集群故障期间可能会重复发相同的 DDL/DML。对于重复的 DDL/DML： + - MySQL sink 可以重复执行 DDL，对于在下游可重入的 DDL （譬如 truncate table）直接执行成功；对于在下游不可重入的 DDL（譬如 create table），执行失败，TiCDC 会忽略错误继续同步。 + - Kafka sink 会发送重复的消息，但重复消息不会破坏 Resolved Ts 的约束，用户可以在 Kafka 消费端进行过滤。 + +#### 数据同步一致性 + +- MySQL sink + + - TiCDC 不拆分表内事务，**保证**单表事务一致性，但**不保证**上游表内事务的顺序一致。 + - TiCDC 以表为单位拆分跨表事务，**不保证**跨表的事务始终一致。 + - TiCDC **保证**单行的更新与上游更新顺序一致。 + +- Kafka sink + + - TiCDC 提供不同的数据分发策略，可以按照表、主键或 ts 等策略分发数据到不同 Kafka partition。 + - 不同分发策略下 consumer 的不同实现方式，可以实现不同级别的一致性，包括行级别有序、最终一致性或跨表事务一致性。 + - TiCDC 没有提供 Kafka 消费端实现，只提供了 [TiCDC 开放数据协议](/ticdc/ticdc-open-protocol.md)，用户可以依据该协议实现 Kafka 数据的消费端。 + ## 同步限制 将数据同步到 TiDB 或 MySQL，需要满足以下条件才能保证正确性： diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index a2655327c670..628c84323455 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -43,7 +43,7 @@ aliases: ['/docs-cn/dev/reference/tools/ticdc/troubleshoot/'] 从 TiDB v4.0.0-rc.1 版本起，PD 支持外部服务设置服务级别 GC safepoint。任何一个服务可以注册更新自己服务的 GC safepoint。PD 会保证任何小于该 GC safepoint 的 KV 数据不会在 TiKV 中被 GC 清理掉。在 TiCDC 中启用了这一功能，用来保证 TiCDC 在不可用、或同步任务中断情况下，可以在 TiKV 内保留 TiCDC 需要消费的数据不被 GC 清理掉。 -启动 CDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，这个值的含义是当 TiCDC 服务全部挂掉后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间，该值默认为 86400 秒。 +启动 TiCDC server 时可以通过 `gc-ttl` 指定 GC safepoint 的 TTL，这个值的含义是当 TiCDC 服务全部挂掉后，由 TiCDC 在 PD 所设置的 GC safepoint 保存的最长时间，该值默认为 86400 秒。 如果同步任务长时间中断，累积未消费的数据比较多，初始启动 TiCDC 可能会发生 OOM。这种情况下可以启用 TiCDC 提供的文件排序功能，该功能会使用文件系统文件进行排序。启用的方式是创建同步任务时在 `cdc cli` 内传入 `--sort-engine=file` 和 `--sort-dir=/path/to/sort_dir`，使用示例如下： @@ -56,3 +56,56 @@ cdc cli changefeed create --pd=http://10.0.10.25:2379 --start-ts=415238226621235 > **注意：** > > TiCDC（4.0 发布版本）还不支持动态修改文件排序和内存排序。 + +## 创建同步任务或同步到 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) 命令加载时区，加载后就可以正常创建任务或同步任务。 + +{{< copyable "shell-regular" >}} + +```shell +mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p +``` + +``` +Enter password: +Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it. +Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it. +Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it. +Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it. +``` + +如果是在特殊的公有云环境使用 MySQL，譬如阿里云 RDS 并且没有修改 MySQL 的权限，就需要通过 `--tz` 参数指定时区。可以首先在 MySQL 查询其使用的时区，然后在创建同步任务和创建 TiCDC 服务时使用该时区。 + +{{< copyable "shell-regular" >}} + +```shell +show variables like '%time_zone%'; +``` + +``` ++------------------+--------+ +| Variable_name | Value | ++------------------+--------+ +| system_time_zone | CST | +| time_zone | SYSTEM | ++------------------+--------+ +``` + +{{< copyable "shell-regular" >}} + +```shell +cdc cli changefeed create --sink-uri="mysql://root@127.0.0.1:3306/" --tz=Asia/Shanghai +``` + +> **注意：** +> +> 在 MySQL 中 CST 时区通常实际代表的是 China Standard Time (UTC+08:00)，通常系统中不能直接使用 `CST`，而是用 `Asia/Shanghai` 来替换。 + +> **注意：** +> +> 请谨慎设置 TiCDC server 的时区，因为该时区会用于时间类型的转换。推荐上下游数据库使用相同的时区，并且启动 TiCDC server 时通过 `--tz` 参数指定该时区。TiCDC server 时区使用的优先级如下： +> +> - 最优先使用 `--tz` 传入的时区 +> - 没有 `--tz` 参数，会尝试读取 `TZ` 环境变量设置的时区 +> - 如果还没有 `TZ` 环境变量，会从 TiCDC server 运行机器的默认时区