“Ceterum autem censeo "MySQL dominum/servum" appellationem esse delendam”
In our recent Newsletter, Eero Teerikorpi, Founder and CEO, introduced our plans to some significant changes that we are making to adjust the terminology used in our product and in our communications. An excerpt of Eero’s message is below:
As you know, database communities, and the MySQL one in particular, have referred to the databases accepting updates as a ‘master’; and those databases that have received replicated data and are accepting only the read traffic have been called ‘slaves’. Over the years, this master/slave communication has become generally accepted in the MySQL community, even with its clear negative connotation.
But no. No more. There is nothing acceptable about this language and we have decided it is time to make a change. To be honest, I feel that we should have done this much earlier. We will start with our own communication first; and hopefully, maybe others within the MySQL community will choose to follow.
In this blog, I would like to start mapping out the plans for the work we are undertaking and outline the changes we are making.
There is no doubt that the changes are quite significant (but absolutely necessary) undertaking. As much as we would like to flick a switch and the changes to happen overnight, that just isn’t possible. We have identified the following areas where changes need to be made, in order of complexity:
- Online communication: content & visuals
- Historical blog posts/whitepapers/webinars
- Online Documentation
- Internal QA testing process
- Status output from the product
- Internal scripts within the product
- Configuration Parameters within the product
Our plan first is to make all the necessary changes as quickly as possible within all of our online communications and documentation. This isn’t quite as simple as a search/replace activity, but we want to make sure we get it right on the first pass.
Next, we will begin looking at our historical webinars and training videos. We are already in the process of recording new training material for Continuent customers incorporating our new terminology (see below for a full summary) and as each recording is complete we will replace the content in the Customers section of our website. New training material should start appearing for our customers in August with the full set of new videos replaced and available by mid-September 2020. All new webinars will use new terminology going forward and all of the old content will be reviewed and a decision made to either re-record or remove.
The biggest challenge and one that will take much longer are the necessary changes within the product. We have a significant number of configuration properties that use the outdated terminology and all of the status output from the likes of cctrl and trepctl also display the outdated terms. Whilst simply changing the properties in the code may seem like a straightforward process, it has to be done with precision and care. We need to ensure that changes we make do not break the stability of the product and that as and when a customer upgrades, they can do so with ease and with minimal disruption.
Our engineering team is analyzing the effort and work involved and when we have estimated timescales we will be communicating this, in addition, we will ensure our Release Notes include this communication.
It’s possible that these changes may gradually trickle through into the products over a series of patch releases, starting with status outputs and gradually moving towards the more complex property values, but it may also be determined that backward-compatibility isn’t possible which would mean a more significant upgrade path. As soon as we know more we will be sure to communicate this clearly.
Along with our ongoing product enhancements and fixes, this is being taken seriously and is a priority for us, as stated above, we want to get this right on the first pass and therefore we ask for patience and understanding in what is a monumental change.
Terminology Changes
The following Terminology changes will be made (and introduced into the documentation and product as outlined above).
Within the Context of Tungsten Clustering and Tungsten Dashboard
| Old Terminology | New Terminology | Detail |
|---|---|---|
| Master | Primary | When referring to a single, read-write node within a cluster, the new Primary wording will be used. |
| Slave | Replica | When referring to a single, read-only node within one or more clusters, the new Replica wording will be used. |
| Cluster-Slave | Cluster-Extractor | When referring to the process of replicating OUT of one or more clusters to a single, standalone target, the replicator will be referred to as a Cluster-Extract service. |
| Composite Master-Slave (CMS) | Composite Active/Passive (CAP) | Composite refers to a “cluster of clusters” or a “mesh”. The Active cluster will be identified by the cluster accepting read/writes into the Primary Node. The Passive cluster will be identified by Cluster open for reads, and accepting inbound updates from the Active Cluster. |
| Composite Master-Master (CMM) | Composite Active/Active (CAA) | Composite refers to a “cluster of clusters” or a “mesh”. In this topology, all clusters are Active and each Active cluster contains a single Primary node. All clusters accept read/writes from client applications and replicate between all clusters within the Composite service. This topology was introduced in v6 of Tungsten Clustering, as an “upgraded” version of the older MSMM topology. All clusters have awareness of each other and Tungsten Connector is fully cluster-aware of the entire Composite service. |
| Multi-Site/Multi-Master (MSMM) | Multi-Site/Active-Active (MSAA) | This was the first Active/Active style topology introduced in Tungsten Clustering. Whilst it is still a valid and supported topology, customers are advised to use CAA as a more stable and easier to manage solution from version 6 onwards. In this topology each cluster is a standalone cluster containing 1 Primary and a minimum of 2 Replicas. Each cluster accepts reads/writes from client applications and uses a standalone installation of Tungsten Replicator to replicate between clusters. Clusters act independently and have no awareness of each other. |
Within the Context of Standalone Tungsten Replicator
| Old Terminology | New Terminology | Detail |
|---|---|---|
| Master | Extractor | Extractor will be used to identify the Role of the replicator in a standalone replicator topology whereby the replicator is “Extracting” transactions from the Source - The source can be a single node or a Tungsten Cluster. |
| Slave | Applier | Applier will be used to identify the Role of the replicator in a standalone replicator topology. It will pull THL from the Extractor and Apply into the Target environment. The Target can be any of the supported Targets, including a Tungsten Cluster. |
| Master | Source | Source will be used to identify the Node(s) that the Extractor is replicating out of. |
| Slave | Target | Target will be used to identify the Node(s) that the Applier is writing into. |
We will welcome any feedback on these changes, please do comment below if you have any questions.
Comments
Add new comment