From a4cf44bc4f651171f2816e5007784eb832f82a73 Mon Sep 17 00:00:00 2001 From: xichengliudui <1693291525@qq.com> Date: Fri, 25 Jan 2019 14:21:25 -0500 Subject: [PATCH] Update doc Signed-off-by: xichengliudui --- doc/HorizontalReshardingWorkflowGuide.md | 2 +- doc/Monitoring.md | 2 +- doc/SchemaManagement.md | 2 +- doc/V3HighLevelDesign.md | 2 +- doc/V3VindexDesign.md | 2 +- doc/VitessApi.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/HorizontalReshardingWorkflowGuide.md b/doc/HorizontalReshardingWorkflowGuide.md index f28be1a0a34..a287e194664 100644 --- a/doc/HorizontalReshardingWorkflowGuide.md +++ b/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. diff --git a/doc/Monitoring.md b/doc/Monitoring.md index 9722ea0ba0b..3864ea87266 100644 --- a/doc/Monitoring.md +++ b/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. diff --git a/doc/SchemaManagement.md b/doc/SchemaManagement.md index c83e049153a..1bdfcc6da66 100644 --- a/doc/SchemaManagement.md +++ b/doc/SchemaManagement.md @@ -64,7 +64,7 @@ ValidateSchemaShard user/0 The [ValidateSchemaKeyspace]({% link reference/vtctl.md %}#validateschemakeyspace) command confirms that all of the tablets in a given keyspace have -the the same schema as the master tablet on shard 0 +the same schema as the master tablet on shard 0 in that keyspace. Thus, whereas the ValidateSchemaShard command confirms the consistency of the schema on tablets within a shard for a given keyspace, ValidateSchemaKeyspace confirms the diff --git a/doc/V3HighLevelDesign.md b/doc/V3HighLevelDesign.md index ebbd647fff7..6e87e140043 100644 --- a/doc/V3HighLevelDesign.md +++ b/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.* diff --git a/doc/V3VindexDesign.md b/doc/V3VindexDesign.md index f6d051b77d5..a0f4e930b5f 100644 --- a/doc/V3VindexDesign.md +++ b/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: diff --git a/doc/VitessApi.md b/doc/VitessApi.md index 5333b61cb49..d4696429bdb 100644 --- a/doc/VitessApi.md +++ b/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