mariadb-docker/docker-entrypoint.sh

504 lines
18 KiB
Bash
Raw Normal View History

#!/bin/bash
set -eo pipefail
shopt -s nullglob
# logging functions
mysql_log() {
local type="$1"; shift
printf '%s [%s] [Entrypoint]: %s\n' "$(date --rfc-3339=seconds)" "$type" "$*"
}
mysql_note() {
mysql_log Note "$@"
}
mysql_warn() {
mysql_log Warn "$@" >&2
}
mysql_error() {
mysql_log ERROR "$@" >&2
exit 1
}
2016-02-24 15:51:13 -08:00
# usage: file_env VAR [DEFAULT]
# ie: file_env 'XYZ_DB_PASSWORD' 'example'
# (will allow for "$XYZ_DB_PASSWORD_FILE" to fill in the value of
# "$XYZ_DB_PASSWORD" from a file, especially for Docker's secrets feature)
file_env() {
local var="$1"
local fileVar="${var}_FILE"
local def="${2:-}"
if [ "${!var:-}" ] && [ "${!fileVar:-}" ]; then
mysql_error "Both $var and $fileVar are set (but are exclusive)"
fi
local val="$def"
if [ "${!var:-}" ]; then
val="${!var}"
elif [ "${!fileVar:-}" ]; then
val="$(< "${!fileVar}")"
fi
export "$var"="$val"
unset "$fileVar"
}
# set MARIADB_xyz from MYSQL_xyz when MARIADB_xyz is unset
# and make them the same value (so user scripts can use either)
_mariadb_file_env() {
local var="$1"; shift
local maria="MARIADB_${var#MYSQL_}"
file_env "$var" "$@"
file_env "$maria" "${!var}"
if [ "${!maria:-}" ]; then
export "$var"="${!maria}"
fi
}
# check to see if this file is being run or sourced from another script
_is_sourced() {
# https://unix.stackexchange.com/a/215279
[ "${#FUNCNAME[@]}" -ge 2 ] \
&& [ "${FUNCNAME[0]}" = '_is_sourced' ] \
&& [ "${FUNCNAME[1]}" = 'source' ]
}
# usage: docker_process_init_files [file [file [...]]]
# ie: docker_process_init_files /always-initdb.d/*
# process initializer files, based on file extensions
docker_process_init_files() {
# mysql here for backwards compatibility "${mysql[@]}"
# ShellCheck: mysql appears unused. Verify use (or export if used externally)
# shellcheck disable=SC2034
mysql=( docker_process_sql )
echo
local f
for f; do
case "$f" in
*.sh)
# https://github.com/docker-library/postgres/issues/450#issuecomment-393167936
# https://github.com/docker-library/postgres/pull/452
if [ -x "$f" ]; then
mysql_note "$0: running $f"
"$f"
else
mysql_note "$0: sourcing $f"
# ShellCheck can't follow non-constant source. Use a directive to specify location.
# shellcheck disable=SC1090
. "$f"
fi
;;
*.sql) mysql_note "$0: running $f"; docker_process_sql < "$f"; echo ;;
*.sql.gz) mysql_note "$0: running $f"; gunzip -c "$f" | docker_process_sql; echo ;;
*.sql.xz) mysql_note "$0: running $f"; xzcat "$f" | docker_process_sql; echo ;;
*.sql.zst) mysql_note "$0: running $f"; zstd -dc "$f" | docker_process_sql; echo ;;
*) mysql_warn "$0: ignoring $f" ;;
esac
echo
done
}
# arguments necessary to run "mysqld --verbose --help" successfully (used for testing configuration validity and for extracting default/configured values)
_verboseHelpArgs=(
--verbose --help
--log-bin-index="$(mktemp -u)" # https://github.com/docker-library/mysql/issues/136
)
mysql_check_config() {
local toRun=( "$@" "${_verboseHelpArgs[@]}" ) errors
if ! errors="$("${toRun[@]}" 2>&1 >/dev/null)"; then
mysql_error $'mysqld failed while attempting to check config\n\tcommand was: '"${toRun[*]}"$'\n\t'"$errors"
fi
}
# Fetch value from server config
# We use mysqld --verbose --help instead of my_print_defaults because the
# latter only show values present in config files, and not server defaults
mysql_get_config() {
local conf="$1"; shift
"$@" "${_verboseHelpArgs[@]}" 2>/dev/null \
| awk -v conf="$conf" '$1 == conf && /^[^ \t]/ { sub(/^[^ \t]+[ \t]+/, ""); print; exit }'
# match "datadir /some/path with/spaces in/it here" but not "--xyz=abc\n datadir (xyz)"
2016-05-17 12:48:56 -07:00
}
2021-03-16 13:15:36 +11:00
# Do a temporary startup of the MariaDB server, for init purposes
docker_temp_server_start() {
"$@" --skip-networking --default-time-zone=SYSTEM --socket="${SOCKET}" --wsrep_on=OFF --skip-log-bin \
--loose-innodb_buffer_pool_load_at_startup=0 &
declare -g MARIADB_PID
MARIADB_PID=$!
mysql_note "Waiting for server startup"
# only use the root password if the database has already been initializaed
# so that it won't try to fill in a password file when it hasn't been set yet
extraArgs=()
if [ -z "$DATABASE_ALREADY_EXISTS" ]; then
extraArgs+=( '--dont-use-mysql-root-password' )
fi
local i
for i in {30..0}; do
if docker_process_sql "${extraArgs[@]}" --database=mysql <<<'SELECT 1' &> /dev/null; then
break
fi
sleep 1
done
if [ "$i" = 0 ]; then
mysql_error "Unable to start server."
fi
}
# Stop the server. When using a local socket file mysqladmin will block until
# the shutdown is complete.
docker_temp_server_stop() {
if ! MYSQL_PWD=$MARIADB_ROOT_PASSWORD mysqladmin shutdown -uroot --socket="${SOCKET}"; then
mysql_error "Unable to shut down server."
fi
}
# Verify that the minimally required password settings are set for new databases.
docker_verify_minimum_env() {
if [ -z "$MARIADB_ROOT_PASSWORD" ] && [ -z "$MARIADB_ALLOW_EMPTY_ROOT_PASSWORD" ] && [ -z "$MARIADB_RANDOM_ROOT_PASSWORD" ]; then
mysql_error $'Database is uninitialized and password option is not specified\n\tYou need to specify one of MARIADB_ROOT_PASSWORD, MARIADB_ALLOW_EMPTY_ROOT_PASSWORD and MARIADB_RANDOM_ROOT_PASSWORD'
fi
}
# creates folders for the database
# also ensures permission for user mysql of run as root
docker_create_db_directories() {
local user; user="$(id -u)"
# TODO other directories that are used by default? like /var/lib/mysql-files
# see https://github.com/docker-library/mysql/issues/562
2016-05-17 12:48:56 -07:00
mkdir -p "$DATADIR"
if [ "$user" = "0" ]; then
# this will cause less disk access than `chown -R`
change group ownership on datadir/socket dir Before (singualriy - 3.8.5) $ find ~/mydatadir/ -ls 1573002 4 drwxrwxr-x 4 100998 dan 4096 Feb 3 19:18 /home/dan/mydatadir/ 1573309 4 -rw-rw---- 1 100998 100998 976 Feb 3 19:18 /home/dan/mydatadir/ib_buffer_pool 1573176 4 -rw-rw---- 1 100998 100998 52 Feb 3 19:18 /home/dan/mydatadir/aria_log_control 1573227 12292 -rw-rw---- 1 100998 100998 12582912 Feb 3 19:18 /home/dan/mydatadir/ibdata1 1573178 32 -rw-rw---- 1 100998 100998 32768 Feb 3 19:18 /home/dan/mydatadir/aria_log.00000001 1573268 4 drwx------ 2 100998 100998 4096 Feb 3 19:18 /home/dan/mydatadir/mysql find: ‘/home/dan/mydatadir/mysql’: Permission denied 1573359 4 drwx------ 2 100998 100998 4096 Feb 3 19:18 /home/dan/mydatadir/performance_schema find: ‘/home/dan/mydatadir/performance_schema’: Permission denied 1573266 98304 -rw-rw---- 1 100998 100998 100663296 Feb 3 19:18 /home/dan/mydatadir/ib_logfile0 1573362 0 -rw-rw---- 1 100998 100998 0 Feb 3 19:18 /home/dan/mydatadir/multi-master.info 1573267 12288 -rw-rw---- 1 100998 100998 12582912 Feb 3 19:18 /home/dan/mydatadir/ibtmp1 After: $ find ~/mydatadir/ -ls 1573002 4 drwxrwxr-x 4 100998 100998 4096 Feb 3 20:26 /home/dan/mydatadir/ 1573206 4 -rw-rw---- 1 100998 100998 976 Feb 3 20:26 /home/dan/mydatadir/ib_buffer_pool 1573267 4 -rw-rw---- 1 100998 100998 52 Feb 3 20:26 /home/dan/mydatadir/aria_log_control 1573269 12292 -rw-rw---- 1 100998 100998 12582912 Feb 3 20:26 /home/dan/mydatadir/ibdata1 1573268 18348 -rw-rw---- 1 100998 100998 18784256 Feb 3 20:26 /home/dan/mydatadir/aria_log.00000001 1573272 4 drwx------ 2 100998 100998 4096 Feb 3 20:26 /home/dan/mydatadir/mysql find: ‘/home/dan/mydatadir/mysql’: Permission denied 1573363 4 drwx------ 2 100998 100998 4096 Feb 3 20:25 /home/dan/mydatadir/performance_schema find: ‘/home/dan/mydatadir/performance_schema’: Permission denied 1573270 98304 -rw-rw---- 1 100998 100998 100663296 Feb 3 20:26 /home/dan/mydatadir/ib_logfile0 1573367 0 -rw-rw---- 1 100998 100998 0 Feb 3 20:25 /home/dan/mydatadir/multi-master.info 1573271 4 -rw-rw-r-- 1 100998 100998 15 Feb 3 20:25 /home/dan/mydatadir/mysql_upgrade_info 1573209 12288 -rw-rw---- 1 100998 100998 12582912 Feb 3 20:26 /home/dan/mydatadir/ibtmp1 Closes #401
2022-02-04 09:57:28 +11:00
find "$DATADIR" \! -user mysql -exec chown mysql: '{}' +
# See https://github.com/MariaDB/mariadb-docker/issues/363
change group ownership on datadir/socket dir Before (singualriy - 3.8.5) $ find ~/mydatadir/ -ls 1573002 4 drwxrwxr-x 4 100998 dan 4096 Feb 3 19:18 /home/dan/mydatadir/ 1573309 4 -rw-rw---- 1 100998 100998 976 Feb 3 19:18 /home/dan/mydatadir/ib_buffer_pool 1573176 4 -rw-rw---- 1 100998 100998 52 Feb 3 19:18 /home/dan/mydatadir/aria_log_control 1573227 12292 -rw-rw---- 1 100998 100998 12582912 Feb 3 19:18 /home/dan/mydatadir/ibdata1 1573178 32 -rw-rw---- 1 100998 100998 32768 Feb 3 19:18 /home/dan/mydatadir/aria_log.00000001 1573268 4 drwx------ 2 100998 100998 4096 Feb 3 19:18 /home/dan/mydatadir/mysql find: ‘/home/dan/mydatadir/mysql’: Permission denied 1573359 4 drwx------ 2 100998 100998 4096 Feb 3 19:18 /home/dan/mydatadir/performance_schema find: ‘/home/dan/mydatadir/performance_schema’: Permission denied 1573266 98304 -rw-rw---- 1 100998 100998 100663296 Feb 3 19:18 /home/dan/mydatadir/ib_logfile0 1573362 0 -rw-rw---- 1 100998 100998 0 Feb 3 19:18 /home/dan/mydatadir/multi-master.info 1573267 12288 -rw-rw---- 1 100998 100998 12582912 Feb 3 19:18 /home/dan/mydatadir/ibtmp1 After: $ find ~/mydatadir/ -ls 1573002 4 drwxrwxr-x 4 100998 100998 4096 Feb 3 20:26 /home/dan/mydatadir/ 1573206 4 -rw-rw---- 1 100998 100998 976 Feb 3 20:26 /home/dan/mydatadir/ib_buffer_pool 1573267 4 -rw-rw---- 1 100998 100998 52 Feb 3 20:26 /home/dan/mydatadir/aria_log_control 1573269 12292 -rw-rw---- 1 100998 100998 12582912 Feb 3 20:26 /home/dan/mydatadir/ibdata1 1573268 18348 -rw-rw---- 1 100998 100998 18784256 Feb 3 20:26 /home/dan/mydatadir/aria_log.00000001 1573272 4 drwx------ 2 100998 100998 4096 Feb 3 20:26 /home/dan/mydatadir/mysql find: ‘/home/dan/mydatadir/mysql’: Permission denied 1573363 4 drwx------ 2 100998 100998 4096 Feb 3 20:25 /home/dan/mydatadir/performance_schema find: ‘/home/dan/mydatadir/performance_schema’: Permission denied 1573270 98304 -rw-rw---- 1 100998 100998 100663296 Feb 3 20:26 /home/dan/mydatadir/ib_logfile0 1573367 0 -rw-rw---- 1 100998 100998 0 Feb 3 20:25 /home/dan/mydatadir/multi-master.info 1573271 4 -rw-rw-r-- 1 100998 100998 15 Feb 3 20:25 /home/dan/mydatadir/mysql_upgrade_info 1573209 12288 -rw-rw---- 1 100998 100998 12582912 Feb 3 20:26 /home/dan/mydatadir/ibtmp1 Closes #401
2022-02-04 09:57:28 +11:00
find "${SOCKET%/*}" -maxdepth 0 \! -user mysql -exec chown mysql: '{}' \;
fi
}
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
_mariadb_version() {
local mariaVersion="${MARIADB_VERSION##*:}"
mariaVersion="${mariaVersion%%[-+~]*}"
echo -n "${mariaVersion}-MariaDB"
}
# initializes the database directory
docker_init_database_dir() {
mysql_note "Initializing database files"
installArgs=( --datadir="$DATADIR" --rpm --auth-root-authentication-method=normal )
if { mysql_install_db --help || :; } | grep -q -- '--skip-test-db'; then
# 10.3+
installArgs+=( --skip-test-db )
else
# 10.2 only
installArgs+=( --skip-auth-anonymous-user )
fi
# "Other options are passed to mysqld." (so we pass all "mysqld" arguments directly here)
mysql_install_db "${installArgs[@]}" "${@:2}" \
--default-time-zone=SYSTEM --enforce-storage-engine= --skip-log-bin \
--loose-innodb_buffer_pool_load_at_startup=0 \
--loose-innodb_buffer_pool_dump_at_shutdown=0
mysql_note "Database files initialized"
}
# Loads various settings that are used elsewhere in the script
# This should be called after mysql_check_config, but before any other functions
docker_setup_env() {
# Get config
declare -g DATADIR SOCKET
DATADIR="$(mysql_get_config 'datadir' "$@")"
SOCKET="$(mysql_get_config 'socket' "$@")"
# Initialize values that might be stored in a file
_mariadb_file_env 'MYSQL_ROOT_HOST' '%'
_mariadb_file_env 'MYSQL_DATABASE'
_mariadb_file_env 'MYSQL_USER'
_mariadb_file_env 'MYSQL_PASSWORD'
_mariadb_file_env 'MYSQL_ROOT_PASSWORD'
# set MARIADB_ from MYSQL_ when it is unset and then make them the same value
: "${MARIADB_ALLOW_EMPTY_ROOT_PASSWORD:=${MYSQL_ALLOW_EMPTY_PASSWORD:-}}"
export MYSQL_ALLOW_EMPTY_PASSWORD="$MARIADB_ALLOW_EMPTY_ROOT_PASSWORD" MARIADB_ALLOW_EMPTY_ROOT_PASSWORD
: "${MARIADB_RANDOM_ROOT_PASSWORD:=${MYSQL_RANDOM_ROOT_PASSWORD:-}}"
export MYSQL_RANDOM_ROOT_PASSWORD="$MARIADB_RANDOM_ROOT_PASSWORD" MARIADB_RANDOM_ROOT_PASSWORD
: "${MARIADB_INITDB_SKIP_TZINFO:=${MYSQL_INITDB_SKIP_TZINFO:-}}"
export MYSQL_INITDB_SKIP_TZINFO="$MARIADB_INITDB_SKIP_TZINFO" MARIADB_INITDB_SKIP_TZINFO
declare -g DATABASE_ALREADY_EXISTS
if [ -d "$DATADIR/mysql" ]; then
DATABASE_ALREADY_EXISTS='true'
fi
}
# Execute the client, use via docker_process_sql to handle root password
docker_exec_client() {
# args sent in can override this db, since they will be later in the command
if [ -n "$MYSQL_DATABASE" ]; then
set -- --database="$MYSQL_DATABASE" "$@"
fi
mysql --protocol=socket -uroot -hlocalhost --socket="${SOCKET}" "$@"
}
# Execute sql script, passed via stdin
# usage: docker_process_sql [--dont-use-mysql-root-password] [mysql-cli-args]
# ie: docker_process_sql --database=mydb <<<'INSERT ...'
# ie: docker_process_sql --dont-use-mysql-root-password --database=mydb <my-file.sql
docker_process_sql() {
if [ '--dont-use-mysql-root-password' = "$1" ]; then
shift
MYSQL_PWD='' docker_exec_client "$@"
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
else
MYSQL_PWD=$MARIADB_ROOT_PASSWORD docker_exec_client "$@"
fi
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
}
# SQL escape the string $1 to be placed in a string literal.
# escape, \ followed by '
docker_sql_escape_string_literal() {
local newline=$'\n'
local escaped=${1//\\/\\\\}
escaped="${escaped//$newline/\\n}"
echo "${escaped//\'/\\\'}"
}
# Initializes database with timezone info and root password, plus optional extra db/user
docker_setup_db() {
# Load timezone info into database
if [ -z "$MARIADB_INITDB_SKIP_TZINFO" ]; then
mysql_tzinfo_to_sql --skip-write-binlog /usr/share/zoneinfo \
| docker_process_sql --dont-use-mysql-root-password --database=mysql
# tell docker_process_sql to not use MYSQL_ROOT_PASSWORD since it is not set yet
fi
# Generate random root password
if [ -n "$MARIADB_RANDOM_ROOT_PASSWORD" ]; then
MARIADB_ROOT_PASSWORD="$(pwgen --numerals --capitalize --symbols --remove-chars="'\\" -1 32)"
export MARIADB_ROOT_PASSWORD MYSQL_ROOT_PASSWORD=$MARIADB_ROOT_PASSWORD
mysql_note "GENERATED ROOT PASSWORD: $MARIADB_ROOT_PASSWORD"
fi
# Sets root password and creates root users for non-localhost hosts
local rootCreate=
local rootPasswordEscaped
rootPasswordEscaped=$( docker_sql_escape_string_literal "${MARIADB_ROOT_PASSWORD}" )
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
# default root to listen for connections from anywhere
if [ -n "$MARIADB_ROOT_HOST" ] && [ "$MARIADB_ROOT_HOST" != 'localhost' ]; then
# no, we don't care if read finds a terminating character in this heredoc
# https://unix.stackexchange.com/questions/265149/why-is-set-o-errexit-breaking-this-read-heredoc-expression/265151#265151
read -r -d '' rootCreate <<-EOSQL || true
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
CREATE USER 'root'@'${MARIADB_ROOT_HOST}' IDENTIFIED BY '${rootPasswordEscaped}' ;
GRANT ALL ON *.* TO 'root'@'${MARIADB_ROOT_HOST}' WITH GRANT OPTION ;
EOSQL
fi
MDEV-27732: Add env MARIADB_MYSQL_LOCALHOST_{USER,GRANTS} We create a mysql@localhost user under MARIADB_MYSQL_LOCALHOST_USER=1 with its default USAGE privileges. This gives access to SHOW GLOBAL STATUS/VARIABLES but no other real access including database visibility or process visibility. Being a @localhost this restricts access to via the unix socket. The level of access can be increased controlled by the environment variable MARIADB_MYSQL_LOCALHOST_GRANTS. If you are using monitoring replication or processes addition privileges are required, and the setting of the environment variable is the comma separated list of grants possible. For the moment, these are a set of global grants only. If you share the unix socket location, /var/run/mysqld by default, as a volume with another container, you have effectively given that container the mysql@localhost provided they have the same uid map or can create arbitrary users. This can be good for things like backup. This would require the datadir volume as well and the set of privileges (https://mariadb.com/kb/en/mariabackup-overview/#authentication-and-privileges). Any grants of UPDATE on mysql database will mean that the mysql@localhost user can manipulate any other user, potentially transparently adding unix_socket auth (in 10.4+), and the being able to gain their privileges. Grants of CREATE USER, or INSERT on the mysql database allow the creation of user and privilege escalation. For these reasons, ALL for MARIADB_MYSQL_LOCALHOST_GRANTS gains a warning. Many thanks to Daniel Rudolf for all the reviews and the support to develop this feature.
2022-02-01 17:50:49 +11:00
local mysqlAtLocalhost=
local mysqlAtLocalhostGrants=
# Install mysql@localhost user
if [ -n "$MARIADB_MYSQL_LOCALHOST_USER" ]; then
MDEV-27732: Add env MARIADB_MYSQL_LOCALHOST_{USER,GRANTS} We create a mysql@localhost user under MARIADB_MYSQL_LOCALHOST_USER=1 with its default USAGE privileges. This gives access to SHOW GLOBAL STATUS/VARIABLES but no other real access including database visibility or process visibility. Being a @localhost this restricts access to via the unix socket. The level of access can be increased controlled by the environment variable MARIADB_MYSQL_LOCALHOST_GRANTS. If you are using monitoring replication or processes addition privileges are required, and the setting of the environment variable is the comma separated list of grants possible. For the moment, these are a set of global grants only. If you share the unix socket location, /var/run/mysqld by default, as a volume with another container, you have effectively given that container the mysql@localhost provided they have the same uid map or can create arbitrary users. This can be good for things like backup. This would require the datadir volume as well and the set of privileges (https://mariadb.com/kb/en/mariabackup-overview/#authentication-and-privileges). Any grants of UPDATE on mysql database will mean that the mysql@localhost user can manipulate any other user, potentially transparently adding unix_socket auth (in 10.4+), and the being able to gain their privileges. Grants of CREATE USER, or INSERT on the mysql database allow the creation of user and privilege escalation. For these reasons, ALL for MARIADB_MYSQL_LOCALHOST_GRANTS gains a warning. Many thanks to Daniel Rudolf for all the reviews and the support to develop this feature.
2022-02-01 17:50:49 +11:00
local pw=
pw="$(pwgen --numerals --capitalize --symbols --remove-chars="'\\" -1 32)"
# MDEV-24111 before MariaDB-10.4 cannot create unix_socket user directly auth with simple_password_check
# It wasn't until 10.4 that the unix_socket auth was built in to the server.
read -r -d '' mysqlAtLocalhost <<-EOSQL || true
EXECUTE IMMEDIATE IF(VERSION() RLIKE '^10\.[23]\.',
"INSTALL PLUGIN /*M10401 IF NOT EXISTS */ unix_socket SONAME 'auth_socket'",
"SELECT 'already there'");
CREATE USER mysql@localhost IDENTIFIED BY '$pw';
ALTER USER mysql@localhost IDENTIFIED VIA unix_socket;
EOSQL
if [ -n "$MARIADB_MYSQL_LOCALHOST_GRANTS" ]; then
if [ "$MARIADB_MYSQL_LOCALHOST_GRANTS" != USAGE ]; then
mysql_warn "Excessive privileges ON *.* TO mysql@localhost facilitates risks to the confidentiality, integrity and availability of data stored"
MDEV-27732: Add env MARIADB_MYSQL_LOCALHOST_{USER,GRANTS} We create a mysql@localhost user under MARIADB_MYSQL_LOCALHOST_USER=1 with its default USAGE privileges. This gives access to SHOW GLOBAL STATUS/VARIABLES but no other real access including database visibility or process visibility. Being a @localhost this restricts access to via the unix socket. The level of access can be increased controlled by the environment variable MARIADB_MYSQL_LOCALHOST_GRANTS. If you are using monitoring replication or processes addition privileges are required, and the setting of the environment variable is the comma separated list of grants possible. For the moment, these are a set of global grants only. If you share the unix socket location, /var/run/mysqld by default, as a volume with another container, you have effectively given that container the mysql@localhost provided they have the same uid map or can create arbitrary users. This can be good for things like backup. This would require the datadir volume as well and the set of privileges (https://mariadb.com/kb/en/mariabackup-overview/#authentication-and-privileges). Any grants of UPDATE on mysql database will mean that the mysql@localhost user can manipulate any other user, potentially transparently adding unix_socket auth (in 10.4+), and the being able to gain their privileges. Grants of CREATE USER, or INSERT on the mysql database allow the creation of user and privilege escalation. For these reasons, ALL for MARIADB_MYSQL_LOCALHOST_GRANTS gains a warning. Many thanks to Daniel Rudolf for all the reviews and the support to develop this feature.
2022-02-01 17:50:49 +11:00
fi
mysqlAtLocalhostGrants="GRANT ${MARIADB_MYSQL_LOCALHOST_GRANTS} ON *.* TO mysql@localhost;";
fi
fi
mysql_note "Securing system users (equivalent to running mysql_secure_installation)"
# tell docker_process_sql to not use MARIADB_ROOT_PASSWORD since it is just now being set
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
# --binary-mode to save us from the semi-mad users go out of their way to confuse the encoding.
docker_process_sql --dont-use-mysql-root-password --database=mysql --binary-mode <<-EOSQL
-- What's done in this file shouldn't be replicated
-- or products like mysql-fabric won't work
SET @@SESSION.SQL_LOG_BIN=0;
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
-- we need the SQL_MODE NO_BACKSLASH_ESCAPES mode to be clear for the password to be set
SET @@SESSION.SQL_MODE=REPLACE(@@SESSION.SQL_MODE, 'NO_BACKSLASH_ESCAPES', '');
DROP USER IF EXISTS root@'127.0.0.1', root@'::1';
EXECUTE IMMEDIATE CONCAT('DROP USER IF EXISTS root@\'', @@hostname,'\'');
SET PASSWORD FOR 'root'@'localhost'=PASSWORD('${rootPasswordEscaped}') ;
${rootCreate}
MDEV-27732: Add env MARIADB_MYSQL_LOCALHOST_{USER,GRANTS} We create a mysql@localhost user under MARIADB_MYSQL_LOCALHOST_USER=1 with its default USAGE privileges. This gives access to SHOW GLOBAL STATUS/VARIABLES but no other real access including database visibility or process visibility. Being a @localhost this restricts access to via the unix socket. The level of access can be increased controlled by the environment variable MARIADB_MYSQL_LOCALHOST_GRANTS. If you are using monitoring replication or processes addition privileges are required, and the setting of the environment variable is the comma separated list of grants possible. For the moment, these are a set of global grants only. If you share the unix socket location, /var/run/mysqld by default, as a volume with another container, you have effectively given that container the mysql@localhost provided they have the same uid map or can create arbitrary users. This can be good for things like backup. This would require the datadir volume as well and the set of privileges (https://mariadb.com/kb/en/mariabackup-overview/#authentication-and-privileges). Any grants of UPDATE on mysql database will mean that the mysql@localhost user can manipulate any other user, potentially transparently adding unix_socket auth (in 10.4+), and the being able to gain their privileges. Grants of CREATE USER, or INSERT on the mysql database allow the creation of user and privilege escalation. For these reasons, ALL for MARIADB_MYSQL_LOCALHOST_GRANTS gains a warning. Many thanks to Daniel Rudolf for all the reviews and the support to develop this feature.
2022-02-01 17:50:49 +11:00
${mysqlAtLocalhost}
${mysqlAtLocalhostGrants}
-- pre-10.3
DROP DATABASE IF EXISTS test ;
EOSQL
# Creates a custom database and user if specified
if [ -n "$MARIADB_DATABASE" ]; then
mysql_note "Creating database ${MARIADB_DATABASE}"
docker_process_sql --database=mysql <<<"CREATE DATABASE IF NOT EXISTS \`$MARIADB_DATABASE\` ;"
fi
if [ -n "$MARIADB_USER" ] && [ -n "$MARIADB_PASSWORD" ]; then
mysql_note "Creating user ${MARIADB_USER}"
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
# SQL escape the user password, \ followed by '
local userPasswordEscaped
userPasswordEscaped=$( docker_sql_escape_string_literal "${MARIADB_PASSWORD}" )
SQL escape passwords To correctly SQL escape passwords, escaping \ first is required. Then we need to escape ' in the password to prevent it being treated as a end of SQL statement quote. All escaping needs to use \, so we cannot be in NO_BACKSLASH_ESCAPES sql_mode otherwise no escaping will work. Getting bash to escape the root password for its internal uses and in a form that was recognized by MariaDB reading the configuration file was becoming exceptionally complicated, and unsuccessful. As such we use the MYSQL_PWD environment variable to contain the password when needed. Occasionally the socket wasn't ready on a clean install by the time docker_process_sql was called so allow up to 5 seconds just in case. example logs of this: 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Waiting for server startup 2021-03-16 0:41:21 140680894076608 [Note] mysqld (mysqld 10.2.37-MariaDB-1:10.2.37+maria~bionic) starting as process 111 ... 2021-03-16 00:41:21+00:00 [Note] [Entrypoint]: Temporary server started. 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Uses event mutexes 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Compressed tables use zlib 1.2.11 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using Linux native AIO 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Number of pools: 1 2021-03-16 0:41:21 140680894076608 [Note] InnoDB: Using SSE2 crc32 instructions ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Closes #183
2021-03-12 15:28:01 +11:00
docker_process_sql --database=mysql --binary-mode <<-EOSQL_USER
SET @@SESSION.SQL_MODE=REPLACE(@@SESSION.SQL_MODE, 'NO_BACKSLASH_ESCAPES', '');
CREATE USER '$MARIADB_USER'@'%' IDENTIFIED BY '$userPasswordEscaped';
EOSQL_USER
if [ -n "$MARIADB_DATABASE" ]; then
mysql_note "Giving user ${MARIADB_USER} access to schema ${MARIADB_DATABASE}"
docker_process_sql --database=mysql <<<"GRANT ALL ON \`${MARIADB_DATABASE//_/\\_}\`.* TO '$MARIADB_USER'@'%' ;"
fi
fi
}
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
# backup the mysql database
docker_mariadb_backup_system()
{
if [ -n "$MARIADB_DISABLE_UPGRADE_BACKUP" ] \
&& [ "$MARIADB_DISABLE_UPGRADE_BACKUP" = 1 ]; then
mysql_note "MariaDB upgrade backup disabled due to \$MARIADB_DISABLE_UPGRADE_BACKUP=1 setting"
return
fi
local backup_db="system_mysql_backup_unknown_version.sql.zst"
local oldfullversion="unknown_version"
if [ -r "$DATADIR"/mysql_upgrade_info ]; then
read -r -d '' oldfullversion < "$DATADIR"/mysql_upgrade_info || true
if [ -n "$oldfullversion" ]; then
backup_db="system_mysql_backup_${oldfullversion}.sql.zst"
fi
fi
mysql_note "Backing up system database to $backup_db"
if ! mysqldump --skip-lock-tables --replace --databases mysql --socket="${SOCKET}" | zstd > "${DATADIR}/${backup_db}"; then
mysql_error "Unable backup system database for upgrade from $oldfullversion."
fi
mysql_note "Backing up complete"
}
# perform mariadb-upgrade
# backup the mysql database if this is a major upgrade
docker_mariadb_upgrade() {
if [ -z "$MARIADB_AUTO_UPGRADE" ] \
|| [ "$MARIADB_AUTO_UPGRADE" = 0 ]; then
mysql_note "MariaDB upgrade (mysql_upgrade) required, but skipped due to \$MARIADB_AUTO_UPGRADE setting"
return
fi
mysql_note "Starting temporary server"
docker_temp_server_start "$@" --skip-grant-tables \
--loose-innodb_buffer_pool_dump_at_shutdown=0 \
--skip-slave-start
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
mysql_note "Temporary server started."
docker_mariadb_backup_system
mysql_note "Starting mariadb-upgrade"
mysql_upgrade --upgrade-system-tables
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
mysql_note "Finished mariadb-upgrade"
# docker_temp_server_stop needs authentication since
# upgrade ended in FLUSH PRIVILEGES
mysql_note "Stopping temporary server"
kill "$MARIADB_PID"
wait "$MARIADB_PID"
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
mysql_note "Temporary server stopped"
}
_check_if_upgrade_is_needed() {
if [ ! -f "$DATADIR"/mysql_upgrade_info ]; then
mysql_note "MariaDB upgrade information missing, assuming required"
return 0
fi
local mariadbVersion
mariadbVersion="$(_mariadb_version)"
IFS='.-' read -ra newversion <<<"$mariadbVersion"
IFS='.-' read -ra oldversion < "$DATADIR"/mysql_upgrade_info || true
if [[ ${#newversion[@]} -lt 2 ]] || [[ ${#oldversion[@]} -lt 2 ]] \
|| [[ ${oldversion[0]} -lt ${newversion[0]} ]] \
|| [[ ${oldversion[0]} -eq ${newversion[0]} && ${oldversion[1]} -lt ${newversion[1]} ]]; then
return 0
fi
mysql_note "MariaDB upgrade not required"
return 1
}
# check arguments for an option that would cause mysqld to stop
# return true if there is one
_mysql_want_help() {
local arg
for arg; do
case "$arg" in
-'?'|--help|--print-defaults|-V|--version)
return 0
;;
esac
done
return 1
}
_main() {
# if command starts with an option, prepend mysqld
if [ "${1:0:1}" = '-' ]; then
set -- mysqld "$@"
fi
#ENDOFSUBSTITIONS
# skip setup if they aren't running mysqld or want an option that stops mysqld
if [ "$1" = 'mariadbd' ] || [ "$1" = 'mysqld' ] && ! _mysql_want_help "$@"; then
2021-03-16 13:15:36 +11:00
mysql_note "Entrypoint script for MariaDB Server ${MARIADB_VERSION} started."
mysql_check_config "$@"
# Load various environment variables
docker_setup_env "$@"
docker_create_db_directories
# If container is started as root user, restart as dedicated mysql user
if [ "$(id -u)" = "0" ]; then
mysql_note "Switching to dedicated user 'mysql'"
exec gosu mysql "${BASH_SOURCE[0]}" "$@"
fi
# there's no database, so it needs to be initialized
if [ -z "$DATABASE_ALREADY_EXISTS" ]; then
docker_verify_minimum_env
2020-02-28 16:14:54 -08:00
# check dir permissions to reduce likelihood of half-initialized database
ls /docker-entrypoint-initdb.d/ > /dev/null
docker_init_database_dir "$@"
mysql_note "Starting temporary server"
docker_temp_server_start "$@"
mysql_note "Temporary server started."
docker_setup_db
docker_process_init_files /docker-entrypoint-initdb.d/*
mysql_note "Stopping temporary server"
docker_temp_server_stop
mysql_note "Temporary server stopped"
echo
2021-03-16 13:15:36 +11:00
mysql_note "MariaDB init process done. Ready for start up."
echo
MDEV-25670 Run mysql_upgrade / mariadb-upgrade at startup As this is quite an extensive change MARIADB_AUTO_UPGRADE=1 is required to opt into the auto upgrade. If may eventually change if this proves stable and based on user feedback and might change to on by default. Per the mysql_upgrade documentation (https://mariadb.com/kb/en/mysql_upgrade/) we take a backup and leave this in the datadir. This backup can be disabled with MARIADB_DISABLE_UPGRADE_BACKUP=1. The upgrade process requires the entrypoint to start the server before being available to the use users (for reasons below). The upgrade will only upgrade-system-tables as highighted in #350, a large set of user database can slow the update process by hours. From feedback in (https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=208660&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-208660) it appears this will rarely if ever be required. Because the root password may not be known to the entrypoint (random or removed users), the temporary server is started in --skip-grant-tables manner to avoid this contraint. Background information: MDEV-27068 showed the dangers of running two mysql_upgrades in parallel. MDEV-14622 and MDEV-27107 showed two deadlock cases with myql_upgrade and the spider engine, and its still unknown if create/drop procedure or create (udf) function will conflict if started from a user connection instead of a plugin. As there are a few other user features that depend on a stable set of system tables, a pre-start upgrade is performed. Some small hacks of ensuring the mysql_upgrade_info file is populated is done in anticipation of upstream features being implementing including: With MDEV-27279, mariadb_upgrade added --check-if-upgrade-is-needed we can test if an upgrade is needed. Unfortunately its not offline yet (MDEV-27636) and requires the start of the server. As such for now we do our own version checks based on mysql_upgrade_info. MDEV-27607: mysql_install_db to install mysql_upgrade_info should facilitate the avoiding of upgrades been needed on the first installed. _mariadb_fake_upgrade_info function is anticipated to be removed and likewise for the || true on mysql_upgrade. The debian/ubuntu packaging component, MDEV-27068 I hope is going to leave a set of config parameters for safe upgrades requiring a small patch like: --- a/docker-entrypoint.sh +++ b/docker-entrypoint.sh @@ -424,6 +424,10 @@ docker_mariadb_upgrade() { return 0 fi mysql_note "Starting temporary server" + local mariadbd="$1" + shift + docker_temp_server_start "$mariadbd" --defaults-extra-file=/etc/mysql/upgrade.cnf "$@" + set -- "$mariadbd" "$@" docker_temp_server_start "$@" mysql_note "Temporary server started." Closes #350
2021-11-19 17:31:42 +11:00
# MDEV-27636 mariadb_upgrade --check-if-upgrade-is-needed cannot be run offline
#elif mysql_upgrade --check-if-upgrade-is-needed; then
elif _check_if_upgrade_is_needed; then
docker_mariadb_upgrade "$@"
fi
fi
exec "$@"
}
# If we are sourced from elsewhere, don't perform any further actions
if ! _is_sourced; then
_main "$@"
fi