Fix incorrect terminology for generating scripts/fill_help_tables.sql

Remove inconsistencies in replication terminology (master/slave
vs. primary/replica), in the files that are needed to generate the
help tables for the server source tree (scripts/fill_help_tables.sql).

Author: knielsen

server/ha-and-performance/optimization-and-tuning/optimizing-tables/optimize-table.md

@@ -33,7 +33,7 @@ This statement requires [SELECT and INSERT privileges](../../../reference/sql-st
 
 By default, `OPTIMIZE TABLE` statements are written to the [binary log](../../../server-management/server-monitoring-logs/binary-log/) and will be [replicated](../../standard-replication/replication-overview.md). The `NO_WRITE_TO_BINLOG` keyword (`LOCAL` is an alias) will ensure the statement is not written to the binary log.
 
-`OPTIMIZE TABLE` statements are not logged to the binary log if [read\_only](../system-variables/server-system-variables.md#read_only) is set. See also [Read-Only Replicas](../../standard-replication/read-only-replicas.md).
+`OPTIMIZE TABLE` statements are not logged to the binary log if [read\_only](../system-variables/server-system-variables.md#read_only) is set. See also [Read-Only Slaves](../../standard-replication/read-only-replicas.md).
 
 `OPTIMIZE TABLE` is also supported for partitioned tables. You can use [ALTER TABLE ... OPTIMIZE PARTITION](../../../reference/sql-statements/data-definition/alter/alter-table/#optimize-partition) to optimize one or more partitions.
 

server/ha-and-performance/standard-replication/gtid.md

@@ -17,7 +17,7 @@ Traditionally, MariaDB treated the [binary log](../../server-management/server-m
 
 InnoDB-based binary logs entirely replace traditional file-based binary logs. When enabled, the server stops writing traditional binlog files, and the new format becomes the only binary log implementation in use.
 
-Additionally, this feature is limited to the binary log on the server. The relay log on replicas continues to use the traditional implementation and is not affected by the use of InnoDB-based binary logs.
+Additionally, this feature is limited to the binary log on the server. The relay log on slaves continues to use the traditional implementation and is not affected by the use of InnoDB-based binary logs.
 
 ## Enabling the InnoDB Binlog
 
@@ -113,18 +113,18 @@ The new binlog implementation requires GTID-based replication. The GTID state is
 innodb-binlog-state-interval=2097152
 ```
 
-The binary log from the last GTID state record is scanned when a replica connects in order to find the determined location.
+The binary log from the last GTID state record is scanned when a slave connects in order to find the determined location.
 The variable innodb-binlog-state-interval can be used to balance the cost of this scan against the extra space needed for the records; however this should have little impact in practice and normally can be left at the default.
 
 For additional configuration options, see [Replication and Binary Log System Variables](replication-and-binary-log-system-variables.md).
 
 #### Replication
 
-Using the new binlog, [replication](./) configuration from the primary can be performed as usual. For that:
+Using the new binlog, [replication](./) configuration from the master can be performed as usual. For that:
 
-* Replicas must use GTID to connect to the primary (this is the default).
-* Replicas should run MariaDB 12.3 or later when replicating from primary.
-* The primary and replica can independently use either the traditional or new binlog format.
+* Slaves must use GTID to connect to the master (this is the default).
+* Slaves should run MariaDB 12.3 or later when replicating from master.
+* The master and slave can independently use either the traditional or new binlog format.
 
 ### Viewing Binlog Events
 
@@ -203,7 +203,7 @@ slave_connections_needed_for_purge=0
 Note that binary log files are only deleted when:
 
 * Limits on time or size are exceeded.
-* Files are not required for crash recovery or by active replicas.
+* Files are not required for crash recovery or by active slaves.
 
 ## Backup using mariadb-backup
 
@@ -215,9 +215,9 @@ Key features:
 
 * Consistent transactional backup for binlog files, similar to other [InnoDB](../../server-usage/storage-engines/innodb/) data.
 * Backups are non-blocking, meaning the server continues running normally. By default, only `RESET MASTER`**,** `PURGE BINARY LOGS`, and `FLUSH BINARY LOGS` are blocked during backup. This blocking can be disabled with the `--no-lock` option.
-* A restored backup can be used to set up a replica for replication.
+* A restored backup can be used to set up a slave for replication.
 
-### Setting Up Replica from Backup
+### Setting Up Slave from Backup
 
 ```bash
 # Default backup includes binlog files
@@ -273,12 +273,12 @@ This is the simplest approach, appropriate for cases where replication or point-
 
 #### Method 2: Replication State Migration (GTID Preservation)
 
-This approach is used to switch a primary server while ensuring that connected replicas can continue replicating without the need for a full reconfiguration.
+This approach is used to switch a master server while ensuring that connected slaves can continue replicating without the need for a full reconfiguration.
 
-1. Stop all writing to the primary.
-2. Wait for all replicas to catch up to the primary's current position.
+1. Stop all writing to the master.
+2. Wait for all slaves to catch up to the master's current position.
 3. Capture the current GTID state by noting down the value of `@@binlog_gtid_state`.
-4. Restart the primary with this configuration:
+4. Restart the master with this configuration:
 
 ```ini
 [mariadb]
@@ -287,17 +287,17 @@ This approach is used to switch a primary server while ensuring that connected r
 ```
 
 5. Immediately execute `SET GLOBAL binlog_gtid_state=<old value>` using the value saved in step 3.
-6. Allow replicas to reconnect; they will continue from where they left off.
+6. Allow slaves to reconnect; they will continue from where they left off.
 
 #### Method 3: Live Migration (Zero downtime)
 
-This is the most robust method for production environments, as it avoids primary downtime during the format transition.
+This is the most robust method for production environments, as it avoids master downtime during the format transition.
 
-1. Ensure that all replicas are upgraded to at least MariaDB version 12.3 before switching the primary.
-2. Choose a replica and restart it with `--binlog-storage-engine=innodb`.
-3. Allow the replica to replicate from the old-format primary until it has enough binlog data.
-4. Promote this replica to be the new primary.
-5. Restart the remaining replicas to point to the new primary after stopping them one at a time and changing their configuration to the new binlog format.
+1. Ensure that all slaves are upgraded to at least MariaDB version 12.3 before switching the master.
+2. Choose a slave and restart it with `--binlog-storage-engine=innodb`.
+3. Allow the slave to replicate from the old-format master until it has enough binlog data.
+4. Promote this slave to be the new master.
+5. Restart the remaining slaves to point to the new master after stopping them one at a time and changing their configuration to the new binlog format.
 
 ## Performance Characteristics
 

server/ha-and-performance/standard-replication/innodb-based-binary-log.md

@@ -251,7 +251,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `binlog_row_event_fragment_threshold`
 
-* Description: When a `Rows_log_event` exceeds this threshold, it is fragmented into multiple `Partial_rows_log_event` events in the binary log, each of it configured to maximum size. That is, all `Partial_rows_log_event` events up to the last in the group have this configured maximum size, and the last event takes the remaining size. This is relevant for events that would surpass the `slave_max_allowed_packet` length when sending to the replica, and thereby a sensible value would reflect the replica's configured `slave_max_allowed_packet` size.
+* Description: When a `Rows_log_event` exceeds this threshold, it is fragmented into multiple `Partial_rows_log_event` events in the binary log, each of it configured to maximum size. That is, all `Partial_rows_log_event` events up to the last in the group have this configured maximum size, and the last event takes the remaining size. This is relevant for events that would surpass the `slave_max_allowed_packet` length when sending to the replica, and thereby a sensible value would reflect the slave's configured `slave_max_allowed_packet` size.
 * Command line: `--binlog-row-event-fragment-threshold`
 * Scope: Global
 * Dynamic: Yes
@@ -382,7 +382,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `init_slave`
 
-* Description: Similar to [init\_connect](../optimization-and-tuning/system-variables/server-system-variables.md#init_connect), but the string contains one or more SQL statements (separated by semicolons) that are executed by a replica server each time the SQL thread starts. These statements are only executed after the acknowledgement is sent to the replica and [START REPLICA](../../reference/sql-statements/administrative-sql-statements/replication-statements/start-replica.md) completes.
+* Description: Similar to [init\_connect](../optimization-and-tuning/system-variables/server-system-variables.md#init_connect), but the string contains one or more SQL statements (separated by semicolons) that are executed by a replica server each time the SQL thread starts. These statements are only executed after the acknowledgement is sent to the replica and [START SLAVE](../../reference/sql-statements/administrative-sql-statements/replication-statements/start-replica.md) completes.
 * Command line: `--init-slave=name`
 * Scope: Global
 * Dynamic: Yes
@@ -483,7 +483,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `master_info_file`
 
-* Description: The location and name of the file that remembers the primary and where the I/O replication thread is in the primary's binlogs. Defaults to primary.info.
+* Description: The location and name of the file that remembers the master and where the I/O replication thread is in the master's binlogs. Defaults to master.info.
 * Command line: `--master-info-file=val`
 * Scope: Global
 * Dynamic: No
@@ -752,15 +752,15 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `report_host`
 
-* Description: The host name or IP address the replica reports to the primary when it registers. If left unset, the replica does not register itself. Reported by [SHOW REPLICA HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md). Note that it is not sufficient for the primary to simply read the IP of the replica from the socket once the replica connects. Due to NAT and other routing issues, that IP may not be valid for connecting to the replica from the primary or other hosts.
+* Description: The host name or IP address the replica reports to the primary when it registers. If left unset, the replica does not register itself. Reported by [SHOW SLAVE HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md). Note that it is not sufficient for the primary to simply read the IP of the replica from the socket once the replica connects. Due to NAT and other routing issues, that IP may not be valid for connecting to the replica from the primary or other hosts.
 * Command line: `--report-host=host_name`
 * Scope: Global
 * Dynamic: No
 * Data Type: `string`
 
 #### `report_password`
 
-* Description: Replica password reported to the primary when it registers. Reported by [SHOW REPLICA HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md) if `--show-slave-auth-info` is set. This password has no connection with user privileges or with the [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) user account password.
+* Description: Replica password reported to the primary when it registers. Reported by [SHOW SLAVE HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md) if `--show-slave-auth-info` is set. This password has no connection with user privileges or with the [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) user account password.
 * Command line: `--report-password=password`
 * Scope: Global
 * Dynamic: No
@@ -778,7 +778,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `report_user`
 
-* Description: Replica's account user name reported to the primary when it registers. Reported by [SHOW REPLICA HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md) if `--show-slave-auth-info` is set. This username has no connection with user privileges or with the [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) user account.
+* Description: Replica's account user name reported to the primary when it registers. Reported by [SHOW SLAVE HOSTS](../../reference/sql-statements/administrative-sql-statements/show/show-replica-hosts.md) if `--show-slave-auth-info` is set. This username has no connection with user privileges or with the [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) user account.
 * Command line: `--report-user=name`
 * Scope: Global
 * Dynamic: No
@@ -935,7 +935,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
     * [slave\_parallel\_max\_queued](replication-and-binary-log-system-variables.md) \* [slave\_parallel\_threads](replication-and-binary-log-system-variables.md)
   * This system variable is only meaningful when parallel\
     replication is configured (i.e. when [slave\_parallel\_threads](replication-and-binary-log-system-variables.md) > `0`).
-  * See [Parallel Replication: Configuring the Maximum Size of the Parallel Replica Queue](parallel-replication.md#configuring-the-maximum-size-of-the-parallel-slave-queue) for more information.
+  * See [Parallel Replication: Configuring the Maximum Size of the Parallel Slave Queue](parallel-replication.md#configuring-the-maximum-size-of-the-parallel-slave-queue) for more information.
 * Command line: `--slave-parallel-max-queued=#`
 * Scope: Global
 * Dynamic: Yes
@@ -980,7 +980,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `slave_run_triggers_for_rbr`
 
-* Description: See [Running triggers on the replica for Row-based events](running-triggers-on-the-replica-for-row-based-events.md) for a description and use-case for this setting.
+* Description: See [Running triggers on the slave for Row-based events](running-triggers-on-the-replica-for-row-based-events.md) for a description and use-case for this setting.
 * Command line: `--slave-run-triggers-for-rbr=value`
 * Scope: Global
 * Dynamic: Yes
@@ -1086,7 +1086,7 @@ Also see [mariadbd replication options](../../server-management/starting-and-sto
 
 #### `sync_master_info`
 
-* Description: A [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) replica synchronizes its primary.info file to disk after this many events. If set to 0, the operating system handles flushing the file to disk.
+* Description: A [replication](../../server-usage/storage-engines/myrocks/myrocks-and-replication.md) replica synchronizes its master.info file to disk after this many events. If set to 0, the operating system handles flushing the file to disk.
 * Command line: `--sync-master-info=#`
 * Scope: Global
 * Dynamic: Yes

server/ha-and-performance/standard-replication/replication-and-binary-log-system-variables.md

@@ -1,8 +1,8 @@
 ---
 description: >-
-  Wait for a replica to reach a log position. This function blocks until the
-  replica has read and applied updates up to a specified position in the
-  primary's binary log.
+  Wait for a slave to reach a log position. This function blocks until the
+  slave has read and applied updates up to a specified position in the
+  master's binary log.
 ---
 
 # MASTER\_POS\_WAIT
@@ -15,8 +15,8 @@ MASTER_POS_WAIT(log_name,log_pos[,timeout,["connection_name"]])
 
 ## Description
 
-This function is useful in [replication](../../../../ha-and-performance/standard-replication/replication-overview.md) for controlling primary/replica synchronization. It blocks until the replica has read and applied all updates up to the specified position (`log_name,log_pos`) in the primary's binary log. The return value is the number of log events the replica had to wait for to advance to the specified position. The function returns `NULL` if the replica SQL thread is not started, the replica's primary information is not initialized, the arguments are incorrect, or an error occurs. It returns -1 if\
-the timeout has been exceeded. If the replica SQL thread stops while`MASTER_POS_WAIT()` is waiting, the function returns `NULL`. If the replica is past the specified position, the function returns immediately.
+This function is useful in [replication](../../../../ha-and-performance/standard-replication/replication-overview.md) for controlling master/slave synchronization. It blocks until the slave has read and applied all updates up to the specified position (`log_name,log_pos`) in the master's binary log. The return value is the number of log events the slave had to wait for to advance to the specified position. The function returns `NULL` if the slave SQL thread is not started, the slave's master information is not initialized, the arguments are incorrect, or an error occurs. It returns -1 if\
+the timeout has been exceeded. If the slave SQL thread stops while`MASTER_POS_WAIT()` is waiting, the function returns `NULL`. If the slave is past the specified position, the function returns immediately.
 
 If a `timeout` value is specified, `MASTER_POS_WAIT()` stops waiting when `timeout` seconds have elapsed. `timeout` must be greater than 0; a zero or negative `timeout` means no `timeout`.