[mongodb] unable to restart replica set primary node after running docker-compose down

[Loosetooth]

Name and Version

bitnami/mongodb:4.4.14

What steps will reproduce the bug?

We start with a simple docker-compose.yml to start a replica set with a single primary node, and a volume to persist db data:

version: '3.9'
services:
  mongo:
    image: bitnami/mongodb:4.4.14
    container_name: mongo
    ports:
      - 27030:27017
    volumes:
      - mongodata:/bitnami/mongodb
    environment:
      - MONGODB_ROOT_USER=root
      - MONGODB_ROOT_PASSWORD=root
      - MONGODB_REPLICA_SET_MODE=primary
      - MONGODB_REPLICA_SET_KEY=ThisIsAUniqueKeyThatShouldBeChanged123

volumes:
  mongodata:
    driver: local

Running docker-compose up the first time results in the replica set correctly starting with a single primary node:

...
"msg":"Transition to primary complete; database writes are now permitted"

Now stop the containers (by pressing ctrl+c in cli or docker-compose stop if running in detached mode) and run docker-compose down

Try to restart the container: docker-compose up

Results in the following output:

..."msg":"This node is not a member of the config"
..."msg":"Replica set state transition","attr":{"newState":"REMOVED","oldState":"STARTUP"}

So it looks like the node did not start back up in primary mode. Please note that when using docker-compose stop and then docker-compose start it does seem to be able to restart correctly.

What is the expected behavior?

I should be able to restart a primary node from volume data.

What do you see instead?

Unable to restart primary node.

Additional information

No response

[gongomgra]

Hi @Loosetooth,

Thank you for using our products and for reporting this issue. I was able to reproduce it with our latest image for MongoDB 5.0, but I couldn't reproduce it using upstream MongoDB 5.0 image, so there should be anything in our configuration or initialization process breaking this. I will open a task for our engineering team to review and fix this. However, I can't provide you with any ETA on when this issue will be solved, but you (or anyone else in the community) can work on your own PR to speed up the resolution of this issue. I will left the thread open.

[carrodher]

We are going to transfer this issue to bitnami/containers

In order to unify the approaches followed in Bitnami containers and Bitnami charts, we are moving some issues in bitnami/bitnami-docker-<container> repositories to bitnami/containers.

Please follow bitnami/containers to keep you updated about the latest bitnami images.

More information here: https://blog.bitnami.com/2022/07/new-source-of-truth-bitnami-containers.html

[Mauraza]

Hi @Loosetooth,

Could you try adding MONGODB_ADVERTISED_HOSTNAME and tell us if that solves the issue?

version: '3.9'
services:
  mongo:
    image: bitnami/mongodb:4.4.14
    container_name: mongo
    ports:
      - 27030:27017
    volumes:
      - mongodata:/bitnami/mongodb
    environment:
      - MONGODB_ROOT_USER=root
      - MONGODB_ROOT_PASSWORD=root
      - MONGODB_ADVERTISED_HOSTNAME=mongo
      - MONGODB_REPLICA_SET_MODE=primary
      - MONGODB_REPLICA_SET_KEY=ThisIsAUniqueKeyThatShouldBeChanged123
volumes:
  mongodata:
    driver: local

[Loosetooth]

Hi @Mauraza,

Correct, running the following docker-compose.yml:

version: '3.9'
services:
  mongo:
    image: bitnami/mongodb:latest
    container_name: mongo
    ports:
      - 27030:27017
    volumes:
      - mongodata:/bitnami/mongodb
    environment:
      - MONGODB_ROOT_USER=root
      - MONGODB_ROOT_PASSWORD=root
      - MONGODB_REPLICA_SET_MODE=primary
      - MONGODB_ADVERTISED_HOSTNAME=mongo
      - MONGODB_REPLICA_SET_KEY=ThisIsAUniqueKeyThatShouldBeChanged123

volumes:
  mongodata:
    driver: local

Fixes the problem I can now do docker-compose down and afterwards docker-compose up without any problems. Thanks for your time.

[Loosetooth]

P.S. The MONGODB_ADVERTISED_HOSTNAME needs to be the same as the service name as defined in the docker compose file. In this case the service name is mongo.