[MDEV-15327] SlaveStatus Master_Server_Id does not reset with CHANGE MASTER Created: 2018-02-16 Updated: 2018-02-16 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Replication |
| Affects Version/s: | 10.2 |
| Fix Version/s: | 10.2 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Esa Korhonen | Assignee: | Andrei Elkin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Description |
|
The Master_Server_Id show by SHOW ALL SLAVES STATUS keeps its old value after a CHANGE MASTER TO-command. It seems the value is only updated once the slave connects to the new master. This can be confusing if the history of the slave is not known and the IO Thread is "Connecting". In that case it's not immediately obvious if the Master_Server_Id shown is the ID of the current master server (temporarily disconnected) or of a previous master. It would be clearer if a CHANGE MASTER automatically assigned -1 or 0 to Master_Server_Id. |
| Comments |
| Comment by Elena Stepanova [ 2018-02-16 ] |
|
I'd think if it makes any sense at all, then it should be done on STOP SLAVE, not on CHANGE MASTER. By the same logic, as long as there is no connection between master and slave, you can't really rely on the stored value – it could have been changed on the master since then. On the other hand, 99 out of 100 times CHANGE MASTER is executed not to switch to a different master, but to change parameters of the existing one; and even if you are changing host/port, it's quite possibly because those of the same master have changed. However, IIRC, monty has agreed to do it on CHANGE MASTER. |
| Comment by Andrei Elkin [ 2018-02-16 ] |
|
It makes sense that CHANGE-MASTER wipes off the last connected master server_id from its memory. |
| Comment by Esa Korhonen [ 2018-02-16 ] |
|
Wiping it on STOP SLAVE sounds like a good idea as well. Either one should be fine. |