MDEV-15327 Reset Master_Server_Id to 0 on CHANGE MASTER#4666
MDEV-15327 Reset Master_Server_Id to 0 on CHANGE MASTER#4666varundeepsaini wants to merge 1 commit intoMariaDB:mainfrom
Conversation
varundeepsaini
force-pushed
the
MDEV-15327-master-server-id-fix
branch
from
32a74f7 to
9c49da8
Compare
gkodinov
added
the
External Contribution
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution!
This is a preliminary review.
Please merge your changes into a single commit and have a commit message in it that follow CODING_STANDARDS.md.
I also have some cleanup suggestions below.
varundeepsaini
force-pushed
the
MDEV-15327-master-server-id-fix
branch
from
9c49da8 to
d88902b
Compare
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you! Looks much better now. Please wait for the final review.
Master_Server_Id was not cleared after CHANGE MASTER or RESET SLAVE, showing a stale value until the slave reconnected. Reset master_id and prev_master_id to 0 in both code paths.
varundeepsaini
force-pushed
the
MDEV-15327-master-server-id-fix
branch
from
d88902b to
3b70619
Compare
andrelkin
left a comment
andrelkin
left a comment
There was a problem hiding this comment.
Howdy Varun!
The patch is quite good and must be safe to my checking.
I have a couple of notes to the test part.
Also in the commit message please explain more after
Reset master_id...
that
the reset value will be present in Show-Slave-Status until it is re-evaluated to
the id of a new connected master server.
Cheers!
Andrei
|
|
||
| --replace_result $SERVER_MYPORT_1 MYPORT_1 $read_master_log_pos <read_master_log_pos> $relay_log_pos <relay_log_pos> $relay_log_space <relay_log_space> | ||
| show slave 'master1' status; | ||
| --query_vertical show slave 'master1' status |
There was a problem hiding this comment.
As this block is driven by the fixes introduce it with #-comment:s
explaining what to expect from Master_Server_id:s.
There was a problem hiding this comment.
I think we can comfortably settle the following tests at the end of an existing suite/rpl/t/rpl_change_master.test.
With one less test file naturally that optimizes mtr runs.
3 participants
Description
Reset
Master_Server_Idto 0 onCHANGE MASTER TOandRESET SLAVE. Previously the stale value from the previous master persisted inSHOW SLAVE STATUSuntil the slave reconnected.Release Notes
CHANGE MASTER TOandRESET SLAVEnow resetMaster_Server_Idto 0, soSHOW SLAVE STATUSno longer reports a stale server ID from the previous master.How can this PR be tested?
Basing the PR against the correct MariaDB version
mainbranch.PR quality check