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
