diff --git a/content/en/docs/concepts/shard.md b/content/en/docs/concepts/shard.md index 5e3e491ae..11a343f5f 100644 --- a/content/en/docs/concepts/shard.md +++ b/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 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. diff --git a/content/en/docs/concepts/tablet.md b/content/en/docs/concepts/tablet.md index e44d93e15..23589b0d9 100644 --- a/content/en/docs/concepts/tablet.md +++ b/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). diff --git a/content/en/docs/reference/features/schema-management.md b/content/en/docs/reference/features/schema-management.md index ae8785bf3..0fc1cd972 100644 --- a/content/en/docs/reference/features/schema-management.md +++ b/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_file=} ` +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_file=} ` When the `ApplySchema` action actually applies a schema change to the specified keyspace, it performs the following steps: diff --git a/content/en/docs/reference/features/sharding.md b/content/en/docs/reference/features/sharding.md index 323304cc1..fcbb7a596 100644 --- a/content/en/docs/reference/features/sharding.md +++ b/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 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