There is an implicit --connect option in healthcheck
so that a normal use can be sure MariaDB is running
on a tcp socket.
There is a case in /docker-entrypoint-initdb.d where
its desirable to perform healthchecks for components
without a --connect. In this case, use --no-connect
in the healthcheck to avoid an implicit --connect test.
START REPLIA was issued during initializing which mean that
even before /docker-entrypoint/initdb.d there was initializtion
going on.
Entrypoints that needed data initialzation didn't complete with
this nicely. Also if there wasn't any initialization there
would be little time for the replication to acheive anything
before being shutdown ready for the final start.
Moved --skip-slave-start to the default docker_temp_server_start
implementation.
Technically this is a compaibility break that is likely to be
of significants if:
* /docker-entrypoint/initdb.d contains a script waiting
for replication to catch up.
The recitifcation to the previous behaviour is:
/docker-entrypoint/initdb.d contains a SQL to START REPLICA.
Recommend also having another script that is:
until healthcheck.sh --replication_io \
--replication_sql \
--replication_seconds_behind_master=0 \
--replication
--no-connect;
do
sleep 1
done
Closes#614
Based on user reports, a `connect` test can observer a non-"Can't
connect" error message.
Because this passes other tests, like innodb_initialized might
succeeded.
The final test -z "$connect_s" is also true, leaving the user
with an incorrect test result.
Maybe the healthcheck cnf hasn't been created yet?
Either way, ruggardise the final test to ensure a healthy connect
test occured.
Narrow down the scope of healthcheck --connect failures
to the mariadb client errors "Can't connect".
May as well look at same @skip-networking system variable
on TCP just in case.
28000 errors, per
https://mariadb.com/kb/en/mariadb-error-code-reference/ are client
errors after a connection, indicating that the start of a tcp
connection occured.
Closes#610
require-secure-transport on the server mandates that tls or
unix socket be used. The healthcheck user doesn't have explict
tls credentials, so would have failed. 11.4+ would have
tls negiotated, except in #594 it was disabled for people that
didn't configure ssl-ca correctly.
To resolve this _process_sql adds an explict --protocol socket
to get around the default configuration of 'protocol=tcp' in
.my-healthcheck.sh. The protocol=tcp was there to catch people
who put `healthcheck.sh --innodb_initialized` to discover it
checked that in the starting phase of the container, without
a tcp connection being available, it still returned true.
We work around this my making a connection test always
occur in the healthcheck.
Remove the protocol=tcp from the generation of .my-healthcheck.cnf
files.
--connect, as a method that requires to test the connection,
we add a mechanims that examines @@skip_networking and considers
that if false, the connection is viable. We made a unix socket
connection to do the test, which is active the same time as tcp
sockets are.
This alternate --connect method would have only worked the
credentials of the healthcheck user where valid. If it isn't
fall back to looking for "Can't connect".
Closes: #596
There may be cases where specific files are readonly,
like .my-healthcheck.cnf due to filesystem mounts.
So lets make the ownership/permission changes optional.
Closes: #573
Correct healthcheck.sh comments.
Few minor errors in later versions corrected.
11.6 upgrade file corrected.
More resiliant to version changes.
Remove mysql/mariadb safe.cnf file that isn't distributed
from Dockerfile.
This only has an effect on the 11.3 and 11.4 that have the configuration
item set in their configuration file.
The 10.4 instance doesn't have this file.
Factor our create_healthcheck_users.
Make sure that when recreating users, if they already exist, we just password
reset these and ensure the .my-healtcheck.cnf file is there for usage. We don't
want to clobber any existing grants if we happen not to have MARIADB_HEALTHCHECK_GRANTS
set.
Because creating users needs to move past --skip-grant-tables with FLUSH PRIVEGES,
and mariadb-upgrade also issue FLUSH PRIVILEGES, then unfortunately is yet another
restart.
Adjust test case to ensure there is no .cnf file, and create it on
restore.
This way the sql commands are compatible with all sql_modes
When using sql_mode ANSI_QUOTES the healtcheck failed with a query error because in this mode double qutes are interpreted as identifier quote
Resolves#538
As the backup may be from a different configuration requiring
specific parameters, we make the mysql user have a homedir of
/var/lib/mysql and place the backup my.cnf there.
Thanks Faustin for review and Martin for testing.
While 777 is needed to be writable by multiple users, a sticky
bit will prevent manipulation by other users. Add this to the
permissions of the /run/mysqld directory.
Also correct, in config and filesystem /run/mysqld is used
in every case above 10.4. /var/run is a symlink to /run in the base
OS.
Thanks @ollie1
Closes: #532
This is so someone that wants debug info packages just
needs to apt-get install mariadb-server-core{-10.X}-dbgsym to
get the right packages after and apt-get update.
The 50-mariadb_safe.cnf file exposed a syslog configuration
that got picked up by Galera SST scripts. These would push
output to /dev/log which doesn't exist in containers.
healthcheck@{127.0.0.1,::1,localhost} users are granted USAGE by default, which
is enough for the non-replication healthchecks in healtcheck.sh.
The env variable MARIADB_HEALTHCHECK_GRANTS can replace USAGE with any
comma separated set of grants.
On initialization a generated password is created and saved in
$DATADIR/.my-healthcheck.cnf along with the server port and socket. If the
command args or default configuration file changes this may become out
of date. Because the password is generated in configuration file the
'#', comment, and '=' characters cannot be part of this password.
The healthcheck.cnf configuration file also sets protocol=tcp to
enforce indirectly that --connect being a standard part of the test. This is
required as starts of the service under --skip-networking should
never be considered healthy.
The healthcheck script also has the --defaults-extra-file set to this
.my-healthcheck.cnf file, if it exists (backwards compatible on
previously created datadirs), so that all new healthcheck invokations
use the authentication here by default.
The compatibility with old instances, without the .my-healthcheck.cnf is
preserved by non setting --defaults-extra-file.
The healthcheck --connect will increment the server status variable Aborted_connects
for each check, however now connection_error* counts are changed.
This also prevents any invalid password errors showing up in the
container log.
Closes#430
These are controled by:
* MARIADB_MASTER_HOST - if specified, the master, and the container is a replica
* MARIADB_REPLICATION_PORT - port number
* MARIADB_REPLICATION_USER - create or use this user
* MARIADB_REPLICATION_PASSWORD - create or use this password
* MARIADB_REPLICATION_PASSWORD_HASH (on master only)
If MARIADB_MASTER_HOST isn't specified, the container is a master. In
this case, the MARIADB_REPLICATION_USER is created, with password{,hash},
and given the REPLICATION REPLICA grant, or REPLICATION SLAVE (for
10.3, 10.4).
If the MARIADB_MASTER_HOST is specified, CHANGE MASTER TO is used to
connect to the MARIADB_MASTER_HOST:MARIADB_MASTER_PORT(default 3306)
using the MARIADB_REPLICATION_USER. As the password is needed
MARIADB_REPLICATION_PASSWORD_HASH cannot be used on a replica.
CHANGE MASTER TO is executed with MASTER_CONNECT_RETRY=10 and the
replica is started by default.
The creation of the replication user is replicated along with the
master's /docker-entrypoint-initdb.d/ contents and MARIADB_DATABASE
/MARIADB_USER. The MARIADB_MYSQL_LOCALHOST_USER isn't replicated and
neither is the timezone data.
Signed-off-by: MdSahil-oss <Mohdssahil1@gmail.com>
Reviewed-by: Daniel Black <daniel@mariadb.org>
