trino分布式部署必须严格区分coordinator和worker角色：coordinator节点配置coordinator=true、负责查询解析与调度，worker节点配置coordinator=false、专注任务执行；两者node.id须唯一，node.environment须一致，catalog配置需同步至所有节点，discovery.uri必须指向coordinator地址。
Trino 分布式部署不是“装完就能跑”，必须明确区分 coordinator 和 worker 角色，且两者配置文件不能混用。单节点伪分布式可跑通，但生产环境必须拆开——否则查询失败、任务卡死、内存溢出都是常态。
coordinator 和 worker 的配置文件怎么分？
核心是三类文件各自独立：每个节点的 etc/node.properties 必须有唯一 node.id；etc/config.properties 中角色由 coordinator=true 或 coordinator=false 决定；etc/jvm.config 建议按角色调参（coordinator 内存可略低，worker 需更高堆和 G1 区大小）。
常见错误现象：
- 所有节点都配
coordinator=true→ 查询报错Query failed: No nodes available to run query -
node.id重复或为空 → 启动失败，日志里反复出现Node id is not set -
node.data-dir指向 NFS 或共享目录 → worker 写临时文件冲突，任务 hang 住
实操建议：
- coordinator 节点：只保留
coordinator=true，关闭node-scheduler.include-coordinator=true（除非你真要它也跑任务） - worker 节点：必须设
coordinator=false，且discovery.uri指向 coordinator 的 HTTP 地址（如http://coordinator-host:8080） - 所有节点的
node.environment值必须完全一致（比如都写production），否则无法发现彼此
连接器（catalog）配置为什么只在 coordinator 生效？
不是“只在 coordinator 生效”，而是 catalog 配置文件（如 etc/catalog/hive.properties）必须在 每个 worker 节点也存在且内容一致。Trino 不会自动同步 catalog，coordinator 解析 SQL 时依赖本地 catalog 定义，但实际执行时 worker 需靠自己加载对应 connector 实现。
容易踩的坑：
- 只在 coordinator 放了
mysql.properties，worker 启动时报Connector 'mysql' not found - worker 上的
connection-url写了localhost→ 所有 worker 都连自己本机 MySQL，而非统一后端 - Hive connector 的
hive.metastore.uri在不同节点指向不同 Thrift 地址 → 元数据不一致，SHOW TABLES结果随机缺失
正确做法：
- catalog 文件用 Ansible/rsync 统一推送到所有节点的
etc/catalog/目录 - 敏感参数（如
connection-password）不要硬编码，改用password-authenticator+password.db或 Kerberos - 测试阶段可用
SELECT * FROM system.metadata.table_comments确认各节点看到的 catalog 列表是否一致
启动失败常见日志怎么看？
别急着重装，先看 var/log/server.log 最末几行。真正有用的线索往往藏在 stack trace 前面那句 warn/error 里。
高频问题定位：
-
Failed to bind to /0.0.0.0:8080→ 端口被占，用lsof -i :8080查进程，不是删掉旧进程就是改http-server.http.port -
Unable to create directory: /var/trino/data→node.data-dir路径不存在或权限不对，chown -R trino:trino /var/trino -
Caused by: java.lang.OutOfMemoryError: Java heap space→ JVM 参数没调，重点看etc/jvm.config里的-Xmx，worker 建议 ≥4G，coordinator ≥2G -
Discovery service not available→discovery.uri地址填错，或 coordinator 还没起来就先启 worker
一个可靠验证顺序：
- 先单独启动 coordinator，curl
http://localhost:8080/v1/status返回{"coordinator":true,"running":true} - 再逐个启动 worker，等 30 秒后查 coordinator 的
http://localhost:8080/v1/node，确认状态为active - 最后用 CLI 连：
trino --server http://coordinator:8080 --catalog hive --schema default
真正麻烦的从来不是配文件，而是网络连通性、DNS 解析、防火墙策略这三层隐形墙。哪怕配置全对，worker ping 不通 coordinator 的 discovery.uri 端口，集群就永远是“半残”状态。
