---
url: /v6.2/data-integration-ops-faq.md
---
# 数据接入与运维

这页整理的是客户和客服最容易反复确认的“连接、同步、日志、排障”问题。它不替代具体连接器文档，而是帮助你先判断：问题更可能出在连接、同步策略，还是运行环境。

## 数据连接能不能作为数据集成的输出端？

可以，但前提不是“连上就行”，而是**目标连接具备写入能力**。

通常至少要满足两件事：

1. 目标连接本身勾选了**允许写入操作**
2. 目标库对应账号确实有写权限

如果页面里已经能浏览表，但批量同步仍然落不进去，优先不要先查同步任务，而是先回头确认目标连接是不是只具备读权限。

相关文档：

* [数据连接](connection-management.md)
* [批量同步](batch-sync.md)

## 为什么增量同步会突然变成全量同步？

一个高频原因是**源表结构发生了变化**。

当系统判断增量同步所依赖的 schema 已经不匹配时，会触发全量同步。最直接的判断方式不是猜，而是看日志里是否出现下面这类信息：

```text
trigger full sync for schema mismatch
```

如果你们对同步时长、目标库压力比较敏感，就应该把这类日志纳入排障习惯里，因为“增量为什么突然变慢了”经常本质上就是“它已经不再按增量执行了”。

## 为什么把 hengshi 内置 PG 同步到 MySQL 会报 lock timeout？

常见原因不是同步功能本身坏了，而是**目标侧表正被别的事务占用**。

如果你看到类似：

```text
ERROR: canceling statement due to lock timeout
```

优先排查：

1. 当前是否有查询或事务占住目标表
2. 是否存在长时间未提交、状态为 `idle in transaction` 的连接

在 PostgreSQL 目标库中，通常可以先查：

```sql
select * from pg_stat_activity where state != 'idle';
```

先搞清楚是谁在占表，再决定是否取消阻塞进程，而不是直接反复重跑同步任务。

## 连接 Mongo BI Connector 时，为什么提示 `mongodb schema not yet available`？

这通常不是“连接参数错了”，而是 **Mongo BI Connector 还在采样 schema**。

Mongo BI Connector 启动后并不是立刻就能查询。它需要先采样数据并推断 schema。采样时间会受数据量、表规模、MongoDB 负载影响。

日志里常见的判断方式：

```text
sampling MongoDB for schema...
mapped schema for ...
```

第一类日志代表开始采样，第二类日志代表 schema 已经采样完成。看到第一条但还没看到第二条时，更应该继续等采样，而不是立即改连接配置。

## 什么时候应该用 API 数据源，而不是普通数据库连接？

如果你的数据天然来自 HTTP API、第三方服务，或者你需要按自定义请求逻辑拉数据，才更适合看 API 数据源。

如果源头本身就是 MySQL、PostgreSQL、SQL Server 这类标准数据库，优先还是直接用数据库连接，因为：

* 配置更简单
* 性能和稳定性通常更可控
* 不需要自己维护 API 定义文件

只有当你确实需要自己定义 `getApiName`、`setOptions`、`getPathTables`、`fetchTableData` 这类获取逻辑时，再进入 API 数据源范畴。

## 数据接入问题，应该先看连接文档、同步文档，还是软件配置？

可以先按这个顺序判断：

|现象|优先排查|
|-|-|
|连不上数据库 / 参数校验失败|先看具体连接器文档和网络连通性|
|连接能建，但同步报错|先看[批量同步](batch-sync.md)和目标库写权限|
|同步逻辑异常、执行结果和预期不一致|先看执行记录、任务日志、同步策略|
|同样配置在某些环境可用、某些环境不可用|再回头看代理、时区、软件配置|

如果你的问题已经进入“要看日志关键字才能判断”的阶段，通常就不再是单纯的“连接参数填错了”。

进一步阅读：

* [数据连接](connecting-connection.md)
* [批量同步](batch-sync.md)
* [软件配置问题](software-config-faq.md)