Add docs on VTGate buffering for MoveTables and Reshard traffic switc…

…hing (#1733) * Add some docs on VTGate buffering for MoveTables and Reshard traffic switching Signed-off-by: Matt Lord <[email protected]> * Address review comments Signed-off-by: Matt Lord <[email protected]> --------- Signed-off-by: Matt Lord <[email protected]>
vitessio · May 23, 2024 · 3a7938a · 3a7938a
1 parent d3fdc2c
commit 3a7938a
Show file tree

Hide file tree

Showing 4 changed files with 30 additions and 7 deletions.
diff --git a/content/en/docs/20.0/concepts/move-tables.md b/content/en/docs/20.0/concepts/move-tables.md
@@ -2,7 +2,7 @@
 title: MoveTables
 ---
 
-MoveTables is a new workflow based on VReplication. It enables you to relocate tables between keyspaces, and therefore physical MySQL instances, without downtime.
+MoveTables is a workflow based on VReplication. It enables you to relocate tables between keyspaces, and therefore physical MySQL instances, without downtime.
 
 ## Identifying Candidate Tables
 

diff --git a/content/en/docs/20.0/reference/features/vtgate-buffering.md b/content/en/docs/20.0/reference/features/vtgate-buffering.md
@@ -22,6 +22,13 @@ with the simplest case: that of buffering during a PRS (PlannedReparentShard)
 operation. Examples of various edge cases can be found in
 [Buffering Scenarios](../../../user-guides/configuration-advanced/buffering-scenarios/).
 
+{{< warning >}}
+The buffering feature is not guaranteed to eliminate errors sent to the application, but
+rather reduce them or make them less frequent. The application should still endeavor to
+handle errors appropriately if/when they occur (e.g. unplanned outages, planned failovers,
+VReplication migrations, etc.)
+{{< /warning >}}
+
 ## VTGate flags to enable buffering
 
 First, let us cover the flags that need to be set in VTGate to enable
@@ -75,13 +82,13 @@ Fundamentally Vitess will:
  * Drain the buffered queries to the new `PRIMARY` tablet.
  * Begin the countdown timer for `buffer_max_failover_duration`.
 
- {{< warning >}}
-This process is not guaranteed to eliminate errors to the application, but
-rather reduce them or make them less frequent. The application should still
-endeavor to handle errors appropriately if/when they occur (e.g. unplanned
-outages/fail overs, etc.)
-{{< /warning >}}
+## What happens during a MoveTables or Reshard SwitchTraffic or ReverseTraffic with Buffering
+
+Fundamentally Vitess will:
 
+ * Hold up and buffer any queries sent to the tables (MoveTables) or shards (Reshard) for which traffic is being switched.
+ * Perform the traffic switching work so that application traffic against the tables (MoveTables) or shards (Reshard) are transparently switched to the new keyspace (MoveTables) or shards (Reshard).
+ * Drain the buffered queries to the new keyspace or shards — or if the switch failed then back to the original keyspace or shards.
 
 ## How does it work?
 

diff --git a/content/en/docs/20.0/reference/vreplication/movetables.md b/content/en/docs/20.0/reference/vreplication/movetables.md
@@ -80,13 +80,21 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`switchtraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_switchtraffic/) switches traffic forward for the `tablet-types` specified. You can switch all traffic with just one command, and this is the default behavior. Note that you can now switch replica, rdonly, and primary traffic in any order.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when switching traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### ReverseTraffic
 <div class="cmd">
 
 [`reversetraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_reversetraffic/) switches traffic in the reverse direction for the `tablet-types` specified. The traffic should have been previously switched forward using `SwitchTraffic` for the `cells` and `tablet-types` specified.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when reversing traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### Cancel

diff --git a/content/en/docs/20.0/reference/vreplication/reshard.md b/content/en/docs/20.0/reference/vreplication/reshard.md
@@ -64,13 +64,21 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`SwitchTraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_switchtraffic) switches traffic forward for the `tablet-types` specified. This replaces the previous `SwitchReads` and `SwitchWrites` commands with a single one. It is now possible to switch all traffic with just one command, and this is the default behavior. Also, you can now switch replica, rdonly and primary traffic in any order: earlier you needed to first `SwitchReads` (for replicas and rdonly tablets) first before `SwitchWrites`.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when switching traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### ReverseTraffic
 <div class="cmd">
 
 [`ReverseTraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_reversetraffic/) switches traffic in the reverse direction for the `tablet-types` specified. The traffic should have been previously switched forward using `SwitchTraffic` for the `cells` and `tablet_types` specified.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when reversing traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### Cancel