By way of comparison, both MongoDB and IBM Informix use primary/secondary nomenclature. Sybase uses primary/replicate. Obstacle Oracle uses master/snapshot, so only half way there. Microsoft SQL Server uses a complex publisher/distributor/subscriber nomenclature that I'd recommend avoiding.

MDEV-18777: Rename or alias slave-related statements, options, status variables

Please find the list of commands/options/variables, which make use of the word
'Slave'. These are input and output commands which are exposed to users. This
document also explains the impact of renaming 'Slave' to 'Replica'. It also lists
various tools which will be affected.

Commands used on Master:
========================
1) REPLICATION SLAVE PRIVILEGE:

Before the new slave can begin replicating from the master, we need to create a
user account on the master that the slave can use to connect, and we need to
grant the user account the REPLICATION SLAVE privilege. For example:

CREATE USER 'repl'@'dbserver2' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON . TO 'repl'@'dbserver2';

The above grant privilege needs to be changed.

"mysql.user" table has the following field which stores 'REPLICATION SLAVE'
privilege. The column needs to be renamed accordingly.

---------------------------------------------------------------+

---------------------------------------------------------------+
Repl_slave_priv | varchar(1) | YES | | NULL

"Upgrade script" will have to be modified to accommodate above change.

2) SHOW SLAVE HOSTS:

This command is run on the master and displays a list of replication slaves that
are currently registered with it.

Commands used on Slave:
=======================
1) Replication admin commands:

START SLAVE, START SLAVE UNTIL,START ALL SLAVES: Start replication threads
START SLAVE SQL_THREAD, START SLAVE IO_THREAD: Start specific replication thread.
STOP SLAVE,STOP ALL SLAVES: Stop replication threads
RESET SLAVE,RESET SLAVE ALL: Forget slave connection information and start a
new relay log file.
SET GLOBAL SQL_SLAVE_SKIP_COUNTER: Skips a number of events from the master.
SHOW RELAYLOG EVENTS: Show events in the relay log
SHOW SLAVE STATUS, SHOW ALL SLAVES STATUS: Show status for one or all masters.

All the above commands are extensively used by monitoring tools, which check
the health status of replication threads and perform failover and switchover.
Renaming these commands will impact all the monitoring tools.

Tools:
======
1) MaxScale:
Uses most of the above command internally. MaxScale also has following
configuration parameters which make use of the term 'slave'. They also must
be renamed.

1.1) MAX SCALE configuration parameters:
max_slave_connections
max_slave_replication_lag

1.2) MaxScale Readconnroute:
The readconnroute router provides simple and lightweight load balancing across a
set of servers. 'router_options' can contain a list of valid server roles. These
roles are used as the valid types of servers the router will form connections to
when new sessions are created.

router=readconnroute
router_options=master,slave

The above 'slave' role needs to be renamed appropriately.

1.3) Mariadbmon:
Uses all admin commands extensively and has following options which use
'slave' term.

enforce_read_only_slaves
detect_stale_slave

2) mariabackup:

2.1) slave-info: Prints the binary log position and the name of the master
server. This option also causes Mariabackup to record this information as a
CHANGE MASTER command that can be used to set up a new server as a slave of
the original server's master after the backup has been restored. This
information will be written to to the xtrabackup_slave_info file.

2.2) safe-slave-backup: Stops slave SQL threads for backups.
When running Mariabackup using this option, it stops slave SQL threads and
waits until the Slave_open_temp_tables in the SHOW STATUS statement is zero.
If there are no open temporary tables, the backup runs, otherwise the SQL
thread starts and stops until there are no open temporary tables.

2.3) safe-slave-backup-timeout=#: Defines the timeout for slave backups.

All the above commands need to be renamed.

All applications and scripts which make use of above commands have to be
rewritten.

3) Galera cluster replication uses following system variables:

wsrep_restart_slave
wsrep_slave_UK_checks
wsrep_slave_threads
wsrep_slave_FK_checks

The above variables will have to be renamed.

Replication System variables:
=============================
gtid_slave_pos:The "mysql.gtid_slave_pos" table is used in replication by slave
servers to keep track of their current position (the global transaction ID of
the last transaction applied). Using the table allows the slave to maintain a
consistent value for the gtid_slave_pos system variable across server rest arts.
Renaming this table has to be handled as part of 'upgrade' process.

