Snapshot errors

Errors

  1. Couldn’t ensure that exactly snapshots exist because an error occurred: . For more information about snapshots, visit: memgr.ph/snapshots.
  2. Couldn’t ensure that only the absolutely necessary WAL files exist because an error occurred: . For more details, visit: memgr.ph/snapshots.

What are snapshots?

Database snapshots are like a view of a database as it was at a certain point in time. It is a read-only copy of the data that can be used for backup or data persistence. Memgraph will try to load the newest snapshot file on startup.

What to do with corrupt snapshots?

Because snapshots are read-only, any modifications will result in corrupt files that won’t be loaded. The solution is to delete the snapshot files and to start Memgraph again.

Why is data lost when Memgraph is restarted?

When you stop a Docker container, the data and state within that container are preserved until the container is explicitly removed. This means that any data or changes you’ve made within the container are retained and can be accessed again when the container is restarted.

To access this data, you need to ensure you’re starting the same container instance that you used previously. Here’s how you can do that:

Starting a Named Container

If you had named your Memgraph container as “memgraph”, for instance, you can easily restart it using the following command:

docker start memgraph

This command will bring the named container back to life, retaining all the data and changes you had made in it.

Starting an Unnamed Container

If you didn’t assign a specific name to your container when you created it, Docker would have given it a random name. To find and restart the correct container list all the containers on your system using the following command:

docker ps -a

From the list, identify the container you want to restart. Note down the container ID associated with it and use it to restart the container:

docker start [CONTAINER_ID]

Replace [CONTAINER_ID] with the actual ID you noted down. Once executed, your container will be up and running again, with all its data intact.

Why can’t I see a snapshot in the Cloud interface after I call the CREATE SNAPSHOT command?

When you run the CREATE SNAPSHOT command in Memgraph, it creates a snapshot file on the disk. However, this snapshot won’t automatically show up in the Cloud interface. The snapshots you see in the Cloud interface are copies of the entire disk (like an AWS EBS volume), which includes any Memgraph snapshots. Since the Cloud service doesn’t have access to Memgraph’s internal commands for security reasons, it can’t automatically create a new disk copy when you use CREATE SNAPSHOT in Memgraph. So, while the command creates a snapshot locally, it doesn’t trigger a new snapshot in the Cloud interface.

Why am I seeing corrupt snapshot files named _edge_part_ and _vertex_part_?

These files are partial results from the multi-threaded execution of snapshot creation. When Memgraph creates snapshots using multiple threads, it divides the data into smaller parts. Each thread processes a specific part and writes intermediate results to files named with the _edge_part_ and _vertex_part_ patterns.

If the snapshot creation process is interrupted or fails, these partial files may remain on disk and appear as corrupt. Memgraph cannot load these incomplete files during startup, as they do not represent a valid snapshot.

How to resolve this issue?

To resolve this issue, you can safely delete the partial files and restart Memgraph. The database will attempt to recover its state using the most recent valid snapshot and the write-ahead log (WAL) files.

rm /var/lib/memgraph/snapshots/*_edge_part_*
rm /var/lib/memgraph/snapshots/*_vertex_part_*