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
