Skip to main content

Start, stop and restart

Datastrato Enterprise runs as a set of Kubernetes workloads installed by one Helm release. There is no service to start or stop: you stop a workload by scaling it to zero replicas and start it by scaling it back up. The commands on this page assume the shell variables from Install with Helm (RELEASE, NAMESPACE).

What is running​

WorkloadKindWhat it is
{release}-gravitinoDeploymentThe server, with the Iceberg REST, Lance REST and SCIM services
{release}-uiDeploymentThe Enterprise UI
{release}-metricsDeploymentThe dashboard metrics service
{release}-mcpDeploymentThe MCP server
{release}-marquez, {release}-marquez-webDeploymentThe lineage service and its web view
{release}-gravitino-postgresqlStatefulSetThe in-cluster metadata database; {release}-gravitino-mysql with MySQL
opensearch-cluster-masterStatefulSetThe search index

Components turned off in the values file are not deployed. When the release name contains gravitino, the chart drops the extra -gravitino from the names.

Check status​

List the workloads and pods
kubectl -n "$NAMESPACE" get deploy,statefulset,pods

Every pod should be Running with all containers ready. The server's readiness also covers its database; see Health and readiness. For a pod that is not ready, its events and log say why:

See why a pod is not ready
kubectl -n "$NAMESPACE" describe pod {pod_name}
kubectl -n "$NAMESPACE" logs {pod_name} --all-containers --tail 100

Restart a component​

Restart the server
kubectl -n "$NAMESPACE" rollout restart "deploy/$RELEASE-gravitino"
kubectl -n "$NAMESPACE" rollout status "deploy/$RELEASE-gravitino"

Use the same commands with another Deployment's name to restart it. What a restart interrupts:

  • The server. Requests fail until the new pod is ready. With the default logs volume, which is ReadWriteOnce, the old pod stops before the new one starts, so there is a short outage. Running jobs are lost.
  • The UI. Every user is signed out.
  • The others. Their own function pauses; the server keeps serving.

A change to the values file does not need a restart. Running the install command again applies it, and the chart restarts the pods whose configuration changed.

Stop everything​

Stop the components that use the databases first, then the databases:

Stop the install
kubectl -n "$NAMESPACE" scale deploy \
  "$RELEASE-ui" "$RELEASE-mcp" "$RELEASE-metrics" "$RELEASE-marquez" "$RELEASE-marquez-web" \
  "$RELEASE-gravitino" --replicas=0
kubectl -n "$NAMESPACE" scale statefulset \
  "$RELEASE-gravitino-postgresql" opensearch-cluster-master --replicas=0

With the in-cluster MySQL, stop $RELEASE-gravitino-mysql instead of the PostgreSQL StatefulSet.

Stopping keeps everything on the volumes: the metadata, lineage history, search index and logs. It does not remove the release; for that, see Uninstall.

Start everything​

Run the install command from Install with Helm again, with the same values and license. It sets every workload back to the replica count in the values, starting the databases before the server, which waits for them.

Scaling the workloads back up one by one also works, in the reverse order of stopping them. The install command is simpler and leaves nothing at the wrong count.

Last updated on