Update doc

doc/HorizontalReshardingWorkflowGuide.md

@@ -132,7 +132,7 @@ on the clicked button. The approval buttons are cleared after the phase has
 finished. The next phase will only starts if its previous phase has finished
 successfully.
 
-If the workflow is restored from a checkpoint, you will still see the the
+If the workflow is restored from a checkpoint, you will still see the
 approval button with approved message when there are running tasks under this
 approval. But you don't need to approve the same tasks again for a restarted
 workflow.

doc/Monitoring.md

@@ -22,7 +22,7 @@ Scraping Vitess variables is a good way to integrate Vitess into an existing mon
 
 Vitess also includes support for push-based metrics systems via plug-ins. Each Vitess component would need to be run with the `--emit_stats` flag.
 
-By default, the stats_emit_period is 60s, so each component will push stats to the the selected backend every minute. This is configurable via the `--stats_emit_period` flag.
+By default, the stats_emit_period is 60s, so each component will push stats to the selected backend every minute. This is configurable via the `--stats_emit_period` flag.
 
 Vitess has preliminary plug-ins to support OpenTSDB as a push-based metrics backend.
 

doc/SchemaManagement.md

@@ -64,7 +64,7 @@ ValidateSchemaShard user/0
 
 The <code>[ValidateSchemaKeyspace]({% link reference/vtctl.md %}#validateschemakeyspace)</code>
 command confirms that all of the tablets in a given keyspace have
-the the same schema as the master tablet on shard <code>0</code>
+the same schema as the master tablet on shard <code>0</code>
 in that keyspace. Thus, whereas the <code>ValidateSchemaShard</code>
 command confirms the consistency of the schema on tablets within a shard
 for a given keyspace, <code>ValidateSchemaKeyspace</code> confirms the

doc/V3HighLevelDesign.md

@@ -1491,7 +1491,7 @@ If a, b and c where in different groups, the output would be:
 a   b where (b.id=a.id) and (cond1(a.col, b.col))
 ```
 
-The cond2 expression gets pushed into the the where clause for table ‘c’ because it’s the right-most group that’s referenced by the condition. External references will be changed to appropriate bind variables by the rewiring phase.
+The cond2 expression gets pushed into the where clause for table ‘c’ because it’s the right-most group that’s referenced by the condition. External references will be changed to appropriate bind variables by the rewiring phase.
 
 *Once VTGate acquires the ability to perform its own filters, should we stop pushing these conditions into the dependent queries and do it ourselves instead? The answer will usually be no. You almost always want to push down filters. This is because it will let the underlying database scan fewer rows, or choose better indexes. The more restrictive the query is, the better.*
 

doc/V3VindexDesign.md

@@ -251,7 +251,7 @@ When you fire up the schema editor, it should take you to the load workflow. The
 
 The schema picks up the loaded JSON, parse it and display the various components of the schema in a page where the relationships are easily visualized. The vschema has four main components: keyspaces, tables, table classes and vindexes.
 
-Keyspaces can be on a left navbar. Once you select the keyspaces, it will display the the rest of the three components in one column each.
+Keyspaces can be on a left navbar. Once you select the keyspaces, it will display the rest of the three components in one column each.
 
 The schema editor will sanity check the JSON file for inconsistencies and flag them using various color codes:
 

doc/VitessApi.md

@@ -488,7 +488,7 @@ Split a query into non-overlapping sub queries
 
 #### Request
 
- SplitQueryRequest is the payload to SplitQuery.  SplitQuery takes a "SELECT" query and generates a list of queries called "query-parts". Each query-part consists of the original query with an added WHERE clause that restricts the query-part to operate only on rows whose values in the the columns listed in the "split_column" field of the request (see below) are in a particular range.  It is guaranteed that the set of rows obtained from executing each query-part on a database snapshot and merging (without deduping) the results is equal to the set of rows obtained from executing the original query on the same snapshot with the rows containing NULL values in any of the split_column's excluded.  This is typically called by the MapReduce master when reading from Vitess. There it's desirable that the sets of rows returned by the query-parts have roughly the same size.
+ SplitQueryRequest is the payload to SplitQuery.  SplitQuery takes a "SELECT" query and generates a list of queries called "query-parts". Each query-part consists of the original query with an added WHERE clause that restricts the query-part to operate only on rows whose values in the columns listed in the "split_column" field of the request (see below) are in a particular range.  It is guaranteed that the set of rows obtained from executing each query-part on a database snapshot and merging (without deduping) the results is equal to the set of rows obtained from executing the original query on the same snapshot with the rows containing NULL values in any of the split_column's excluded.  This is typically called by the MapReduce master when reading from Vitess. There it's desirable that the sets of rows returned by the query-parts have roughly the same size.
 
 ##### Parameters