init_slave
log_slow_slave_statements
log_slave_updates
slave_compressed_protocol
slave_ddl_exec_mode
slave_domain_parallel_threads
slave_exec_mode
slave_load_tmpdir
slave_max_allowed_packet
slave_net_timeout
slave_parallel_max_queued
slave_parallel_mode
slave_parallel_threads
slave_parallel_workers
slave_run_triggers_for_rbr
slave_skip_errors
slave_sql_verify_checksum
slave_transaction_retries
slave_transaction_retry_errors
slave_transaction_retry_interval
slave_type_conversions
sql_log_bin
sql_slave_skip_counter
sync_binlog
sync_master_info
sync_relay_log
sync_relay_log_info

Replication command line options:
================================
abort-slave-event-count
init-slave
log-slave-updates
slave-ddl-exec-mode
slave-compressed-protocol
slave-domain-parallel-threads
slave-exec-mode
slave-load-tmpdir
slave-max-allowed-packet
slave-net-timeout
slave-parallel-threads
slave-parallel-max-queued
slave-run-triggers-for-rbr
slave-skip-errors
slave-sql-verify-checksum
slave-transaction-retries
slave-transaction-retry-errors
slave-transaction-retry-interval
slave-type-conversions

Semisynchronous Replication Options and System Variables:
========================================================
rpl-semi-sync-master-wait-no-slave
rpl-semi-sync-slave-delay-master
rpl-semi-sync-slave-kill-conn-timeout
rpl-semi-sync-slave-enabled
rpl-semi-sync-slave-trace-level

Please note that this is not the entire list of commands. I gathered them as per
documentation . Hence it may change.

Since 'Slave' word is being used extensively current plan is to introduce a new alias named 'Replica'.

sujatha.sivakumar To renaming I suggest: s/master/primary/ and s/slave/replica/ .

To few uncalled yet objects which are going to be aliased, let's look at `mysql.gtid_slave_pos` table (actually tables,
thanks to --gtid-pos-auto-engines.
We would definitely not like to have two instances of such tables. An new server option to dichotomize the naming choice is even ugly imo. I would consider to rename the tables right away. A standard way to proceed in this case would be first (that would be 10.5) to launch a deprecation "campaign", and later in 10.6 to complete with renaming. We might find few more objects falling to the deprecation-first-scheme.

I wonder how a compromise like this would be rated by ralf.gebhardt@mariadb.com, GeoffMontee, serg as well.

Suggestions provided by: serg

Split the task into following steps.
1. Add aliases in the parser
2. Add aliases to system variables
3. Change column names
4. Change PSI stages
5. gtid_slave_pos table.

Implement one step at a time and publish the results. Based on demand
implement the next and publish. Repeat this for the rest of steps.

Documentation team is working on finding the correct pair of words to use
instead of master/slave. Upon identifying the correct pair of words start
working on this issue.

Any chance this effort could be un-stalled?

Hi Douglas,

Work is in-progress in several ways. First, MariaDB's Enterprise Documentation has shifted to prefer the terms "Primary" and "Replica". As this change did not require code or interface changes, it was a natural place to start.

This was also carried forward in the MariaDB SkySQL DBaaS, our new cloud database offering, and its accompanying documentation.

Work to integrate the change to MariaDB Server began in the MariaDB Server 10.5 series, where aliases have been added for all SQL statements that used the terminology. This work occurred via MDEV-20601 which is linked to this ticket.

Far from stalled, work is continuing, and occurring in an incremental fashion to ensure existing interfaces are not broken while we shift to updated terminology.

Thank you,

Jacob Moorman
Sr. Director of Documentation, MariaDB Corporation

Great - I'm glad to hear - I did see that MDEV-20601 was completed, but was unclear where things stood. Thank you for helping to clarify.

Go to hell with your politically correct speech.
The doublethink is here huh? This is real end of our civilization definitely.
It was just a tech terms.
–
Mareg

This is insane, if both Oracle and MariaDB are going to change these innocent names I'm going to use something else or stop using it all together. Maybe even stop programming all together and become a truck driver or something. Why would you follow this nonsense trend? There's nothing racist about these words at all. Programming world taken over by SJW's very sad.

Just stumbled upon this, is this some kind of joke? Or aprils fools that was getting out of control?
If not, then there is nothing else to say besides: This is madness. Pure madness.

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.