Frequently asked questions

One or more PostgreSQL images no longer boot

When the Datachain stack is shut down (often unexpectedly), the database may no longer start, with the following error log:

2023-03-24 11:12:35.314 CET [24] LOG: database system stopped at 2023-03-17 06:04:58 CET
2023-03-24 11:12:35.314 CET [24] LOG: invalid resource manager identifier in primary checkpoint record
2023-03-24 11:12:35.314 CET [24] PANIC: could not locate a valid checkpoint record

In this case, proceed as follows:

on the machine where the PostgreSQL is located, identify the PostgreSQL data directory:
- either it’s a volume name mounted on the machine and is in the docker-compose deployment file
- or it’s a docker volume, and is located in /var/lib/docker/volumes/NOM_DE_STACK_NOM_DU_VOLUME/_data (stack name from startup (up.sh?), and volume name the volume in the docker-compose file (potentially pg_data). The 'docker volume ls' command will validate that this is the correct volume name. Example on a file:

version: "3.7"
services:
  dc_pg:
    image: dc/pg:dev
    networks:
      dc_network:
        aliases:
          - dc-pg
    deploy:
      mode: replicated
      replicas: 1
    volumes:
      - pg_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=adobis
...

If the stack name is datachain, then the volume will be datachain_pg_data, and the path /var/lib/docker/volumes/datachain_pg_data/_data.

Once the path has been validated, stop the stack.
On the target postgres machine, run the following command.

docker run -it -u postgres -v /var/lib/docker/volumes/datachain_pg_data/_data/:/var/lib/postgresql/data ${REGISTRY}/dc/pg:7.6.0 pg_resetwal /var/lib/postgresql/data/

A note: you could use the standard postgres 12 image, which would also work. * Restart the stack.

I want to remove the passwords from the docker-compose.yml deployment files. How can I do this?

In swarm, all datachain passwords can be stored directly at swarm cluster level in "docker secret".

Datachain environment variables containing passwords usually have a second variable suffixed with _FILE. The procedure for storing a password is as follows:

create the secret in docker from the Swarm manager

$ printf "my super secret password" | docker secret create my_secret -

use this secret in the deployment file (or .en file, depending on your preference) and replace the environment variable with the suffixed variable.

version: "3.7"
services:
...
  dc_pg_migration:
    image: dc/pg_migration:dev
    networks:
      dc_network:
        aliases:
          - dc-pg-migration
    environment:
      - PG_HOST=dc-pg
      - PG_PASSWORD=12345
    deploy:
      restart_policy:
        condition: none
    volumes:
      - pg_dump:/data/pg_dump

becomes

version: "3.7"
services:
...
  dc_pg_migration:
    image: dc/pg_migration:dev
    networks:
      dc_network:
        aliases:
          - dc-pg-migration
    environment:
      - PG_HOST=dc-pg
      - PG_PASSWORD_FILE=/run/secrets/pg_password
      - PG_EXPOSE_PASSWORD_FILE=/run/secrets/pg_password
      - PG_KC_PASSWORD_FILE=/run/secrets/pg_password
    deploy:
      restart_policy:
        condition: none
    volumes:
      - pg_dump:/data/pg_dump
    secrets:
      - pg_password
...

secrets:
  pg_password:
    external: true

Environment variables are specified in dedicated pages.

I need to add a trusted authority or a server certificate so that Datachain can access HTTPS connectors/repositories. How can I do this?

The trusted authorities used by Datachain are stored in the standard Java certificate store (keystore).

Solution 1 (recommended): use the /java_cert_import volume

The images concerned (Console, Spark, MarketPlace) expose a /java_cert_import volume: any certificate in .cert format placed in this directory is automatically imported into the Java keystore when the container starts.

See the dedicated page for details on how it works and the expected file format (PEM or DER, .cert extension mandatory, a single certificate per file).

Solution 2 (manual alternative): update and remount the complete keystore, or provide your own jks file

The JKS must be provided to the JVM with the additional private authorities.

The procedure is as follows:

Retrieve the standard Java jks from a delivered container, directly on the machine where the spark service runs

docker ps
# get the identifier of a spark container
# and put it in the following command
docker cp <idconteneurSpark>:/etc/ssl/certs/java/cacerts /tmp
# The password of the JVM cacerts file is "changeit".

Update the cacerts file with the authority’s public key

keytool -importcert -trustcacerts -keystore cacerts -file clepublique.pem -alias monAutorite

Make the file available on all machines, so that it can be provided to the images of the spark cluster and to the Adobis spark containers
Update the docker-compose file(s) of the spark cluster and of datachain by adding the file as a volume (placed here in a share/cacerts directory). For example:

dc_spark1:
    image: ${REGISTRY}/dc/spark:${PROJECT_VERSION}
    networks:
        traefik_network:
        dc_network:
          aliases:
            - dc-spark1
    env_file: spark1.env
    ports:
        - "4040:4040"
    deploy:
        mode: replicated
        replicas: 1
        labels:
            - "traefik.enable=true"
            - "traefik.http.routers.dc_spark1.rule=PathPrefix(`/actuator-spark1`)"
            - "traefik.http.routers.dc_spark1.entrypoints=web"
            - "traefik.port=9091"
            - "traefik.docker.network=traefik_network"
            - "traefik.http.services.dc_spark1.loadbalancer.server.port=9091"
            - "traefik.http.routers.dc_spark1.middlewares=dc_spark1-auth@docker"
            - "traefik.http.middlewares.dc_spark1-auth.basicauth.users=adobis:$$apr1$$ba1fhf6J$$nVxNFnb69azCnMzgBlsXP."
            - "traefik.http.middlewares.dc_spark1-auth.basicauth.removeheader=true"
    volumes:
        - /opt/adobis/data/hdfs:/data
        # declare the cacerts file as a volume.
        - /share/cacerts:/etc/ssl/certs/java/cacerts

Do you have example database backup/restore scripts?

We do not provide built-in scripts for the database, as they often depend on the environment in which the solution is deployed.

Below are example scripts, to be adapted to your context, for a docker environment (but easily adaptable to k8s).

The scripts must be run on the machine where the docker container is located (the command is not run from the swarm manager).

Backup script

#!/bin/bash

# in our case, the postgres container is in the dc stack.
DOCKER_IMAGE=$(docker ps -qf "name=dc_dc-pg.")
# databases to back up
DATABASES="dc_console keycloak dc_marketplace expose adobis"

for database in $DATABASES; do
 docker exec -t $DOCKER_IMAGE pg_dump -U postgres --format=c --blobs --clean --create $database -f /tmp/base.dump
 docker cp $DOCKER_IMAGE:/tmp/base.dump /tmp/$database.dump
 docker exec -t $DOCKER_IMAGE rm /tmp/base.dump
done

Restore script

#!/bin/bash

DOCKER_IMAGE=$(docker ps -qf "name=dc_dc-pg.")
DATABASES="dc_console keycloak dc_marketplace expose adobis"

for database in $DATABASES; do
docker cp /tmp/$database.dump $DOCKER_IMAGE:/tmp/base.dump
docker exec -t $DOCKER_IMAGE pg_restore -U postgres -c -v -C -d postgres /tmp/base.dump
docker exec -t $DOCKER_IMAGE rm /tmp/base.dump
done

Dernière mise à jour le 2 novembre 2026 à 15:16