The root cause of this issue was the absence of the relay-log option in the mysql.cnf file (or in this case, due to the docker volume mounts, the docker.cnf file). This lead to the creation and usage of files such as 89726507f176-relay-bin.000002 initially, where 89726507f176 is the host name of the machine (randomly assigned by the docker daemon when an image is created). When the container was stopped, removed and recreated, a new set of files was created and used (e.g. be0c801d95bc-relay-bin.000407) but this caused sync issues.
By explicitly specifying a value for relay-log in the docker.cnf file the container was able to be removed and recreated without problems.
As a side note, I suggested also that there was a problem with the /var/log/mysql directory not being mounted - this is not the case. If however you specify a value of log_bin = /var/log/mysql/mysql-bin.log for example, then this is a requirement. If you do not specify this path, it seems the binary logs are stored locally in /var/lib/mysql which is already mounted outside the container.
My final docker.cnf file is as follows:
[mysqld]
skip-host-cache
skip-name-resolve
bind-address = 0.0.0.0
binlog-ignore-db = mysql
replicate-ignore-db = mysql
log_bin = /var/log/mysql/mysql-bin.log
relay-log = replication-1
server_id = 1
Note: server_id = 2 on the replication slave.
Also note that without the relay-log option the command SHOW MASTER STATUS; returned no results on the master database container.
There is a possible outstanding issue yet which is that by default when you use docker stop it asks the container to terminate (by sending a SIGHUP to the docker entrypoint command) and if it doesn't terminate within 10 seconds it is forcefully stopped. I need to ensure taht this is given sufficient time to shut down as it could take a little while to sort itself out while under load, possibly resulting in data loss as a result.
2 options;
- Build the container and ADD or COPY a my.cnf file into place with your desired options.
- Bind mount a config file into the container as part of the run command
I think there’s possibly a 3rd but I’m not in the position to test but you can possibly add startup options to the docker run command e.g.
docker run -d {other necessary options} mysql/mysql-server:latest —lower-case-table-names
Best Answer
Can you show us the command you used to launch the Percona Server for MySQL 5.7 container? You need to ensure you are allowing access to 3306/tcp.
Otherwise from PMM Server perspective there will be nothing unique to your use case of running Percona Server for MYSQL from docker or via yum/apt-get, the mysqld_exporter will connect to 3306/tcp and collect MySQL metrics as needed.
You will be missing collection of node_exporter data so you won't have anything on your Disk Performance, Disk Space, etc graphs.