MDEV-20122: Remove Master_info::is_demotion#5115
Conversation
MDEV-20122 introduced this field, but it was never actually used. `CHANGE MASTER TO master_demote_to_slave=…` only uses the parser field `LEX_MASTER_INFO::is_demotion_opt` and is not recorded in either `@@master_info_file` or `@@relay_log_info_file`, as it takes effect during CHANGE MASTER rather than during replication.
There was a problem hiding this comment.
Code Review
This pull request relocates the demotion flag from the Master_info class to the LEX_MASTER_INFO struct. Feedback was provided to improve the accuracy of the documentation by using 'server' instead of 'connection' and to align the comment style with existing codebase conventions regarding capitalization and formatting.
| When `true`, transition this connection from an active master to a slave. | ||
| This updates the replication state to account for any transactions which | ||
| were committed into the binary log. In particular, it merges | ||
| `gtid_binlog_pos` into `gtid_slave_pos`. |
There was a problem hiding this comment.
The term "connection" is slightly inaccurate in this context. While the demotion is initiated through a specific replication connection (channel), the operation transitions the server's role and affects the global GTID state. The original wording "transition this server" is more precise. Additionally, using standard capitalization for TRUE and avoiding backticks in the comment text maintains better consistency with the existing codebase style.
When TRUE, transition this server from being an active master to a slave.
This updates the replication state to account for any transactions which
were committed into the binary log. In particular, it merges
gtid_binlog_pos into gtid_slave_pos.References
- Use standard capitalization for TRUE and avoid backticks in comments for consistency with the codebase style. (link)
MDEV-20122 introduced this field, but it was never actually used.
CHANGE MASTER TO master_demote_to_slave=…only uses the parser fieldLEX_MASTER_INFO::is_demotion_optand is not recorded in either@@master_info_fileor@@relay_log_info_file, as it takes effect during CHANGE MASTER rather than during replication.