The basic problem is that a database server is not what Docker is trying to containerize. They want to containerize applications which used to be clear cut things. They used to be single purpose things built by compiling and linking some source code into a single binary. They did not contain everything including the kitchen sink and a plumbing kit complete with automatic drain clearing snake.
Today's database server, and this includes more than just the RDBMSes, are actually a collection of applications. Even if the developers have the bright idea of integrating it all into one binary, it is still not a traditional app. It is a collection of apps built into one binary, like busybox.
To truly dockerize a db server, it would need to be built differently, as a collection of separate, semi-independent apps, that have clearly defined interfaces between each other. Until that day arrives better to use something like Ansible to manage your monolithic db server on it's own instance.
Docker doesn't buy you anything with db servers because you generally want stability. I know some people are experimenting with highly scalable clusters of db servers, and using things like MySQL in a way that was never intended, but they know they are on the bleeding edge. I also expect them to soon start hacking away the bits of the RDBMS monolith that they do not need, and building single purpose cluster members that only do one of the jobs in a normal RDBMS. It might work; give them time.
But if you have to run a db to support your business, don't do it with Docker. I run PostgreSQL and right beside the monolithic RDBMS there is a docker host that runs miscellaneous support stuff like serving up pgBadger data, running a REST interface to data, running an app that listens to PostgreSQL NOTIFY events using Camel pgconnect, and some other admin tools (simple webapps to do db related stuff). Docker has a role, but running the main RDBMS is not it.