Test multi_source.connects tried would sporadically fail with a result
mismatch resembling the following diff:
@@ -29,6 +29,7 @@
SELECT @time_begin, CURRENT_TIMESTAMP(1)
WHERE TIMESTAMPDIFF(SECOND, @time_begin, CURRENT_TIMESTAMP(1)) < 1;
@time_begin CURRENT_TIMESTAMP(1)
+2025-04-28 17:10:08.3 2025-04-28 17:10:09.2
CREATE TEMPORARY TABLE status_sleep AS SELECT 'named' Connection_name, Connects_Tried Connects_Tried;
SET @@SESSION.default_master_connection= '';
include/wait_for_slave_param.inc [Connects_Tried]
This happened due to the reference variable @time_begin being set
_after_ the slave was started. That is, @time_begin was used as the
anchor point at which the time should start ticking for when
Connects_Tried should be incremented; however, MTR may not actually
be able to set it for some time after the slave had started due to
OS scheduling or heavy server load. The failure can be reproduced by
adding a 0.1s sleep statement in-between the aformentioned statements.
The fix is to set @time_begin before starting the slave so it is at
least always valid to reference as the start of the test case.
CHANGE MASTER can set `Master_Retry_Count` to be lower than
`Connects_Tried`, which’ll look strange to those unaware of that CHANGE.
Now, setting `Master_Retry_Count` also resets `Connects_Tried` to 0.
Reviewed-by: Susil Behera <susil.behera@mariadb.com>
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
Improve the `multi_source.connects_tried` feature test:
* Replace the main course from
*checking `Connect_Tried` after sleeping a specific time* to
*checking the duration after reaching a minimum `Connect_Tried`*
* Not using a specific SLEEP eliminates the possibility (of failure)
that it awakens before the `Connects_Tried` counter increments.
* In replacement-based tests of conventional views (SHOW & variants),
assert the parallel values without distinguishing which is which
* There were rare cases where both values end up equal (even though
one was configured to tick more frequently than the other).
* Comment touchups
Reviewed-by: Kristian Nielsen <knielsen@knielsen-hq.org>
When the IO thread (re)connect to a primary,
no updates are available besides unique errors that cause the failure.
These new `Master_info` numbers supplement SHOW SLAVE STATUS’s (most-
recent) ‘Connecting’ state with statistics on (re)connect attempts:
* `Connects_Tried`: how many retries have been attempted so far
This was previously a local variable that only counted re-attempts;
it’s now meaningful even after the “Connecting” state concludes.
* `Master_Retry_Count` (from MDEV-25674): out of how many configured
Side-note: Some of the tests updated by this commit dump the entire
SHOW SLAVE STATUS, which might include non-deterministic entries.
Reviewed-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Reviewed-by: Brandon Nesterenko <brandon.nesterenko@mariadb.com>
