数据接入与运维
这页整理的是客户和客服最容易反复确认的“连接、同步、日志、排障”问题。它不替代具体连接器文档，而是帮助你先判断：问题更可能出在连接、同步策略，还是运行环境。
数据连接能不能作为数据集成的输出端？
可以，但前提不是“连上就行”，而是目标连接具备写入能力。
通常至少要满足两件事：
- 目标连接本身勾选了允许写入操作
- 目标库对应账号确实有写权限
如果页面里已经能浏览表，但批量同步仍然落不进去，优先不要先查同步任务，而是先回头确认目标连接是不是只具备读权限。
相关文档：
为什么增量同步会突然变成全量同步？
一个高频原因是源表结构发生了变化。
当系统判断增量同步所依赖的 schema 已经不匹配时，会触发全量同步。最直接的判断方式不是猜，而是看日志里是否出现下面这类信息：
trigger full sync for schema mismatch如果你们对同步时长、目标库压力比较敏感，就应该把这类日志纳入排障习惯里，因为“增量为什么突然变慢了”经常本质上就是“它已经不再按增量执行了”。
为什么把 hengshi 内置 PG 同步到 MySQL 会报 lock timeout？
常见原因不是同步功能本身坏了，而是目标侧表正被别的事务占用。
如果你看到类似：
ERROR: canceling statement due to lock timeout优先排查：
- 当前是否有查询或事务占住目标表
- 是否存在长时间未提交、状态为
idle in transaction的连接
在 PostgreSQL 目标库中，通常可以先查：
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 负载影响。
日志里常见的判断方式：
sampling MongoDB for schema...
mapped schema for ...第一类日志代表开始采样，第二类日志代表 schema 已经采样完成。看到第一条但还没看到第二条时，更应该继续等采样，而不是立即改连接配置。
什么时候应该用 API 数据源，而不是普通数据库连接？
如果你的数据天然来自 HTTP API、第三方服务，或者你需要按自定义请求逻辑拉数据，才更适合看 API 数据源。
如果源头本身就是 MySQL、PostgreSQL、SQL Server 这类标准数据库，优先还是直接用数据库连接，因为：
- 配置更简单
- 性能和稳定性通常更可控
- 不需要自己维护 API 定义文件
只有当你确实需要自己定义 getApiName、setOptions、getPathTables、fetchTableData 这类获取逻辑时，再进入 API 数据源范畴。
数据接入问题，应该先看连接文档、同步文档，还是软件配置？
可以先按这个顺序判断：
| 现象 | 优先排查 |
|---|---|
| 连不上数据库 / 参数校验失败 | 先看具体连接器文档和网络连通性 |
| 连接能建，但同步报错 | 先看批量同步和目标库写权限 |
| 同步逻辑异常、执行结果和预期不一致 | 先看执行记录、任务日志、同步策略 |
| 同样配置在某些环境可用、某些环境不可用 | 再回头看代理、时区、软件配置 |
如果你的问题已经进入“要看日志关键字才能判断”的阶段，通常就不再是单纯的“连接参数填错了”。
进一步阅读：