5分钟掌握社区提问必备技能

[CloudCanal-万少]

前言

本文章旨在指导用户在遇到CloudCanal问题时，如何获取必要的上下文信息用于提问，使得自己的问题能够被更快更准确地被处理。这些必要的上下文信息主要包括：

• 异常日志
• 提供同步任务问题现场必要信息

获取异常信息

解决问题的关键在于首先确认哪里出现了问题，并且具体的问题是什么。获取异常信息是排查问题要做的第一件事也是最为主要的工作，掌握如何获取异常信息，很多问题也自然能够迎刃而解，例如数据库没有访问权限、账号密码错误等。因此，在社区提问前务必需要学会如何获取异常信息，并在提问时提供这些异常信息。

控制台异常日志

CloudCanal控制台提供了白屏化日志，当CloudCanal管控的使用或者任务迁移同步产生任何问题时，几乎都可以在该页面看到最新的异常信息。社区发帖时务必将以下信息提供。

第1步：点击导航栏访问异常监控页面

第2步：查看异常监控堆栈

异常来源主要是以下三个核心组件：

• 管控系统：页面上的产品化功能均由管控负责，例如任务的创建、信息的呈现查询等。如果出现的问题与管控的能力相关，可以查看管控系统的异常。在提问时也可以将管控系统异常堆栈提供出来。
• SIDECAR异常：任务创建过程中会捞取数据库的元信息，比如数据库里面有哪些库表，他们的列类型是什么。这些信息的获取执行和SIDECAR有关；另外表结构迁移的功能也与SIDECAR异常有关。如果遇到表结构迁移执行失败、任务创建中元数据获取相关问题可以查看此处是否有异常。
• 任务异常: 具体的数据全量迁移、数据增量实时同步、数据校验都是由任务组件去完成的。如果发现迁移同步任务产生延迟、或者状态异常等，可以关注任务异常的堆栈信息

第3步：复制异常堆栈附带在提问帖中

可以截图，复制完整的堆栈内容，在提问时附带上信息

日志文件

绝大部分异常理论上都应该可以从控制台查看到，但是如果产生问题时，异常监控没法看到任何信息，则可以到具体机器上获取日志，找到日志中Exception相关的内容，将相关内容在提问时附带上。

主要日志路径

日志的划分也是按照三大核心组件划分的，即管控、SIDECAR和任务。对于三大核心组件功能理解有疑惑的，可以参考上文异常来源部分的介绍。

# 管控日志路径，在管控机器上，也就是cloudcanal-console的docker容器内部
/home/clougence/logs/cloudcanal/console/console.log
# SIDECAR日志路径，在cloudcanal-sidecar的docker容器内部
/home/clougence/logs/cloudcanal/sidecar/sidecar.log
# 任务日志路径，在cloudcanal-sidecar的docker容器内部。每个sidecar容器内可以运行多个任务进程，其中${taskName}的名字可以在控制台上查看
/home/clougence/logs/cloudcanal/task/${taskName}/${taskName}.log
#结构迁移失败，报错 SQL 日志
/home/clougence/logs/cloudcanal/sidecar/rsocket_send_receive_error.log

提供复现同步任务问题现场的必要信息

具体的全量迁移、增量同步如果遇到异常，一般会导致任务延迟或者状态异常。除了提供上文中提到的异常日志信息以外，还需要提供能够复现问题的信息，以便于CloudCanal研发人员重现你的问题并进行修复。能被稳定重现的问题，往往会较快地被进行修复。

具体的任务迁移同步往往和数据、表结构以及源对端的数据源类型是紧相关的，为了复现问题，务必需要提供以下信息。

源对端的表结构

能重现问题的源对端表结构的建表SQL语句。例如源端是MySQL，对端是StarRocks，则提供以下表结构

### 源端MySQL表结构
CREATE TABLE `brush_face_records` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `date` date NOT NULL,
  `time` time NOT NULL,
  `name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `shangtang_id` int(11) DEFAULT '0',
  `version` tinyint(4) NOT NULL DEFAULT '1' COMMENT '默认为1',
  `device` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT '',
  `card_id` bigint(20) NOT NULL,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `updated_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`),
  KEY `brush_face_records_card_id_index` (`card_id`),
  KEY `brush_face_records_name_date_time_index` (`name`(191),`date`,`time`),
  KEY `idx_date_time_version_shangtang_id` (`shangtang_id`,`date`,`time`,`version`),
  KEY `idx_date_device` (`date`,`device`(191)),
  KEY `idx_createdat_device_name` (`created_at`,`device`(191),`name`(191))
) ENGINE=InnoDB AUTO_INCREMENT=14134034 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC

### 对端StarRocks表结构
CREATE TABLE `brush_face_records` (
  `id` int(11) NOT NULL COMMENT "",
  `date` date NULL COMMENT "",
  `time` datetime NULL COMMENT "",
  `name` varchar(255) NULL COMMENT "",
  `shangtang_id` int(11) NULL COMMENT "",
  `version` int(11) NULL COMMENT "",
  `device` varchar(255) NULL COMMENT "",
  `card_id` bigint(20) NULL COMMENT "",
  `created_at` datetime NULL COMMENT "",
  `updated_at` datetime NULL COMMENT ""
) ENGINE=OLAP
PRIMARY KEY(`id`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`id`) BUCKETS 10
PROPERTIES (
"replication_num" = "1",
"in_memory" = "false",
"storage_format" = "DEFAULT"
);

重现问题使用的数据

无论是同步异常还是数据不一致或者丢失，都肯定与源端执行的SQL有关。例如源端MySQL执行insert时，导致写入异常，这时候请提供具体源端数据的初始化SQL。这个一般通过navicat和datagrip这样的工具，都可以直接导出查询的结果为具体的insert语句。

参考例子：

INSERT INTO db2.brush_face_records (id, date, time, name, shangtang_id, version, device, card_id, created_at, updated_at) VALUES (14134032, '2021-11-23', '18:09:22', '李四', 21497, 3, '昆明', -2, '2021-11-23 18:09:24', '2021-11-23 18:09:24');

INSERT INTO brush_face_records (id, date, time, name, shangtang_id, version, device, card_id, created_at, updated_at) VALUES (14134033, '2021-11-23', '08:39:00', '张三', 28802, 3, '研发测温1', -2, '2021-11-26 10:42:38', '2021-11-26 10:42:38');