Starten · Stoppen · Neustarten

Es gibt zwei Orte, um die Datenseeschicht zu starten und zu stoppen. Der Container selbst wird auf dem Host verwaltet, ein einzelner Dienst im Container wird pd verwaltet. Entscheiden Sie zuerst, welche Variante Sie benötigen.

Aufgabe	Ort	Befehl
Gesamte Plattform starten und stoppen	Host	up.sh · down.sh · restart.sh
Nach Konfiguration oder Passwortänderung nur die Datenseeschicht neu erstellen	Host	restart-datalake.sh
Nur eine App neu starten (Server · Batch · Warehouse)	Host	restart-server.sh · restart-batch.sh · restart-warehouse.sh · restart-one.sh <서비스>
Nur einen Dienst in der Datenseeschicht neu starten (CEP · Workflow …)	Im Container	pd restart <서비스>
Status prüfen	Host / Im Container	status.sh / pd status

Host-Befehle

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

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

Befehl	Exit-Code 0 bedeutet	Hinweise
up.sh	«einsatzbereit» — das ist nicht gleichbedeutend mit Befehlserfolg. Es wird erneut abgerufen, bis die Readiness-Prüfung besteht (Standard 900 Sekunden, 15-Sekunden-Intervall)	Mit PP_WAIT=0 wird nicht gewartet, und die 0 bedeutet dann nicht Readiness
restart.sh	Nach Neustart bereit	Alle sechs Apps, Proxy und Certificate-Container. Wird für Apps relevante Werte wie Sprache oder Zeitzone geändert
restart-datalake.sh	Datenseeschicht wieder healthy, ebenso abhängige Apps	Ein Container, aber ein Stack-Ereignis — alle Apps sind über diesen verbunden, daher führt der Host nach Abschluss eine Readiness-Prüfung durch und startet neu, was sich nicht selbst erholt hat. Dauert so lange wie der Bootvorgang
status.sh	Normal	Volumes · Konfiguration werden nur angezeigt, nicht in den Exit-Code aufgenommen

Nach einer Wertänderung ist docker restart falsch, verwenden Sie restart-datalake.sh

Werte in Sidecar- und Knotendateien werden von compose als Umgebungsvariablen eingegeben, wenn der Container neu erstellt wird. docker restart plantpulse-datalake startet nur mit denselben Umgebungsvariablen neu, daher werden neue Werte nicht übernommen.

Startreihenfolge

Zwischen Containern

plantpulse-certs (TLS-Material) → plantpulse-datalake → sechs Apps · Proxy. Apps starten erst, nachdem die Datenseeschicht healthy ist. Das Startup-Timeout der Datenseeschicht beträgt 900 Sekunden, und der erste Start kann durch die Cassandra-Schemenerstellung ebenso lange dauern.

Innerhalb der Datenseeschicht

Wenn der Container startet, hilft pd start automatisch.

1. Falls die Core-Ports (6379 · 5432 · 9042) bereits offen sind, wird mit «already running» abgewiesen.
2. Es wird geprüft, ob alle 15 erforderlichen Secrets vorhanden sind (Worker +1). Falls nicht, werden alle Namen aufgelistet und exit 3 ausgeführt.
3. TLS-Material prüfen (/var/security/plantpulse).
4. Konfiguration rendern — alle Templates unter PP_HOME in tatsächliche Dateien. Jedes Mal, ohne Ausnahmen.
5. Dienste in der Reihenfolge storage → analytics → messaging → timeseries → cep → workflow → data-gateway → admin-api starten und auf Health Check UP warten.

Die letzte Zeile ist das Ergebnis.

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

Stoppreihenfolge

down.sh · restart.sh auf dem Host fahren zuerst die Apps herunter und drainieren dann die Datenseeschicht — pd stop im Container fährt Dienste in umgekehrter Reihenfolge herunter (admin-api → … → storage) und belegt für jeden «gestoppt» (30-Sekunden-Warten → SIGTERM 15 Sekunden → SIGKILL 10 Sekunden). Das Stop-Timeout des Containers (stop_grace_period) ist 180 Sekunden.

Stoppen Sie nicht nur storage und lassen Sie den Rest laufen

Alle oben genannten Dienste sind mit storage verbunden. Um herunterzufahren, verwenden Sie pd stop, das alle Dienste in umgekehrter Reihenfolge herunter fährt. Und noch besser ist es, den Host mit down.sh herunterzufahren, um den Container selbst zu stoppen. Wenn Sie pd stop alle «nur um sie kurz zum Schweigen zu bringen» pausieren, wird die Container-HEALTHCHECK in wenigen Minuten unhealthy, und die Host-seitige Überwachung reagiert.

Nur einen Dienst — 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

Dienst	Beim Neustarten
storage	Verlieren alles, was abhängig ist seine Verbindung. Verwenden Sie nach Möglichkeit restart-datalake.sh auf dem Host für alles
analytics	Alle laufenden SQL · Spark-Jobs werden beendet. Wenn ein Archivierungsjob läuft, warten Sie bis er fertig ist
messaging	Alle Nachrichtenempfänge stoppen für wenige Sekunden. Consumer (Server · CEP · Batch) verbinden sich automatisch erneut
timeseries · cep · workflow · data-gateway · admin-api	Nur dieser Dienst. Apps verbinden sich automatisch erneut

pd restart belegt zunächst den Stop. Wenn der Stop fehlschlägt (exit 7), wird hier angehalten — verwenden Sie dann pd kill --dry-run → pd kill → pd status → pd start.

Status zeilenweise prüfen

./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 aber tot» — Speicher OOM

Da PID 1 des Containers systemd ist, kann der Java-Prozess von cgroup allein OOM-getötet werden, und docker ps zeigte weiterhin Up (healthy), bis es später unhealthy wurde. Wenn pd status alle STOPPED sind aber der Container noch läuft, verdächtigen Sie zuerst dies.

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

Wie man das Limit erhöht, finden Sie unter Konfiguration ändern — Memory.

Automatisches Starten

Der Container hat restart: always, daher startet der Docker-Daemon ihn beim Host-Reboot automatisch. Es wird keine separate systemd-Unit benötigt. Allerdings bleibt ein Stack, der absichtlich mit down.sh heruntergefahren wurde, nach dem Reboot abgeschaltet — verwenden Sie up.sh zum Starten.

Verwandte Dokumentation

• Systemstart und -shutdown — Ganzer Stack und Notfallverfahren
• pd CLI
• Logs und Health