Details
-
Epic
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
Rename or alias slave-related statements, options, status variables
Description
A US-based user has asked me whether we can rename or alias slave-related statements, options, status variables. I believe that discussions involving slaves can be uncomfortable for some people due to the history of slavery in the U.S.
Aliasing can be implemented, as well as new optional command/option names. For example SHOW REPLICA STATUS as alternative to SHOW MASTER STATUS.
Existing names and output must be preserved if they can be in use by existing user application and scripts, to preserve backwards compatibility.
Newly added options and commands still need to have a variant following the main traditional terminology for consistency (eg. Master_* options for CHANGE MASTER). New optional commands could change the output naming (eg. output of SHOW REPLICA STATUS) as this does not break backwards compatibility.
Internal (non-user-facing naming) must not be changed to avoid unnecessary source code changes that complicate merges and reading commit history).
I have no idea how prevalent this feeling is, but I do know that several other software teams have done similar changes recently. For example:
https://www.theregister.co.uk/2018/09/11/python_purges_master_and_slave_in_political_pogrom/
https://www.theregister.co.uk/2018/09/13/redis_master_slave/
https://github.com/antirez/redis/issues/5335
https://github.com/kubernetes/website/issues/6525
https://www.drupal.org/node/2275877 - replica
If we did want to do this, then some potential replacements are:
- replica
- clone
- replicator
- standby
- secondary
- follower
Attachments
Issue Links
- includes
-
MDEV-20601 Make REPLICA a synonym for SLAVE in SQL statements
-
- Closed
-
-
-
- Open
-
-
-
- Open
-
-
-
- Open
-
- is blocked by
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
MDEV-24362 Privilege aliases are missing from SHOW PRIVILEGES
-
- Open
-
- links to
Activity
We should not make any changes to mysql.gtid_slave_pos. This is a critical table
I hate to see what the world is coming to.
Imagine your car has "Help Ukraine" on its dash. Imagine your tool box comes with a big rainbow flag on it. This is exactly that.
PLEASE, DO NOT compromise the quality and security of your product for a political nonsense.
For those who came here feeling the same way, if you're in position to resist this current political pressure, please do.
It seems this issue should be closed.
There are aliases for most syntax and if any additional feature requests for aliases they can be filed as separate issues.
There will not be deprecation of old syntax or non-backwards-compatible changes to server outputs.
The request to rename, if it will ever become actual, might be addressed with a new pre-parser plugin, perhaps solely for the Enterprise edition.
The issue still has many unaddressed child issues, so shouldn't yet be closed.
We should not make any changes to mysql.gtid_slave_pos. This is a critical table, and it's already complex to handle it correctly for all possible upgrade scenarios etc.
By extension, no non-user-facing names should be changed or aliases added. For example, needlessly changing server source code names will complicate merging and git history tracking.
New names should be introduced by adding aliases. No existing names can be deprecated or removed, as that would create needless work for a huge number of users.
My understanding is that this is being done to satisfy the wishes from users who dislike the word "slave" (how many users?). It's important to be respectful to all users, including those that have no dislike for one letter combination over another, but do have a dislike for extra technical complications and problems in their work.
Please Cc: all patches regarding this to me (knielsen@knielsen-hq.org) so I can review them wrt. this.
- Kristian.