mirror of
https://gitlab.com/signalytic/client-external/streamline/streamline-emr.git
synced 2026-09-11 18:51:31 +00:00
alec.turner
63ba4d29c8
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.
1.5 KiB
1.5 KiB
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
streamlinedatabase only (binlog-do-db=streamline) - remove binary log size limit (
max_binlog_size)
- limit binary logging to the
- modify
/var/www/html/.docker/mysql/mysql-init.sh- remove binary log configuration from
mysqldcommands, usingmy.cnfas the sole configuration source (--log-basename=bin --log-bin=/var/lib/mysql/logs/bin)
- remove binary log configuration from
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.