Part 1 of terminology changes

content/en/docs/concepts/shard.md

@@ -2,9 +2,9 @@
 title: Shard
 ---
 
-A *shard* is a division within a keyspace. A shard typically contains one MySQL master and many MySQL slaves.
+A *shard* is a division within a keyspace. A shard typically contains one MySQL master and many MySQL replicas.
 
-Each MySQL instance within a shard has the same data (excepting some replication lag). The slaves can serve read-only traffic (with eventual consistency guarantees), execute long-running data analysis tools, or perform administrative tasks (backup, restore, diff, etc.).
+Each MySQL instance within a shard has the same data (excepting some replication lag). The replicas can serve read-only traffic (with eventual consistency guarantees), execute long-running data analysis tools, or perform administrative tasks (backup, restore, diff, etc.).
 
 An unsharded keyspace has effectively one shard. Vitess names the shard `0` by convention. When sharded, a keyspace has `N` shards with non-overlapping data.
 

content/en/docs/concepts/tablet.md

@@ -11,8 +11,8 @@ Queries are routed to a tablet via a [VTGate](../vtgate) server.
 See the user guide [VTTablet Modes](../../user-guides/vttablet-modes) for more information.
 
 * **master** - A *replica* tablet that happens to currently be the MySQL master for its shard.
-* **replica** - A MySQL slave that is eligible to be promoted to *master*. Conventionally, these are reserved for serving live, user-facing requests (like from the website's frontend).
-* **rdonly** - A MySQL slave that cannot be promoted to *master*. Conventionally, these are used for background processing jobs, such as taking backups, dumping data to other systems, heavy analytical queries, MapReduce, and resharding.
+* **replica** - A MySQL replica that is eligible to be promoted to *master*. Conventionally, these are reserved for serving live, user-facing requests (like from the website's frontend).
+* **rdonly** - A MySQL replica that cannot be promoted to *master*. Conventionally, these are used for background processing jobs, such as taking backups, dumping data to other systems, heavy analytical queries, MapReduce, and resharding.
 * **backup** - A tablet that has stopped replication at a consistent snapshot, so it can upload a new backup for its shard. After it finishes, it will resume replication and return to its previous type.
 * **restore** - A tablet that has started up with no data, and is in the process of restoring itself from the latest backup. After it finishes, it will begin replicating at the GTID position of the backup, and become either *replica* or *rdonly*.
 * **drained** - A tablet that has been reserved by a Vitess background process (such as rdonly tablets for resharding).

content/en/docs/reference/features/schema-management.md

@@ -42,9 +42,9 @@ GetSchema test-000000100
 
 ### ValidateSchemaShard
 
-The [`ValidateSchemaShard`](../../reference/vtctl/#validateschemashard) command confirms that for a given keyspace, all of the slave tablets in a specified shard have the same schema as the master tablet in that shard. When you call `ValidateSchemaShard`, you specify both the keyspace and the shard that you are validating.
+The [`ValidateSchemaShard`](../../reference/vtctl/#validateschemashard) command confirms that for a given keyspace, all of the replica tablets in a specified shard have the same schema as the master tablet in that shard. When you call `ValidateSchemaShard`, you specify both the keyspace and the shard that you are validating.
 
-The following command confirms that the master and slave tablets in shard `0` all have the same schema for the `user` keyspace:
+The following command confirms that the master and replica tablets in shard `0` all have the same schema for the `user` keyspace:
 
 ``` sh
 ValidateSchemaShard user/0
@@ -88,7 +88,7 @@ Vitess' schema modification functionality is designed the following goals in min
 
 Note that, at this time, Vitess only supports [data definition statements](https://dev.mysql.com/doc/refman/5.6/en/sql-syntax-data-definition.html) that create, modify, or delete database tables. For instance, `ApplySchema` does not affect stored procedures or grants.
 
-The [ApplySchema](../../reference/vtctl/#applyvschema) command applies a schema change to the specified keyspace on every master tablet, running in parallel on all shards. Changes are then propagated to slaves via replication. The command format is: `ApplySchema {-sql=<sql> || -sql_file=<filename>} <keyspace>`
+The [ApplySchema](../../reference/vtctl/#applyvschema) command applies a schema change to the specified keyspace on every master tablet, running in parallel on all shards. Changes are then propagated to replicas. The command format is: `ApplySchema {-sql=<sql> || -sql_file=<filename>} <keyspace>`
 
 When the `ApplySchema` action actually applies a schema change to the specified keyspace, it performs the following steps:
 

content/en/docs/reference/features/sharding.md

@@ -13,7 +13,7 @@ A keyspace in Vitess can be sharded or unsharded. An unsharded keyspace maps dir
 
 For example, if an application's "user" keyspace is split into two shards, each shard contains records for approximately half of the application's users. Similarly, each user's information is stored in only one shard.
 
-Note that sharding is orthogonal to (MySQL) replication. A Vitess shard typically contains one MySQL master and many MySQL slaves. The master handles write operations, while slaves handle read-only traffic, batch processing operations, and other tasks. Each MySQL instance within the shard should have the same data, excepting some replication lag.
+Note that sharding is orthogonal to (MySQL) replication. A Vitess shard typically contains one MySQL master and many MySQL replicas. The master handles write operations, while replicas handle read-only traffic, batch processing operations, and other tasks. Each MySQL instance within the shard should have the same data, excepting some replication lag.
 
 ### Supported Operations
 

content/en/docs/reference/programs/mysqlctl.md

@@ -146,7 +146,7 @@ The following global parameters apply to `mysqlctl`:
 | log_err_stacks | boolean | log stack traces for errors |
 | log_rotate_max_size | uint | size in bytes at which logs are rotated (glog.MaxSize) (default 1887436800) |
 | logtostderr | boolean | log to standard error instead of files |
-| master_connect_retry | duration | how long to wait in between slave -> connection attempts. Only precise to the second. (default 10s) |
+| master_connect_retry | duration | how long to wait in between replica reconnect attempts. Only precise to the second. (default 10s) |
 | mem-profile-rate | int | profile every n bytes allocated (default 524288) |
 | mutex-profile-fraction | int | profile every n mutex contention events (see runtime.SetMutexProfileFraction) |
 | mysql_auth_server_static_file | string | JSON File to read the users/passwords from. |

content/en/docs/reference/programs/vtctl.md

@@ -280,7 +280,7 @@ The following global options apply to `vtctl`:
 | -log_err_stacks | | log stack traces for errors |
 | -log_rotate_max_size | uint | size in bytes at which logs are rotated (glog.MaxSize) (default 1887436800) |
 | -logtostderr | | log to standard error instead of files |
-| -master_connect_retry | duration | how long to wait in between slave -> connection attempts. Only precise to the second. (default 10s) |
+| -master_connect_retry | duration | how long to wait in between replica reconnect attempts. Only precise to the second. (default 10s) |
 | -mem-profile-rate | int | profile every n bytes allocated (default 524288) |
 | -min_number_serving_vttablets | int | the minimum number of vttablets that will be continue to be used even with low replication lag (default 2) |
 | -mutex-profile-fraction | int | profile every n mutex contention events (see runtime.SetMutexProfileFraction) |