Details
-
Bug
-
Status: Open (View Workflow)
-
Trivial
-
Resolution: Unresolved
-
12.0
-
None
-
None
Description
At present it's possible to have Master_Retry_Count < Connects_Tried which shouldn't happen.
Last_IO_Errno: 2003
|
Last_IO_Error: error reconnecting to master 'repl_user@127.0.0.1:12622' - retry-time: 10 maximum-retries: 10 message: Can't connect to server on '127.0.0.1' (111 "Connection refused")
|
Last_SQL_Errno: 0
|
Last_SQL_Error:
|
Replicate_Ignore_Server_Ids:
|
Master_Server_Id: 1
|
Master_SSL_Crl:
|
Master_SSL_Crlpath:
|
Using_Gtid: Slave_Pos
|
Gtid_IO_Pos: 0-1-3
|
Replicate_Do_Domain_Ids:
|
Replicate_Ignore_Domain_Ids:
|
Parallel_Mode: optimistic
|
SQL_Delay: 0
|
SQL_Remaining_Delay: NULL
|
Slave_SQL_Running_State:
|
Slave_DDL_Groups: 1
|
Slave_Non_Transactional_Groups: 2
|
Slave_Transactional_Groups: 0
|
Replicate_Rewrite_DB:
|
Connects_Tried: 3
|
Master_Retry_Count: 1
|
Repro
STOP SLAVE;
|
CHANGE MASTER TO Master_Connect_Retry = 10
|
CHANGE MASTER TO Master_Retry_Count = 10;
|
stop master for 100 sec.
|
START SLAVE;
|
SHOW SLAVE STATUS\G -- until it shows Connects_Tried > 1
|
STOP SLAVE;
|
CHANGE MASTER TO Master_Retry_Count = 1;
|
SHOW SLAVE STATUS\G -- it'll show Connects_Tried > 1 and Master_Retry_Count = 1
|
Expected behavior
Master_Retry_Count should never be less than Connects_Tried. Perhaps like START SLAVE, STOP SLAVE should also reset Connects_Tried to 1.
Attachments
Issue Links
- is caused by
-
MDEV-35304 More Details for Ongoing IO Thread Re-connection Attempts
-
- In Testing
-
I intended this, so an admin can still check Connects_Tried after STOP REPLICA (so they doesn’t have to leave the attempt loop spinning).
Note that after STOP REPLICA, START REPLICA will reset it to 1 anyway.
Though it’s a decent question for what to do when setting Master_Retry_Count to < Connects_Tried.
The connections counter has always been there internally, only it was never exposed before MDEV-35304.