01 / THE ROLE
In this lab.
MySQL runs as a containerised database service with persistent database files and configuration. Documented consumers include Semaphore, phpIPAM, Vaultwarden and Firefly III. These applications have separate data and configuration needs even when they share the same database engine.
02 / THE CONNECTIONS
Follow the flow.
- STEP 01Application
- STEP 02Database connection
- STEP 03MySQL
- STEP 04Persistent database files
03 / How it works
How it works.
The application authenticates using its configured database connection and operates on its own schema. Application deployments and database upgrades must be considered together: a schema migration can make an older application version incompatible with the data it now finds.
04 / Persistent data & recovery
Persistent data & recovery.
Recovery needs a consistent database backup, required users and permissions, and the application’s matching files and configuration. Copying active database files arbitrarily is not treated as a validated backup. Credentials are managed outside the public configuration.
05 / How to check it
How to check it.
Check connection, expected schema and an application operation rather than only a listening database port. Resource pressure or database unavailability can affect several applications at once, making database dependencies part of incident triage.
06 / Decisions & limits
Decisions & limits.
A shared engine reduces duplicated infrastructure but concentrates dependencies. A single application’s restart is very different from restarting a database used by multiple services.