启动 · 停止 · 重启

数据湖的启停有两个位置。容器本身在主机上操作，容器内的单个服务用**pd**管理。先决定要用哪一个。

要做的事	在哪里	命令
启动和停止整个平台	主机	`up.sh` · `down.sh` · `restart.sh`
修改配置 · 密码后只重建数据湖	主机	`restart-datalake.sh`
只重启一个应用（服务器 · 批处理 · 数据仓库）	主机	`restart-server.sh` · `restart-batch.sh` · `restart-warehouse.sh` · `restart-one.sh <서비스>`
只重启数据湖内的一个服务（CEP · 工作流 …）	容器内	`pd restart <서비스>`
检查状态	主机 / 容器内	`status.sh` / `pd status`

主机动作

cd /opt/kopens/plantpulse-platform-docker/bin

./up.sh                 # 기동 — 준비될 때까지 기다린다. 종료 코드 0 = 쓸 수 있다
./down.sh               # 정지 — 컨테이너 · 볼륨은 남는다
./restart.sh            # 전체 재시작 — graceful drain → 재기동 → 준비 대기. 인자를 받지 않는다
./restart-datalake.sh   # 데이터레이크만 — drain → 재생성 → 준비 대기 → 의존 앱 판정
./status.sh             # 컨테이너 · 헬스 · 볼륨 요약. 0 = 정상 / 2 = 비정상

动作	退出码 0 的含义	注意事项
`up.sh`	「可以使用」 — 不是命令成功。持续检查直到就绪判定通过（默认 900 秒，间隔 15 秒）	如果是 `PP_WAIT=0`，则不等待，此时的 0 也不表示就绪
`restart.sh`	重启后就绪完成	包括全部六个应用、代理和证书容器。修改了语言、时区等影响应用的值时使用
`restart-datalake.sh`	数据湖恢复 healthy，其依赖的应用也是	虽然只是一个容器，但是栈事件 — 所有应用都持有到它的连接，完成后判定应用，只有未能自行恢复的才重启一次。耗时相当于完整启动
`status.sh`	正常	卷和配置只报告，不计入退出码

如果修改了值，应该用 restart-datalake.sh 而不是 docker restart

边车和节点文件中的值在 compose 重建容器时作为环境变量注入。docker restart plantpulse-datalake 只是用同一环境变量重新启动，新值不会生效。

启动顺序

容器之间

plantpulse-certs（TLS 材料）→ plantpulse-datalake → 六个应用和代理。应用必须在数据湖healthy后才能启动。数据湖的启动宽限期是 900 秒，首次启动时 Cassandra 模式创建可能需要这么久。

数据湖内部

容器启动时 pd start 自动接管。

如果核心端口（6379 · 5432 · 9042）已经开放，则以「already running」拒绝。
检查所有 15 个必需密钥（worker 额外加 1 个）是否存在。不存在则列出所有名称并 exit 3。
验证 TLS 材料（/var/security/plantpulse）。
配置渲染 — 将所有模板渲染为 PP_HOME 下的实际文件。每次都要，没有例外。
按 storage → analytics → messaging → timeseries → cep → workflow → data-gateway → admin-api 的顺序启动，每个都等待其健康检查变为 UP。

最后一行是结果。

datalake started: 8 service(s) ready. Logs: pd logs                                  # exit 0
datalake started with 1 service(s) not ready (7 ready). Check: pd status              # exit 6

停止顺序

主机上的 down.sh · restart.sh 先关闭应用，再对数据湖进行 drain — 容器内 pd stop 以反向顺序（admin-api → … → storage）关闭服务，每个都证明「已停止」（等待 30 秒 → SIGTERM 15 秒 → SIGKILL 10 秒）。容器的停止宽限期（stop_grace_period）为 180 秒。

不要只关闭 storage 而留下其余服务

以上所有服务都连接到 storage。如果要关闭，应该用反向顺序关闭所有服务的 pd stop，那样的话用主机的 down.sh 关闭容器本身更合适。如果执行整个 pd stop「只是想让它安静一会儿」，容器的 HEALTHCHECK 会在几分钟内变为 unhealthy，主机端的监控会响应。

只重启一个服务 — `pd`

docker exec plantpulse-datalake pd status            # 어느 것이 STOPPED 인가
docker exec plantpulse-datalake pd logs --lines 100 cep
docker exec plantpulse-datalake pd restart cep       # stop → 정지 증명 → 5초 → start

服务	重启后的影响
`storage`	所有依赖失去连接。如可能，用主机的 `restart-datalake.sh` 重启全部
`analytics`	所有正在运行的 SQL · Spark 作业都会中断。如果归档作业正在运行，则在其完成后
`messaging`	数秒内所有消息接收停止。消费者（服务器 · CEP · 批处理）会自动重新连接
`timeseries` · `cep` · `workflow` · `data-gateway` · `admin-api`	仅该服务。应用自动重新连接

pd restart 先证明已停止。如果停止失败（exit 7），则在此停止 — 此时使用 pd kill --dry-run → pd kill → pd status → pd start。

逐行检查状态

./status.sh                                            # 호스트: 0 정상 / 2 비정상
docker ps --format 'table {{.Names}}\t{{.Status}}'      # 컨테이너와 (healthy)
docker exec plantpulse-datalake pd status              # 서비스 포트 표
curl -kfsS https://<server-ip>:4950/api/health | jq .status   # 콘솔 헬스 API

「Up 但已死亡」— 内存 OOM

容器内 PID 1 是 systemd，Java 进程只在 cgroup 中被 OOM-kill，而 docker ps 继续显示 Up (healthy)，直到后来才变为 unhealthy。如果 pd status 全是 STOPPED 但容器仍然活着，首先怀疑这一点。

dmesg -T | grep -i "memory cgroup"                                   # 호스트
docker inspect plantpulse-datalake --format '{{.State.OOMKilled}}'

提高限制的方法在修改配置 — 内存。

自动启动

容器设置为 restart: always，因此主机重启时 Docker 守护进程会自动启动它。无需额外的 systemd 单位。但是用 down.sh故意关闭的栈在重启后仍保持关闭 — 用 up.sh 启动它。

主机动作​

启动顺序​

容器之间​

数据湖内部​

停止顺序​

只重启一个服务 — pd​

逐行检查状态​

自动启动​

相关文档​