Issues with Persistent Data in Dockerized Website Application

General
1

Hi everyone,

I’ve been working on containerizing my website using Docker, and everything is mostly running fine, except for an issue with persistent data. My website is built with a Node.js backend and a MySQL database. I’m using Docker Compose to orchestrate the containers.

Here’s my setup:

  1. Node.js app container for the backend.
  2. MySQL container for the database, with a volume for data persistence.
  3. A volume is mapped for MySQL:
 volumes:  
  - mysql_data:/var/lib/mysql

The problem:

  1. After restarting the MySQL container, the database data is sometimes missing, even though the volume seems correctly defined.
  2. I checked the volume directory on the host machine, and it’s empty. It seems like MySQL is not writing data to the mapped volume.
  3. I’ve also noticed that MySQL takes a long time to start after a restart, throwing errors like:
    [ERROR] InnoDB: Unable to open the datafile ./ibdata1

Steps I’ve tried so far:

  • Ensured correct permissions for the volume directory on the host.
  • Verified that the my.cnf configuration file matches the expected paths.
  • Recreated the containers using docker-compose down and docker-compose up --build.

Still, the issue persists.

I’d appreciate guidance on:

  1. Diagnosing why the volume mapping doesn’t seem to work reliably.
  2. Whether there’s a better way to handle persistent MySQL data in Docker.
  3. Debugging the MySQL startup errors effectively.

Thanks in advance for your help!

2

Important details are missing from your description. We know only that you have a problem with MySQL and its data, but nothing about how you crate the container, how you checked the volume is empty, how you installed Docker, which version on which platform. Please, share these details. A compose file for example could help a lot.

Volumes are not deleted when a container is restarted. Restarting a container is just restarting the process in it. If MySQL cannot read its data, my guess would be that you don’t use the official MySQL image. or override the volume mount with a bind mount, or you changed the image and the new MySQL is not compatible with the old one. The volume would still not be empty

3

Thank you for your reply and the guidance. Let me provide the additional details you’ve requested to help diagnose the issue.
My Compose File:

version: "3.8"
services:
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: mydb
      MYSQL_USER: user
      MYSQL_PASSWORD: password
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "3306:3306"

  app:
    image: node:16-alpine
    working_dir: /usr/src/app
    volumes:
      - .:/usr/src/app
    ports:
      - "3000:3000"
    depends_on:
      - db
volumes:
  mysql_data:

How I Verified the Volume:

  1. I checked the volume’s directory on the host machine using:
    docker volume inspect mysql_data
  • The mount point resolves to /var/lib/docker/volumes/mysql_data/_data (on Linux). This directory appears empty after the MySQL container restarts.
  • I also attempted to inspect the container’s filesystem directly using:
    docker exec -it [mysql-container-id] ls -la /var/lib/mysql
  1. The /var/lib/mysql folder does contain some files during runtime, but they don’t seem to persist across restarts.

My Observations:

  1. Startup Errors: I frequently see errors like:
    [ERROR] InnoDB: Unable to open the datafile './ibdata1'

  2. Could this indicate corruption or an initialization problem with InnoDB?

  3. Image Consistency: I am using the official MySQL image (mysql:8.0) and haven’t overridden the volume mount with a bind mount. However, I have recreated the containers multiple times.

  4. Permission Issues: The host directory permissions are set to drwxr-xr-x, and I’ve ensured that the Docker process has access. Is there anything additional I should check?

Follow-Up Questions:

  1. Could switching to bind mounts (e.g., ./data:/var/lib/mysql) help debug this issue, or are there risks to avoid?
  2. What’s the best way to ensure compatibility when recreating containers (e.g., avoiding data loss during updates)?

While troubleshooting this, I was simultaneously working on editing some project videos using capcut. It made me think about how software like capcut ensures the integrity and persistence of project data. Moreover, if you want to enhance your video editing skills by using capcut pro version but can’t afford, then visit here https://capprocutapk.com/ and download the capcut mod apk for free. Could the MySQL data issue be related to a similar principle, like ensuring proper volume mapping or permissions to retain critical information? Thank you for your time and assistance. Please let me know if there’s anything else I should check or provide! :grinning:

4

There are still missing details

Volume content is never deleted automatically. If it happened to you, there must be something that deletes it like an antivirus maybe. There is nothing in your compose file that would explain the content to be deleted or that you see nothing outside the container but see something inside. Please, share the output of the following commands:

docker info
docker version

dpkg -l | grep docker
snap list docker

Anything you change can help debugging, but you could also have other problems. The volume is also a bind mount basically, just a different one, managed by Docker. But it is true, if you use a bind mount, at least you know what you mount even if you have multiple Docker installation on your machine.

A named volume should work. I usually use bind mounts or named volumes with custom source path which I wrote about in a blogpost.just to avoid accidentally deleting the volume with the data. But if you don’t delete the volume, it will not be deleted automatically.

5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.