Removal of master-slave language

[bopopescu]

For diversity reasons, it would be nice to try to avoid 'master' and 'slave' terminology in this repository which can be associated to slavery. The master-slave terminology could be problematic for people in several countries which has the history of slavery like Romania, USA and many others. Thank you for considering the proposal. Let me know if any changes in the PR are needed, I would be happy to implement them.

[shlomi-noach]

Hi @bopopescu, thank you for the discussion and for this pull request. See some recent pull requests on the same topic: #1168, #1182, #1187, #1188, and search for some major overhaul in slave->replica terminology made when I imported this repo into the github.com/github org (it has recently moved out of that org).

At this time, and to the best of my awareness, there is no use of slave terminology in:

• public API requests
• public API responses
• CLI commands
• Web interface
• Documentaiton

I believe they have all been eradicated. slave terminology has been almost eradicated from internal code, as well, with the exception of:

• slave -named MySQL commands which at this time have no alternative (e.g. show slave status)
• slave -named MySQL variables which at this time have no alternative (e.g. slave_net_timeout)
• Configuration, API & CLI commands perserved for backwards compatibility. As example, orchestrator -c relocate-slaves still exists so as not to break existing deployments; however orchestrator -c relocate-replicas replaces that and is encouraged (the documentation does not mention slave terminology anymore). As example, the Instance object exports SlaveHosts, but then also exports Replicas, which is advocated. As example, SlaveLagQuery in the configuration is deprecated in favor of ReplicaitonLagQuery (e.g. see here).
• Internal database column names.

Since orchestrator is a public solution, and since it's essence is to keep MySQL high availability in production, and since it happens to be deployed at some known and many more unknown locations, it is impossible to just change database column names in the code and ship as a new release without this breaking production at many places. Similarly, if we just change the public API, many scripts, tests and automation will just break. It is therefore necessary, in my opinion, to take the longer path of a gradual change, over a long period of time, where we first silently demote the use of old terminology and encourage the use of a replacement terminology, then, at some point in a future release, introduce Warnings when old terminology is been used. Then, at some point after that, introduce actual errors and remove old terminology. This unfortunately cannot happen overnight and is unfortunately not a matter of simple search&replace. Do note that I've taken the decision to break some APIs in favor of change in the terminology, in places where I predict will not cause outage to users.

BTW the common term used by the MySQL community to replace slave is replica, not subordinate.

Regarding master terminology: we as the MySQL community (speaking as a member of the community) are keen to settle on a replacement terminology. In my opinion, given the large open source ecosystem around MySQL, it is essential that all tools use same terminology. It was only recently that Oracle published their intention of changing the terminology in MySQL itself: https://mysqlhighavailability.com/mysql-terminology-updates/. These are great news, since we will not have to use terminology such as show slave status anymore. It is yet to be determined how we will name a master. That post suggests source (as opposed to main in your PR), but there's more to that; we'd need to settle on terminology to be used by the client, to be used for an "intermediate-master", to be used by a replica, to be used in multi-master etc. Our Oracle friends promise to publish more information in the near future, and I expect to have followup discussions within the community.

As this is relatively recent, I prefer to first await decision on the formal changes to terminology in MySQL. orchestrator will benefit from matching that terminology.

Once we do settle on new terminology, we will need to go through similar phases of migration. Again, I can't just accept the changes in this PR, because they will break each and every installment of orchestrator out there. So I'm keen to make a steady progress towards new terminology, but one that does not require instant downtime for the many users of this technology. We will go through introducing of new API calls, new CLI command,s new configuraiton variables; we'll validate that no two contradicting variables are used as both old & new terminology, we will update documentation to use the new terminology, update tests, update internal code to remove old terminology where possible, then hopefully be able to issue warnings upon usage of old terminology, and last, at some point in the future, remove the old terminology.

Thank you kindly for this pull request, I hope the above explains why I cannot merge it as-is, and how this project works to change the terminology in an iterative manner.

[shlomi-noach]

I feel like this PR is machine generated and without context to the operation of orchestrator nor mysql. show subordinate status is not a valid command. Subordinate_IO_Running is not a value returned by this query. log_subordinate_updates is not an actual MySQL variable. etc.

[goldstar611]

lol, the o.p. has about 4000 repos, most of which are forks and almost all have a branch named bucharest with a single commit related to adjusting of master/slave terminology. This dude is trolling because his script is obviously not taking any consideration of code/context.

Basically, masterpiece becomes mainpiece and slavering (drooling from mouth) become subordinatering

In bopopescu/zhuangzhuang131419.github.io@e9d270c mastercard becomes oligarchcard lol so his script at least has some I18N bits in it.

lmfao, mastercard/maincard && webmaster/webmain: bopopescu/Cloud-User-Management@d8985f5#diff-8f80a2645e1615f9cfb7638de6a110d9164f09219fd9fafa83a2d1ca2a43c3e9