Update docker images to modify mysql configuration

Dockerfiles are updated with two key changes:
- use streamline's official images as a base
- replace two files related to mysql configuration

A README.md file is added to the docker folder which details the changes, but
the key difference is to limit binary logs to only the `streamline` database.
This prevents additional system databases from being included, which the
database sync tools do not (yet) support.

An unrelated bugfix corrects the docker-compose image tag, specifying 'latest'
instead of a previously hard-coded version.
This commit is contained in:
2024-03-10 14:51:17 -07:00
parent e88aef18f4
commit 63ba4d29c8
7 changed files with 165 additions and 4 deletions
+16
View File
@@ -0,0 +1,16 @@
# Image Notes
The base images used have a few issues that should be addressed, specifically:
- quite a few files seem to be unused, taking up space unnecessarily and making it difficult to follow
- services should ideally be run in separate docker containers - this looks to have been at least partially implemented, but is not currently used
- mysql configuration is managed in several places, in particular with respect to binary logging
- binary logging needs to be configured slightly differently to work reliably with Signalytic tools (in their current state)
A minimal set of changes has been made to the images in order to implement an initial prototype system, this includes:
- modify `/etc/mysql/my.cnf`
- limit binary logging to the `streamline` database only (`binlog-do-db=streamline`)
- remove binary log size limit (`max_binlog_size`)
- modify `/var/www/html/.docker/mysql/mysql-init.sh`
- remove binary log configuration from `mysqld` commands, using `my.cnf` as the sole configuration source (`--log-basename=bin --log-bin=/var/lib/mysql/logs/bin`)
The reason for these changes is that the Signalytic database sync tools currently work with only a single database at a time. When using MariaDB, several system databases are generated automatically, generating additional binary logs that we are not interested in. When attempting to later apply the binary logs to a database server, conflicts may arise. An alternative approach would be to drop all databases instead, this is worth investigating in the future.