diff --git a/content/en/docs/15.0/get-started/local-brew.md b/content/en/docs/15.0/get-started/local-brew.md
index f9d9a56c8..c60bec6e8 100644
--- a/content/en/docs/15.0/get-started/local-brew.md
+++ b/content/en/docs/15.0/get-started/local-brew.md
@@ -1,7 +1,7 @@
---
title: Local Install via Homebrew
description: Instructions for using Vitess on your macOS machine for testing purposes
-weight: 2
+weight: 3
featured: true
aliases: ['/docs/tutorials/local-brew/']
---
diff --git a/content/en/docs/15.0/get-started/local-docker.md b/content/en/docs/15.0/get-started/local-docker.md
index f9b56336b..0f6c36bfb 100644
--- a/content/en/docs/15.0/get-started/local-docker.md
+++ b/content/en/docs/15.0/get-started/local-docker.md
@@ -1,11 +1,15 @@
---
title: Local Install via Docker
description: Instructions for using Vitess on your machine for testing purposes
-weight: 1
-featured: true
+weight: 5
+featured: false
aliases: ['/docs/tutorials/local-docker/']
---
+{{< warning >}}
+This guide will only work on x86_64/amd64 based machines.
+{{ warning >}}
+
This guide illustrates how to run a local testing Vitess setup via Docker. The Vitess environment is identical to the [local setup](../local/), but without having to install software on one's host other than Docker.
## Check out the vitessio/vitess repository
diff --git a/content/en/docs/15.0/get-started/local.md b/content/en/docs/15.0/get-started/local.md
index 93dc51e51..d9e0e8188 100644
--- a/content/en/docs/15.0/get-started/local.md
+++ b/content/en/docs/15.0/get-started/local.md
@@ -85,11 +85,11 @@ Download the [latest binary release](https://github.com/vitessio/vitess/releases
**Notes:**
* Release 15.0 has a bug because of which the local example fails when try to run vtadmin web. [Issue#11679](https://github.com/vitessio/vitess/issues/11679)
-* Please use release [15.0.3](https://github.com/vitessio/vitess/releases/tag/v15.0.3) instead.
+* Please use release [15.0.3](https://github.com/vitessio/vitess/releases/tag/v15.0.3) or later.
```sh
-version=15.0.3
-file=vitess-${version}-652b0da.tar.gz
+version=15.0.4
+file=vitess-${version}-72d943e.tar.gz
wget https://github.com/vitessio/vitess/releases/download/v${version}/${file}
tar -xzf ${file}
cd ${file/.tar.gz/}
diff --git a/content/en/docs/15.0/get-started/operator.md b/content/en/docs/15.0/get-started/operator.md
index 16adcfa87..621b3bdb1 100644
--- a/content/en/docs/15.0/get-started/operator.md
+++ b/content/en/docs/15.0/get-started/operator.md
@@ -1,6 +1,6 @@
---
title: Vitess Operator for Kubernetes
-weight: 3
+weight: 1
featured: true
aliases: ['/docs/tutorials/kubernetes/','/user-guide/sharding-kubernetes.html', '/docs/get-started/scaleway/','/docs/get-started/kubernetes/']
---
diff --git a/content/en/docs/15.0/get-started/vttestserver-docker-image.md b/content/en/docs/15.0/get-started/vttestserver-docker-image.md
index b4a7aab80..e5f452a5f 100644
--- a/content/en/docs/15.0/get-started/vttestserver-docker-image.md
+++ b/content/en/docs/15.0/get-started/vttestserver-docker-image.md
@@ -1,6 +1,6 @@
---
title: Vttestserver Docker Image
-weight: 4
+weight: 10
featured: true
aliases: ['/docs/tutorials/vttestserver/']
---
diff --git a/content/en/docs/15.0/reference/features/messaging.md b/content/en/docs/15.0/reference/features/messaging.md
index d0dc86136..8724ae323 100644
--- a/content/en/docs/15.0/reference/features/messaging.md
+++ b/content/en/docs/15.0/reference/features/messaging.md
@@ -122,12 +122,22 @@ Messages can also be created to be sent in the future:
## Receiving messages
-Processes can subscribe to receive messages by sending a `MessageStream`
+Processes can subscribe to receive messages by sending a [`MessageStream`](https://pkg.go.dev/vitess.io/vitess/go/vt/vtgate#Executor.MessageStream)
gRPC request to a `VTGate` or using the `stream * from
` SQL statement
(if using the interactive mysql command-line client you must also pass the
-`-q`/`--quick` option). If there are multiple subscribers, the messages will be
-delivered in a round-robin fashion. Note that *this is not a broadcast*; each
-message will be sent to at most one subscriber.
+`-q`/`--quick` option):
+
+```mysql
+$ mysql --quick
+mysql> SET WORKLOAD=OLAP;
+mysql> STREAM * FROM
;
+```
+
+
+
+If there are multiple subscribers, the messages will be delivered in a round-robin
+fashion. Note that *this is not a broadcast*; each message will be sent to at most
+one subscriber.
The format for messages is the same as a standard Vitess `Result` received from
a `VTGate`. This means that standard database tools that understand query results
diff --git a/content/en/docs/16.0/get-started/local-brew.md b/content/en/docs/16.0/get-started/local-brew.md
index 73c833660..95723c40a 100644
--- a/content/en/docs/16.0/get-started/local-brew.md
+++ b/content/en/docs/16.0/get-started/local-brew.md
@@ -1,7 +1,7 @@
---
title: Local Install via Homebrew
description: Instructions for using Vitess on your macOS machine for testing purposes
-weight: 2
+weight: 3
featured: true
aliases: ['/docs/tutorials/local-brew/']
---
diff --git a/content/en/docs/16.0/get-started/local-docker.md b/content/en/docs/16.0/get-started/local-docker.md
index 8eaecff3f..d4bf43fd5 100644
--- a/content/en/docs/16.0/get-started/local-docker.md
+++ b/content/en/docs/16.0/get-started/local-docker.md
@@ -1,11 +1,15 @@
---
title: Local Install via Docker
description: Instructions for using Vitess on your machine for testing purposes
-weight: 1
-featured: true
+weight: 5
+featured: false
aliases: ['/docs/tutorials/local-docker/']
---
+{{< warning >}}
+This guide will only work on x86_64/amd64 based machines.
+{{ warning >}}
+
This guide illustrates how to run a local testing Vitess setup via Docker. The Vitess environment is identical to the [local setup](../local/), but without having to install software on one's host other than Docker.
## Check out the vitessio/vitess repository
diff --git a/content/en/docs/16.0/get-started/local.md b/content/en/docs/16.0/get-started/local.md
index e8b62b803..c1e427715 100644
--- a/content/en/docs/16.0/get-started/local.md
+++ b/content/en/docs/16.0/get-started/local.md
@@ -85,12 +85,12 @@ Download the [latest binary release](https://github.com/vitessio/vitess/releases
**Notes:**
* Release 16.0.0 has an issue where the VTAdmin `web` directory is missing from the release artifacts.
-* Please use release [16.0.2](https://github.com/vitessio/vitess/releases/tag/v16.0.2) instead.
+* Please use release [16.0.2](https://github.com/vitessio/vitess/releases/tag/v16.0.2) or later.
* Ubuntu is the only fully supported OS, for another OS please [build Vitess by yourself](/docs/contributing) or use the Docker images.
```sh
-version=16.0.2
-file=vitess-${version}-6076fed.tar.gz
+version=16.0.3
+file=vitess-${version}-a93cb55.tar.gz
wget https://github.com/vitessio/vitess/releases/download/v${version}/${file}
tar -xzf ${file}
cd ${file/.tar.gz/}
diff --git a/content/en/docs/16.0/get-started/operator.md b/content/en/docs/16.0/get-started/operator.md
index 8e17c183f..55112f490 100644
--- a/content/en/docs/16.0/get-started/operator.md
+++ b/content/en/docs/16.0/get-started/operator.md
@@ -1,6 +1,6 @@
---
title: Vitess Operator for Kubernetes
-weight: 3
+weight: 1
featured: true
aliases: ['/docs/tutorials/kubernetes/','/user-guide/sharding-kubernetes.html', '/docs/get-started/scaleway/','/docs/get-started/kubernetes/']
---
diff --git a/content/en/docs/16.0/get-started/vttestserver-docker-image.md b/content/en/docs/16.0/get-started/vttestserver-docker-image.md
index 5d6949b53..fac47efe5 100644
--- a/content/en/docs/16.0/get-started/vttestserver-docker-image.md
+++ b/content/en/docs/16.0/get-started/vttestserver-docker-image.md
@@ -1,6 +1,6 @@
---
title: Vttestserver Docker Image
-weight: 4
+weight: 10
featured: true
aliases: ['/docs/tutorials/vttestserver/']
---
diff --git a/content/en/docs/16.0/reference/features/messaging.md b/content/en/docs/16.0/reference/features/messaging.md
index d0dc86136..8724ae323 100644
--- a/content/en/docs/16.0/reference/features/messaging.md
+++ b/content/en/docs/16.0/reference/features/messaging.md
@@ -122,12 +122,22 @@ Messages can also be created to be sent in the future:
## Receiving messages
-Processes can subscribe to receive messages by sending a `MessageStream`
+Processes can subscribe to receive messages by sending a [`MessageStream`](https://pkg.go.dev/vitess.io/vitess/go/vt/vtgate#Executor.MessageStream)
gRPC request to a `VTGate` or using the `stream * from
` SQL statement
(if using the interactive mysql command-line client you must also pass the
-`-q`/`--quick` option). If there are multiple subscribers, the messages will be
-delivered in a round-robin fashion. Note that *this is not a broadcast*; each
-message will be sent to at most one subscriber.
+`-q`/`--quick` option):
+
+```mysql
+$ mysql --quick
+mysql> SET WORKLOAD=OLAP;
+mysql> STREAM * FROM
;
+```
+
+
+
+If there are multiple subscribers, the messages will be delivered in a round-robin
+fashion. Note that *this is not a broadcast*; each message will be sent to at most
+one subscriber.
The format for messages is the same as a standard Vitess `Result` received from
a `VTGate`. This means that standard database tools that understand query results
diff --git a/content/en/docs/17.0/get-started/local-brew.md b/content/en/docs/17.0/get-started/local-brew.md
index a895481af..3d752fa8d 100644
--- a/content/en/docs/17.0/get-started/local-brew.md
+++ b/content/en/docs/17.0/get-started/local-brew.md
@@ -1,7 +1,7 @@
---
title: Local Install via Homebrew
description: Instructions for using Vitess on your macOS machine for testing purposes
-weight: 2
+weight: 3
featured: true
aliases: ['/docs/tutorials/local-brew/']
---
@@ -37,12 +37,12 @@ Already downloaded: /Users/askdba/Library/Caches/Homebrew/downloads/45991b27589a
```
At this point Vitess binaries installed under default Homebrew install location at /usr/local/share/vitess.
-### Install Node 16.13.0+ (required to run VTAdmin)
+### Install Node 18.16.0+ (required to run VTAdmin)
```bash
$ brew install nvm
-$ nvm install --lts 16.13.0
-$ nvm use 16.13.0
+$ nvm install --lts 18.16.0
+$ nvm use 18.16.0
```
See the [vtadmin README](https://github.com/vitessio/vitess/blob/main/web/vtadmin/README.md) for more details.
@@ -60,41 +60,42 @@ Created cell: zone1
etcd start done...
Starting vtctld...
vtctld is running!
+Successfully created keyspace commerce. Result:
+{
+ "name": "commerce",
+ "keyspace": {
+ "served_froms": [],
+ "keyspace_type": 0,
+ "base_keyspace": "",
+ "snapshot_time": null,
+ "durability_policy": "semi_sync",
+ "throttler_config": null,
+ "sidecar_db_name": "_vt"
+ }
+}
Starting MySQL for tablet zone1-0000000100...
Starting vttablet for zone1-0000000100...
HTTP/1.1 200 OK
-Date: Thu, 01 Sep 2022 12:49:50 GMT
+Date: Mon, 26 Jun 2023 19:21:51 GMT
Content-Type: text/html; charset=utf-8
Starting MySQL for tablet zone1-0000000101...
Starting vttablet for zone1-0000000101...
HTTP/1.1 200 OK
-Date: Thu, 01 Sep 2022 12:49:55 GMT
+Date: Mon, 26 Jun 2023 19:21:54 GMT
Content-Type: text/html; charset=utf-8
Starting MySQL for tablet zone1-0000000102...
Starting vttablet for zone1-0000000102...
HTTP/1.1 200 OK
-Date: Thu, 01 Sep 2022 12:50:00 GMT
+Date: Mon, 26 Jun 2023 19:21:56 GMT
Content-Type: text/html; charset=utf-8
-{
- "keyspace": {
- "served_froms": [],
- "keyspace_type": 0,
- "base_keyspace": "",
- "snapshot_time": null,
- "durability_policy": "semi_sync",
- "throttler_config": null,
- "sidecar_db_name": "_vt"
- }
-}
vtorc is running!
- UI: http://localhost:16000
- - Logs: /Users/manangupta/vitess/vtdataroot/tmp/vtorc.out
- - PID: 74088
+ - Logs: /Users/florentpoinsard/Code/vitess/vtdataroot/tmp/vtorc.out
+ - PID: 49556
-zone1-0000000100 commerce 0 primary localhost:15100 localhost:17100 [] 2022-09-23T05:48:52Z
New VSchema object:
{
@@ -107,7 +108,8 @@ New VSchema object:
"auto_increment": null,
"columns": [],
"pinned": "",
- "column_list_authoritative": false
+ "column_list_authoritative": false,
+ "source": ""
},
"customer": {
"type": "",
@@ -115,7 +117,8 @@ New VSchema object:
"auto_increment": null,
"columns": [],
"pinned": "",
- "column_list_authoritative": false
+ "column_list_authoritative": false,
+ "source": ""
},
"product": {
"type": "",
@@ -123,7 +126,8 @@ New VSchema object:
"auto_increment": null,
"columns": [],
"pinned": "",
- "column_list_authoritative": false
+ "column_list_authoritative": false,
+ "source": ""
}
},
"require_explicit_routing": false
@@ -131,51 +135,16 @@ New VSchema object:
If this is not what you expected, check the input data (as JSON parsing will skip unexpected fields).
Waiting for vtgate to be up...
vtgate is up!
-Access vtgate at http://Manans-MacBook-Pro.local:15001/debug/status
+Access vtgate at http://Florents-MacBook-Pro-2.local:15001/debug/status
vtadmin-api is running!
- - API: http://localhost:14200
- - Logs: /Users/manangupta/vitess/vtdataroot/tmp/vtadmin-api.out
- - PID: 74039
-
-> vtadmin@0.1.0 build
-> vite build
-
-vite v4.2.1 building for production...
-transforming (1218) src/icons/alertFail.svgUse of eval in "node_modules/@protobufjs/inquire/index.js" is strongly discouraged as it poses security risks and may cause issues with minification.
-✓ 1231 modules transformed.
-build/assets/chevronUp-3d6782a5.svg 0.18 kB
-build/assets/chevronDown-02f94e73.svg 0.19 kB
-build/assets/download-8ef290b4.svg 0.21 kB
-build/assets/delete-a9184ef9.svg 0.23 kB
-build/assets/info-2617ee9d.svg 0.34 kB
-build/assets/circleAdd-cfd7e5db.svg 0.35 kB
-build/assets/alertFail-8056b6e4.svg 0.35 kB
-build/assets/checkSuccess-f8fd1dbb.svg 0.36 kB
-build/assets/search-3261bac7.svg 0.41 kB
-build/assets/question-a67b2492.svg 0.46 kB
-build/assets/runQuery-edfab4ed.svg 0.49 kB
-build/assets/open-405dd348.svg 0.49 kB
-build/index.html 0.90 kB
-build/assets/bug-5b6edb54.svg 0.99 kB
-build/assets/topology-0032b65e.svg 1.62 kB
-build/assets/NotoMono-Regular-41fd7ccc.ttf 107.85 kB
-build/assets/NotoSans-Regular-c8cff31f.ttf 313.14 kB
-build/assets/NotoSans-SemiBold-43207822.ttf 313.72 kB
-build/assets/NotoSans-Bold-c6a598dd.ttf 313.79 kB
-build/assets/index-ef40fbc9.css 87.78 kB │ gzip: 15.02 kB
-build/assets/index-4ddb52ed.js 2,811.88 kB │ gzip: 492.59 kB
-
-(!) Some chunks are larger than 500 kBs after minification. Consider:
-- Using dynamic import() to code-split the application
-- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
-- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
-✓ built in 10.85s
+ - API: http://Florents-MacBook-Pro-2.local:14200
+ - Logs: /Users/florentpoinsard/Code/vitess/vtdataroot/tmp/vtadmin-api.out
+ - PID: 49695
vtadmin-web is running!
- - Browser: http://localhost:14201
- - Logs: /Users/manangupta/vitess/vtdataroot/tmp/vtadmin-web.out
- - PID: 74070
-
+ - Browser: http://Florents-MacBook-Pro-2.local:14201
+ - Logs: /Users/florentpoinsard/Code/vitess/vtdataroot/tmp/vtadmin-web.out
+ - PID: 49698
```
Verify your initial cluster:
```sql
diff --git a/content/en/docs/17.0/get-started/local-docker.md b/content/en/docs/17.0/get-started/local-docker.md
index 8eaecff3f..d4bf43fd5 100644
--- a/content/en/docs/17.0/get-started/local-docker.md
+++ b/content/en/docs/17.0/get-started/local-docker.md
@@ -1,11 +1,15 @@
---
title: Local Install via Docker
description: Instructions for using Vitess on your machine for testing purposes
-weight: 1
-featured: true
+weight: 5
+featured: false
aliases: ['/docs/tutorials/local-docker/']
---
+{{< warning >}}
+This guide will only work on x86_64/amd64 based machines.
+{{ warning >}}
+
This guide illustrates how to run a local testing Vitess setup via Docker. The Vitess environment is identical to the [local setup](../local/), but without having to install software on one's host other than Docker.
## Check out the vitessio/vitess repository
diff --git a/content/en/docs/17.0/get-started/local.md b/content/en/docs/17.0/get-started/local.md
index 2593b7144..717c09ff7 100644
--- a/content/en/docs/17.0/get-started/local.md
+++ b/content/en/docs/17.0/get-started/local.md
@@ -65,8 +65,8 @@ Download the [latest binary release](https://github.com/vitessio/vitess/releases
* Ubuntu is the only fully supported OS, for another OS please [build Vitess by yourself](/docs/contributing) or use the Docker images.
```sh
-version=17.0.0
-file=vitess-${version}-70a9466.tar.gz
+version=17.0.1
+file=vitess-${version}-a4e751f.tar.gz
wget https://github.com/vitessio/vitess/releases/download/v${version}/${file}
tar -xzf ${file}
cd ${file/.tar.gz/}
diff --git a/content/en/docs/17.0/get-started/operator.md b/content/en/docs/17.0/get-started/operator.md
index 8e17c183f..55112f490 100644
--- a/content/en/docs/17.0/get-started/operator.md
+++ b/content/en/docs/17.0/get-started/operator.md
@@ -1,6 +1,6 @@
---
title: Vitess Operator for Kubernetes
-weight: 3
+weight: 1
featured: true
aliases: ['/docs/tutorials/kubernetes/','/user-guide/sharding-kubernetes.html', '/docs/get-started/scaleway/','/docs/get-started/kubernetes/']
---
diff --git a/content/en/docs/17.0/get-started/vttestserver-docker-image.md b/content/en/docs/17.0/get-started/vttestserver-docker-image.md
index 46924ef98..b7193536c 100644
--- a/content/en/docs/17.0/get-started/vttestserver-docker-image.md
+++ b/content/en/docs/17.0/get-started/vttestserver-docker-image.md
@@ -1,6 +1,6 @@
---
title: Vttestserver Docker Image
-weight: 4
+weight: 10
featured: true
aliases: ['/docs/tutorials/vttestserver/']
---
diff --git a/content/en/docs/17.0/reference/features/messaging.md b/content/en/docs/17.0/reference/features/messaging.md
index d0dc86136..8724ae323 100644
--- a/content/en/docs/17.0/reference/features/messaging.md
+++ b/content/en/docs/17.0/reference/features/messaging.md
@@ -122,12 +122,22 @@ Messages can also be created to be sent in the future:
## Receiving messages
-Processes can subscribe to receive messages by sending a `MessageStream`
+Processes can subscribe to receive messages by sending a [`MessageStream`](https://pkg.go.dev/vitess.io/vitess/go/vt/vtgate#Executor.MessageStream)
gRPC request to a `VTGate` or using the `stream * from
` SQL statement
(if using the interactive mysql command-line client you must also pass the
-`-q`/`--quick` option). If there are multiple subscribers, the messages will be
-delivered in a round-robin fashion. Note that *this is not a broadcast*; each
-message will be sent to at most one subscriber.
+`-q`/`--quick` option):
+
+```mysql
+$ mysql --quick
+mysql> SET WORKLOAD=OLAP;
+mysql> STREAM * FROM
;
+```
+
+
+
+If there are multiple subscribers, the messages will be delivered in a round-robin
+fashion. Note that *this is not a broadcast*; each message will be sent to at most
+one subscriber.
The format for messages is the same as a standard Vitess `Result` received from
a `VTGate`. This means that standard database tools that understand query results
diff --git a/content/en/docs/17.0/reference/features/recovery.md b/content/en/docs/17.0/reference/features/recovery.md
index 7d9786d50..0be939330 100644
--- a/content/en/docs/17.0/reference/features/recovery.md
+++ b/content/en/docs/17.0/reference/features/recovery.md
@@ -6,6 +6,23 @@ aliases: ['/docs/recovery/pitr','/docs/reference/pitr/']
## Point in Time Recovery
+Vitess supports incremental backup and recoveries, AKA point in time recoveries. `v17` offers restore-to-position functionality, and `v18` is slated to support restore-to-timestamp functionality in addition.
+
+Point in time recoveries are based on full and incremental backups. It is possible to recover a database to a position that is _covered_ by some backup.
+
+See [Backup Types](../../../user-guides/operating-vitess/backup-and-restore/overview/#backup-types) and [Restore Types](../../../user-guides/operating-vitess/backup-and-restore/overview/#restore-types) for an overview of incremental backups and restores.
+
+See the user guides for how to [Create an Incremental Backup](../../../user-guides/operating-vitess/backup-and-restore/creating-a-backup/#create-an-incremental-backup-with-vtctl) and how to [Restore to a position](../../../user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore/#restore-to-a-point-in-time).
+
+### Supported Databases
+- MySQL 5.7, 8.0
+
+### Notes
+
+This functionality replaces a legacy functionality, based on binlog servers and transient binary logs.
+
+## Point in Time Recovery: legacy functionality based on binlog server
+
### Supported Databases
- MySQL 8.0
diff --git a/content/en/docs/17.0/reference/features/tablet-throttler.md b/content/en/docs/17.0/reference/features/tablet-throttler.md
index 21b7d6595..0de167dc7 100644
--- a/content/en/docs/17.0/reference/features/tablet-throttler.md
+++ b/content/en/docs/17.0/reference/features/tablet-throttler.md
@@ -102,6 +102,12 @@ It is possible to _restrict_ the throttler's response to one or more apps. For e
It is _not possible_ to give an app more way than the throttler's standard behavior. That is, if the throttler is set to throttler at `5s` replication lag, it is _not possible_ to respond wih `HTTP 200` to a specific app with replication lag at `7s`.
+Vitess has a granular breakdown for its own throttler apps. Generally, the user should not change throttling configuration for internal apps. However, some of the apps are user-facing or user-initiated, and it makes sense for the user to restrict them. These apps include:
+
+- `online-ddl`: affecting all schema migrations of all strategies.
+- `vreplication`: all VReplication operations, for example: MoveTables, Reshard, Online DDL via `vitess/online` strategy.
+- `vplayer`: the VPlayer component of VReplication, which tails, processes and applies events from the bianry logs.
+- `vcopier`: the VCopier component of VReplication, which copies over the mass of table rows from source to target tables.
## Configuration
{{< warning >}}
diff --git a/content/en/docs/17.0/reference/programs/vttablet.md b/content/en/docs/17.0/reference/programs/vttablet.md
index b23b3997b..d34196110 100644
--- a/content/en/docs/17.0/reference/programs/vttablet.md
+++ b/content/en/docs/17.0/reference/programs/vttablet.md
@@ -296,7 +296,7 @@ The following global options apply to `vttablet`:
| --queryserver-config-txpool-timeout | float | query server transaction pool timeout, it is how long vttablet waits if tx pool is full (default 1) |
| --queryserver-config-txpool-waiter-cap | int | query server transaction pool waiter limit, this is the maximum number of transactions that can be queued waiting to get a connection (default 5000) |
| --queryserver-config-warn-result-size | int | query server result size warning threshold, warn if number of rows returned from vttablet for non-streaming queries exceeds this |
-| --queryserver-enable-settings-pool | boolean | Enable pooling of connections with modified system settings |
+| --queryserver-enable-settings-pool | boolean | Enable pooling of connections with modified system settings (default true) |
| --queryserver-enable-views | boolean | Enable views support in vttablet. |
| --queryserver_enable_online_ddl | boolean | Enable online DDL. (default true) |
| --redact-debug-ui-queries | boolean | redact full queries and bind variables from debug UI |
@@ -403,6 +403,7 @@ The following global options apply to `vttablet`:
| --twopc_coordinator_address | string | address of the (VTGate) process(es) that will be used to notify of abandoned transactions. |
| --twopc_enable | boolean | if the flag is on, 2pc is enabled. Other 2pc flags must be supplied. |
| --tx-throttler-config | string | Synonym to -tx_throttler_config (default "target_replication_lag_sec: 2\nmax_replication_lag_sec: 10\ninitial_rate: 100\nmax_increase: 1\nemergency_decrease: 0.5\nmin_duration_between_increases_sec: 40\nmax_duration_between_increases_sec: 62\nmin_duration_between_decreases_sec: 20\nspread_backlog_across_sec: 20\nage_bad_rate_after_sec: 180\nbad_rate_increase: 0.1\nmax_rate_approach_threshold: 0.9\n") |
+| --tx-throttler-default-priority int | int | Default query priority used by the transaction throttler if it is not specified in a query comment directive. It must be a number between 0 (highest priority) and 100 (lowest priority) (default: 100) |
| --tx-throttler-healthcheck-cells | strings | Synonym to -tx_throttler_healthcheck_cells |
| --tx-throttler-tablet-types | strings | A comma-separated list of tablet types. Only tablets of this type are monitored for replication lag by the transaction throttler. Supported types are replica and/or rdonly. (default replica) |
| --tx_throttler_config | string | The configuration of the transaction throttler as a text formatted throttlerdata.Configuration protocol buffer message (default "target_replication_lag_sec: 2\nmax_replication_lag_sec: 10\ninitial_rate: 100\nmax_increase: 1\nemergency_decrease: 0.5\nmin_duration_between_increases_sec: 40\nmax_duration_between_increases_sec: 62\nmin_duration_between_decreases_sec: 20\nspread_backlog_across_sec: 20\nage_bad_rate_after_sec: 180\nbad_rate_increase: 0.1\nmax_rate_approach_threshold: 0.9\n") |
diff --git a/content/en/docs/17.0/reference/query-serving/reserved-conn.md b/content/en/docs/17.0/reference/query-serving/reserved-conn.md
index 40b449351..bf5644a8e 100644
--- a/content/en/docs/17.0/reference/query-serving/reserved-conn.md
+++ b/content/en/docs/17.0/reference/query-serving/reserved-conn.md
@@ -39,7 +39,7 @@ What we want to highlight at the beginning is that there is a known issue when a
To solve this problem, the connection pool implementation used by vttablet has been enhanced to keep the connections with settings in the pool and not to pin the connection to the client session.
With this enhancement, we reduce the likelihood of MySQL running out of connections due to reserved connections, because the scenarios where we still need reserved connections are sharply reduced.
-Since this is a new feature, it is currently disabled by default. It can be enabled by setting the flag `--queryserver-enable-settings-pool` on vttablet.
+This is enabled by default from v17 onwards. It can be disabled by setting the flag `--queryserver-enable-settings-pool` on vttablet.
This change takes effect only for the cases when system variable changes need a reserved connection.
There are still cases like [temporary tables](#temporary-tables-and-reserved-connections) and [advisory locks](#get_lock-and-reserved-connections) where reserved connections will continue to be used.
diff --git a/content/en/docs/17.0/user-guides/configuration-advanced/comment-directives.md b/content/en/docs/17.0/user-guides/configuration-advanced/comment-directives.md
index daad76c7a..faadca599 100644
--- a/content/en/docs/17.0/user-guides/configuration-advanced/comment-directives.md
+++ b/content/en/docs/17.0/user-guides/configuration-advanced/comment-directives.md
@@ -119,3 +119,15 @@ As shown above, the metrics being instrumented this way are `vttablet_query_coun
If the query lacks the `WORKLOAD_NAME` directive, the corresponding label in the metric will have the value of an empty
string. If `vttablet` is not started with `--enable-per-workload-table-metrics`, metrics are emitted without the
workload label (e.g. `vttablet_query_counts{plan="Select",table="customer"}`.
+
+### Priority (`PRIORITY`)
+
+Specifies the priority associated with the execution of this query, as a number between 0 (highest priority) and 100
+(lowest priority). The priority is used by the transaction throttler (see `--tx-throttler-...` and `-enable-tx-throttler`
+flags in the `vttablet` [documentation](../../reference/programs/vttablet.md))) to determine whether a particular query
+should be throttled. If the transaction throttler determines that a query may need to be throttled, it will throttle it
+with a probability equal to the provided query priority. This allows avoiding high business impact queries from being
+throttled (by setting their priority to `0`) while letting less business critical ones continue to be throttled (by
+setting their priority to more than `0`).
+
+Notice that this directive has no effect if the transaction throttler is not enabled.
diff --git a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore.md b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore.md
index 5ab721ed7..6ab431628 100644
--- a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore.md
+++ b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore.md
@@ -4,7 +4,8 @@ weight: 3
aliases: ['/docs/user-guides/backup-and-restore/']
---
-## Restoring a backup
+Restores can be done automatically by way of seeding/bootstrapping new tablets, or they can be invoked manually on a tablet to restore a full backup or do a point-in-time recovery.
+## Auto restoring a backup on startup
When a tablet starts, Vitess checks the value of the `--restore_from_backup` command-line flag to determine whether to restore a backup to that tablet. Restores will always be done with whichever engine was used to create the backup.
@@ -32,3 +33,41 @@ Bootstrapping a new tablet is almost identical to restoring an existing tablet.
```
The bootstrapped tablet will restore the data from the backup and then apply changes, which occurred after the backup, by restarting replication.
+
+## Manual restore
+
+A manual restore is done on a specific tablet. The tablet's MySQL server is shut down and its data is wiped out.
+
+### Restore a full backup
+
+To restore the tablet from the most recent full backup, run:
+
+```shell
+vtctldclient --server=: RestoreFromBackup
+```
+
+Example:
+
+```shell
+vtctldclient --server localhost:15999 --alsologtostderr RestoreFromBackup zone1-0000000101
+```
+
+If successful, the tablet's MySQL server rejoins the shard's replication stream, to eventually captch up and be able to serve traffic.
+
+### Restore to a point-in-time
+
+`v17` supports incremental restore, or restoring to a specific _position_:
+
+```shell
+vtctlclient -- RestoreFromBackup --restore_to_pos
+```
+
+Example:
+
+```shell
+vtctlclient -- RestoreFromBackup --restore_to_pos "MySQL56/0d7aaca6-1666-11ee-aeaf-0a43f95f28a3:1-60" zone1-0000000102
+```
+
+This restore method assumes backups have been taken that cover the specified position. The restore process will first determine a restore path: a sequence of backups, starting with a full backup followed by zero or more incremental backups, that when combined, include the specified position. See more on [Restore Types](../overview/#restore-types) and on [Taking Incremental Backup](../creating-a-backup/#create-an-incremental-backup-with-vtctl).
+
+`v18` will supports restore to a given timestamp.
diff --git a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/creating-a-backup.md b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/creating-a-backup.md
index 665fba502..ff4ffaaba 100644
--- a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/creating-a-backup.md
+++ b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/creating-a-backup.md
@@ -4,6 +4,12 @@ weight: 2
aliases: ['/docs/user-guides/backup-and-restore/']
---
+## Choosing the backup type
+
+As described in [Backup types](../overview/#backup-types), you choose to run a full Backup (the default) or an incremental Backup.
+
+Full backups will use the backup engine chosen in the tablet's [configuration](#configuration). Incremental backups will always copy MySQL's binary logs, irrespective of the configured backup engine.
+
## Using xtrabackup
The default backup implementation is `builtin`, however we strongly recommend using the `xtrabackup` engine as it is more robust and allows for non-blocking backups. Restores will always be done with whichever engine was used to create the backup.
@@ -75,11 +81,11 @@ I0310 12:49:32.279773 215835 backup.go:163] I0310 20:49:32.279485 xtrabackupeng
To continue with risk: Set `--xtrabackup_backup_flags=--no-server-version-check`. Note this occurs when your MySQL server version is technically unsupported by `xtrabackup`.
-## Create backups with vtctl
+## Create a full backup with vtctl
__Run the following vtctl command to create a backup:__
-``` sh
+```sh
vtctldclient --server=: Backup
```
@@ -89,10 +95,31 @@ If the engine is `xtrabackup`, the tablet can continue to serve traffic while th
__Run the following vtctl command to backup a specific shard:__
-``` sh
+```sh
vtctldclient --server=: BackupShard [--allow_primary=false]
```
+## Create an incremental backup with vtctl
+
+An incremental backup requires additional information: the point from which to start the backup. An incremental backup is taken by supplying `--incremental_from_pos` to the `Backup` command. The argument may either indicate a valid position, or the value `auto`. Examples:
+
+```sh
+vtctlclient -- Backup --incremental_from_pos="MySQL56/0d7aaca6-1666-11ee-aeaf-0a43f95f28a3:1-53" zone1-0000000102
+
+vtctlclient -- Backup --incremental_from_pos="auto" zone1-0000000102
+```
+
+When `--incremental_from_pos="auto"`, Vitess chooses the position of the last successful backup as the starting point for the incremental backup. This is a convenient way to ensure a sequence of contiguous incremental backups.
+
+An incremental backup backs up one or more MySQL binary log files. These binary log files may begin with the requested position, or with an earlier position. They will necessarily include the requested position. When the incremental backup begins, Vitess rotates the MySQL binary logs on the tablet, so that it does not back up an active log file.
+
+An incremental backup fails in these scenarios:
+
+- It is unable to find binary log files that covers the requested position. This can happen if the binary logs are purged earlier than the incremental backup was taken. It essentially means there's a gap in the changelog events. **Note** that while on one tablet the binary logs may be missing, another tablet may still have binary logs that cover the requested position.
+- There is no change to the database since the requested position, i.e. the GTID position has not changed since.
+
+`v17` only supports `--incremental_from_pos` in the `Backup` command, not in `BackupShard`. Also, only `vtctlclient` supports the flag, where `vtctldclient` does not. `v18` is expected to support incremental backups for `BackupShard` and for `vtctldclient`.
+
## Backing up Topology Server
The Topology Server stores metadata (and not tablet data). It is recommended to create a backup using the method described by the underlying plugin:
diff --git a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/overview.md b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/overview.md
index 1f7e98996..d7ac333d1 100644
--- a/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/overview.md
+++ b/content/en/docs/17.0/user-guides/operating-vitess/backup-and-restore/overview.md
@@ -26,6 +26,36 @@ The engine is the techology used for generating the backup. Currently Vitess has
* Builtin: Shutdown an instance and copy all the database files (default)
* XtraBackup: An online backup using Percona's [XtraBackup](https://www.percona.com/software/mysql-database/percona-xtrabackup)
+### Backup types
+
+Vitess supports full backups as well as incremental backups, and their respective counterparts full restores and point-in-time restores.
+
+* A full backup contains the entire data in the database. The backup represents a consistent state of the data, i.e. it is a snapshot of the data at some point in time.
+* An incremental backup contains a changelog, or a transition of data from one state to another. Vitess implements incremental backups by making a copy of MySQL binary logs.
+
+Generally speaking and on most workloads, the cost of a full backup is higher, and the cost of incremental backups is lower. The time it takes to create a full backup is significant, and it is therefore impractical to take full backups in very small intervals. Moreover, a full backup consumes the disk space needed for the entire dataset. Incremental backups, on the other hand, are quick to run, and have very little impact, if any, to the running servers. They only contain the changes in between two points in time, and on most workloads are more compact.
+
+Full and incremental backups are expected to be interleaved. For example: one would create a full backup once per day, and incremental backups once per hour.
+
+Full backups are simply states of the database. Incremental backups, however, need to start with some point and end with some point. The common practice is for an incremental backup to continue from the point of the last good backup, which can be a full or incremental backup. An inremental backup in Vitess ends at the point in time of execution.
+
+The identity of the tablet on which a full backup or an incremental backup is taken is immaterial. It is possible to take a full backup on one tablet and incremental backups on another. It is possible to take full backups on two different tablets. It is also possible to take incremental backups, independently, on two different tablets, even though the contents of those incremental backups overlaps. Vitess uses MySQL GTID sets to determine positioning and prune duplicates.
+
+### Restores
+
+Restores are the counterparts of backups. A restore uses the engine utilized to create a backup. One may run a restore from a full backup, or a point-in-time restore (PITR) based on additional incremental backups.
+
+A Vitess restore operates on a tablet. The restore process completely wipes out the data in the tablet's MySQL server and repopulates the server with the backup(s) data. The MySQL server is shutdown during the process. As a safety mechanism, Vitess by default prevents a restore onto a `PRIMARY` tablet. Any non-`PRIMARY` tablet is otherwise eligible to restore.
+
+### Restore Types
+
+Vitess supports full restores and incremental (AKA point-in-time) restores. The two serve different purposes.
+
+* A full restore loads the dataset from a full backup onto a non-`PRIMARY` tablet. Once the data is loaded, the restore process starts the MySQL service and makes it join the replication stream. It is expected that a freshly restored server will lag behind the shard's `PRIMARY` for a period of time.
+ The full restore flow is useful for seeding new replica tablets. It may also be used to fix replicas that have been corrupted.
+* An incremental, or a point-in-time restore, restores a tablet/MySQL up to a specific position or time. This is done by first loading a full backup dataset, followed by applying the changelog captured in zero or more incremental backups. Once that is complete, the tablet type is set to `DRAINED` and the tablet does _not_ join the replication stream.
+ The common purpose of point-in-time restore is to recover data from an accidental write/deletion. If the database administrator knows at about what time the accidental write took place, they can restore a replica tablet to a point in time shortly before the accidental write. Since the server does not join the replication stream, its data then remains static, and the administrator may review or copy the data as they please. Finally, it is then possible to change the tablet type back to `REPLICA` and have it join the shard's replication.
+
## Vtbackup, VTTablet and Vtctld
Vtbackup, VTTablet, and Vtctld may all participate in backups and restores.
diff --git a/content/en/docs/17.0/user-guides/vschema-guide/advanced-vschema.md b/content/en/docs/17.0/user-guides/vschema-guide/advanced-vschema.md
index 440d1bb82..1429063a3 100644
--- a/content/en/docs/17.0/user-guides/vschema-guide/advanced-vschema.md
+++ b/content/en/docs/17.0/user-guides/vschema-guide/advanced-vschema.md
@@ -46,7 +46,7 @@ A reference table should not have any vindex, and is defined in the VSchema as a
#### Source Tables
-Vitess will optimize reference tables routing when joined to a table within the same keyspace. Additional routing optimizations can be enabled by specifying the `source` of a reference table. When a reference table specifies a `source` table:
+Vitess will optimize reference table routing when joined to a table within the same keyspace. Additional routing optimizations can be enabled by specifying the `source` of a reference table. When a reference table specifies a `source` table:
* A `SELECT ... JOIN` (or equivalent `SELECT ... WHERE`) will try to route the
query to the keyspace of the table to which the reference (or source) table
@@ -70,7 +70,6 @@ For example:
There are some constraints on `source`:
- * It must be a keyspace-qualified table name, e.g. `unsharded_ks.zip_detail`.
* It must refer to an existing table in an existing keyspace.
* It must refer to a table in a different keyspace.
* It must refer to a table in an unsharded keyspace.
diff --git a/content/en/docs/18.0/get-started/local-brew.md b/content/en/docs/18.0/get-started/local-brew.md
index 7b55955fd..3d752fa8d 100644
--- a/content/en/docs/18.0/get-started/local-brew.md
+++ b/content/en/docs/18.0/get-started/local-brew.md
@@ -1,7 +1,7 @@
---
title: Local Install via Homebrew
description: Instructions for using Vitess on your macOS machine for testing purposes
-weight: 2
+weight: 3
featured: true
aliases: ['/docs/tutorials/local-brew/']
---
diff --git a/content/en/docs/18.0/get-started/local-docker.md b/content/en/docs/18.0/get-started/local-docker.md
index 8eaecff3f..d4bf43fd5 100644
--- a/content/en/docs/18.0/get-started/local-docker.md
+++ b/content/en/docs/18.0/get-started/local-docker.md
@@ -1,11 +1,15 @@
---
title: Local Install via Docker
description: Instructions for using Vitess on your machine for testing purposes
-weight: 1
-featured: true
+weight: 5
+featured: false
aliases: ['/docs/tutorials/local-docker/']
---
+{{< warning >}}
+This guide will only work on x86_64/amd64 based machines.
+{{ warning >}}
+
This guide illustrates how to run a local testing Vitess setup via Docker. The Vitess environment is identical to the [local setup](../local/), but without having to install software on one's host other than Docker.
## Check out the vitessio/vitess repository
diff --git a/content/en/docs/18.0/get-started/operator.md b/content/en/docs/18.0/get-started/operator.md
index 8e17c183f..55112f490 100644
--- a/content/en/docs/18.0/get-started/operator.md
+++ b/content/en/docs/18.0/get-started/operator.md
@@ -1,6 +1,6 @@
---
title: Vitess Operator for Kubernetes
-weight: 3
+weight: 1
featured: true
aliases: ['/docs/tutorials/kubernetes/','/user-guide/sharding-kubernetes.html', '/docs/get-started/scaleway/','/docs/get-started/kubernetes/']
---
diff --git a/content/en/docs/18.0/get-started/vttestserver-docker-image.md b/content/en/docs/18.0/get-started/vttestserver-docker-image.md
index 46924ef98..e64739f6a 100644
--- a/content/en/docs/18.0/get-started/vttestserver-docker-image.md
+++ b/content/en/docs/18.0/get-started/vttestserver-docker-image.md
@@ -1,6 +1,6 @@
---
title: Vttestserver Docker Image
-weight: 4
+weight: 10
featured: true
aliases: ['/docs/tutorials/vttestserver/']
---
@@ -51,20 +51,20 @@ At this point, you should have a docker image named `vitess/vttestserver:mysql57
The docker image expects some of the environment variables to be set to function properly. The following table lists all the environment variables available along with their usages.
-| Environment variable | Required | Use |
-| -- | -- | -- |
-| *KEYSPACES* | yes | Specifies the names of the keyspaces to be created as a comma separated value. |
-| *NUM_SHARDS* | yes | Specifies the number of shards in each keyspace. It is a comma separated value as well, read in conjunction with the KEYSPACES. |
-| *PORT* | yes | The starting of the port addresses that vitess will use to register its components like vtgate, etc. |
-| *MYSQL_MAX_CONNECTIONS* | no | Maximum number of connections that the MySQL instance will support. If unspecified, it defaults to 1000. |
-| *MYSQL_BIND_HOST* | no | Which host to bind the MySQL listener to. If unspecified, it defaults to `127.0.0.1`. |
-| *MYSQL_SERVER_VERSION* | no | MySQL server version to advertise. If unspecified, it defaults to `8.0.31-vitess` or `5.7.9-vitess` according to the version of vttestserver run. |
-| *CHARSET* | no | Default charset to use. If unspecified, it defaults to `utf8mb4`. |
-| *FOREIGN_KEY_MODE* | no | This is to provide how to handle foreign key constraint in create/alter table. Valid values are: allow (default), disallow. |
-| *ENABLE_ONLINE_DDL* | no | Allow users to submit, review and control Online DDL. Valid values are: true (default), false. |
-| *ENABLE_DIRECT_DDL* | no | Allow users to submit direct DDL statements. Valid values are: true (default), false. |
-| *PLANNER_VERSION* | no | Sets the default planner to use when the session has not changed it. Valid values are: Gen4 (default), v3, Gen4Greedy and Gen4Fallback. Gen4Fallback tries the new gen4 planner and falls back to the V3 planner if the gen4 fails. |
-| *TABLET_REFRESH_INTERVAL* | no | Interval at which vtgate refreshes tablet information from topology server. |
+| Environment variable | Required | Use |
+|---------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------|
+| *KEYSPACES* | yes | Specifies the names of the keyspaces to be created as a comma separated value. |
+| *NUM_SHARDS* | yes | Specifies the number of shards in each keyspace. It is a comma separated value as well, read in conjunction with the KEYSPACES. |
+| *PORT* | yes | The starting of the port addresses that vitess will use to register its components like vtgate, etc. |
+| *MYSQL_MAX_CONNECTIONS* | no | Maximum number of connections that the MySQL instance will support. If unspecified, it defaults to 1000. |
+| *MYSQL_BIND_HOST* | no | Which host to bind the MySQL listener to. If unspecified, it defaults to `127.0.0.1`. |
+| *MYSQL_SERVER_VERSION* | no | MySQL server version to advertise. If unspecified, it defaults to `8.0.31-vitess` or `5.7.9-vitess` according to the version of vttestserver run. |
+| *CHARSET* | no | Default charset to use. If unspecified, it defaults to `utf8mb4`. |
+| *FOREIGN_KEY_MODE* | no | This is to provide how to handle foreign key constraint in create/alter table. Valid values are: allow (default), disallow. |
+| *ENABLE_ONLINE_DDL* | no | Allow users to submit, review and control Online DDL. Valid values are: true (default), false. |
+| *ENABLE_DIRECT_DDL* | no | Allow users to submit direct DDL statements. Valid values are: true (default), false. |
+| *PLANNER_VERSION* | no | Sets the default planner to use when the session has not changed it. Valid values are: Gen4, Gen4Greedy, Gen4Left2Right. |
+| *TABLET_REFRESH_INTERVAL* | no | Interval at which vtgate refreshes tablet information from topology server. |
Environment variables in docker can be specified using the `-e` aka `--env` flag.
diff --git a/content/en/docs/18.0/reference/backup-and-restore/metrics.md b/content/en/docs/18.0/reference/backup-and-restore/metrics.md
index 1645642f7..ac83023ed 100644
--- a/content/en/docs/18.0/reference/backup-and-restore/metrics.md
+++ b/content/en/docs/18.0/reference/backup-and-restore/metrics.md
@@ -50,11 +50,11 @@ _restore_duration_seconds_ times the duration of a restore. This metric is depre
Vtbackup exports some metrics which are not available elsewhere.
-#### DurationByPhaseSeconds
+#### Phase
Vtbackup fetches the last backup, restores it to an empty mysql installation, replicates recent changes into that installation, and then takes a backup of that installation.
-_DurationByPhaseSeconds_ exports timings for these individual phases.
+_Phase_ a binary-valued gauge that reports the currently active phase.
@@ -91,11 +91,11 @@ _DurationByPhaseSeconds_ exports timings for these individual phases.
"BackupEngine.Builtin.Destination:Close": 17144630,
"BackupStorage.File.File:Write": 10743169
},
- "DurationByPhaseSeconds": {
- "InitMySQLd": 2,
- "RestoreLastBackup": 6,
- "CatchUpReplication": 1,
- "TakeNewBackup": 4
+ "Phase": {
+ "InitialBackup": 0,
+ "RestoreLastBackup": 0,
+ "CatchUpReplication": 0,
+ "TakeNewBackup": 0
},
"RestoreBytes": {
"BackupEngine.Builtin.Source:Read": 1095,
@@ -131,6 +131,6 @@ _DurationByPhaseSeconds_ exports timings for these individual phases.
Some notes to help understand these metrics:
* `BackupBytes["BackupStorage.File.File:Write"]` measures how many bytes were read from disk by the `file` Backup Storage implementation during the backup phase.
- * `DurationByPhaseSeconds["CatchUpReplication"]` measures how long it took to catch-up replication after the restore phase.
- * `DurationByPhaseSeconds["RestoreLastBackup"]` measures to the duration of the restore phase.
+ * `Phase["CatchUpReplication"]` reports whether the catch-up replication phase is active (1) or not (0).
+ * `Phase["RestoreLastBackup"]` reports whether the restore last backup phase is active (1) or not (0).
* `RestoreDurationNanoseconds["-.-.Restore"]` also measures to the duration of the restore phase.
diff --git a/content/en/docs/18.0/reference/compatibility/gen4-and-v3-compatibility.md b/content/en/docs/18.0/reference/compatibility/gen4-and-v3-compatibility.md
deleted file mode 100644
index fb61ab653..000000000
--- a/content/en/docs/18.0/reference/compatibility/gen4-and-v3-compatibility.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Gen4 and V3 Compatibility
-weight: 2
-aliases: ['/docs/reference/gen4-against-v3/', '/docs/reference/gen4-and-v3-compatibility/']
----
-
-The latest version of the Vitess query planner, `Gen4`, changes most of the planner's internals.
-To ensure `Gen4` produces plans that, once executed, give us the same results as what `V3` would do, we have developed
-a small test tool that runs queries using both `Gen4` and `V3` planners and compare their results. If the results we got are different
-from the two planners, the query will fail and the difference will be printed in VTGate's logs as a warning.
-
-This tool is enabled by the use of a new planner: `Gen4CompareV3`, to use it, we must start VTGate with the `--planner-version`
-flag set to `Gen4CompareV3`. Once set, new queries will be tested against both `Gen4` and `V3`.
diff --git a/content/en/docs/18.0/reference/compatibility/mysql-compatibility.md b/content/en/docs/18.0/reference/compatibility/mysql-compatibility.md
index c9bdff72b..04d19f50c 100644
--- a/content/en/docs/18.0/reference/compatibility/mysql-compatibility.md
+++ b/content/en/docs/18.0/reference/compatibility/mysql-compatibility.md
@@ -125,16 +125,26 @@ Vitess does not yet support Window Functions or Common Table Expressions.
### Killing running queries
-Vitess does not yet support killing running queries via the `KILL` command through VTGate.
-Currently, there exists a comment directive [QUERY_TIMEOUT_MS](../../../user-guides/configuration-advanced/comment-directives/#query-timeouts-query_timeout_ms) that can be set to reduce the query timeout which will ensure that the query either return result or abort within that time.
+In v18, Vitess introduced the ability to terminate running queries using the [`KILL` command](https://dev.mysql.com/doc/refman/8.0/en/kill.html) through VTGate.
+To execute a "kill connection" or "kill query" statement, the client needs to establish a new connection.
+This behavior is similar to when a user on the MySQL shell client terminates a command by pressing ctrl+c.
-Vitess does have strict query timeouts for OLTP workloads (see below). If you need to kill a query, you can connect to the underlying MySQL shard instance and run `KILL` from there.
+The [RFC](https://github.com/vitessio/vitess/issues/13438) highlights the current limitation of the `Kill statement` support.
+
+Alternatively,
+- [query_timeout_ms](../../../user-guides/configuration-advanced/comment-directives/#query-timeouts-query_timeout_ms) query comment directive can be set to define a query timeout. This ensures that the query either returns a result or aborts within the specified time.
+- [mysql_server_query_timeout](../../programs/vtgate/) command-line flag can be set on VTGate to establish a default timeout.
+
+Vitess does have strict query timeouts for OLTP workloads (see below).
### Workload
-By default, Vitess sets some intentional restrictions on the execution time and number of rows that a query can return. This default workload mode is called `OLTP`. This can be disabled by setting the workload to `OLAP`:
+By default, Vitess applies specific limitations on the execution time and the number of rows a query can return.
+These limitations can be modified by adjusting the parameters like `queryserver-config-query-timeout`, `queryserver-config-transaction-timeout` and more in [vttablet](../../programs/vttablet/).
+This default workload mode is referred as `OLTP`. This can be disabled by switching to `OLAP` mode by executing the following SQL statement:
+
```sql
-SET workload='olap'
+set workload = olap;
```
### SELECT ... INTO Statement
diff --git a/content/en/docs/18.0/reference/features/messaging.md b/content/en/docs/18.0/reference/features/messaging.md
index d0dc86136..8724ae323 100644
--- a/content/en/docs/18.0/reference/features/messaging.md
+++ b/content/en/docs/18.0/reference/features/messaging.md
@@ -122,12 +122,22 @@ Messages can also be created to be sent in the future:
## Receiving messages
-Processes can subscribe to receive messages by sending a `MessageStream`
+Processes can subscribe to receive messages by sending a [`MessageStream`](https://pkg.go.dev/vitess.io/vitess/go/vt/vtgate#Executor.MessageStream)
gRPC request to a `VTGate` or using the `stream * from
` SQL statement
(if using the interactive mysql command-line client you must also pass the
-`-q`/`--quick` option). If there are multiple subscribers, the messages will be
-delivered in a round-robin fashion. Note that *this is not a broadcast*; each
-message will be sent to at most one subscriber.
+`-q`/`--quick` option):
+
+```mysql
+$ mysql --quick
+mysql> SET WORKLOAD=OLAP;
+mysql> STREAM * FROM
;
+```
+
+
+
+If there are multiple subscribers, the messages will be delivered in a round-robin
+fashion. Note that *this is not a broadcast*; each message will be sent to at most
+one subscriber.
The format for messages is the same as a standard Vitess `Result` received from
a `VTGate`. This means that standard database tools that understand query results
diff --git a/content/en/docs/18.0/reference/features/recovery.md b/content/en/docs/18.0/reference/features/recovery.md
index 7d9786d50..0be939330 100644
--- a/content/en/docs/18.0/reference/features/recovery.md
+++ b/content/en/docs/18.0/reference/features/recovery.md
@@ -6,6 +6,23 @@ aliases: ['/docs/recovery/pitr','/docs/reference/pitr/']
## Point in Time Recovery
+Vitess supports incremental backup and recoveries, AKA point in time recoveries. `v17` offers restore-to-position functionality, and `v18` is slated to support restore-to-timestamp functionality in addition.
+
+Point in time recoveries are based on full and incremental backups. It is possible to recover a database to a position that is _covered_ by some backup.
+
+See [Backup Types](../../../user-guides/operating-vitess/backup-and-restore/overview/#backup-types) and [Restore Types](../../../user-guides/operating-vitess/backup-and-restore/overview/#restore-types) for an overview of incremental backups and restores.
+
+See the user guides for how to [Create an Incremental Backup](../../../user-guides/operating-vitess/backup-and-restore/creating-a-backup/#create-an-incremental-backup-with-vtctl) and how to [Restore to a position](../../../user-guides/operating-vitess/backup-and-restore/bootstrap-and-restore/#restore-to-a-point-in-time).
+
+### Supported Databases
+- MySQL 5.7, 8.0
+
+### Notes
+
+This functionality replaces a legacy functionality, based on binlog servers and transient binary logs.
+
+## Point in Time Recovery: legacy functionality based on binlog server
+
### Supported Databases
- MySQL 8.0
diff --git a/content/en/docs/18.0/reference/features/tablet-throttler.md b/content/en/docs/18.0/reference/features/tablet-throttler.md
index 21b7d6595..67c73399d 100644
--- a/content/en/docs/18.0/reference/features/tablet-throttler.md
+++ b/content/en/docs/18.0/reference/features/tablet-throttler.md
@@ -45,7 +45,7 @@ In addition, the primary tablet is responsible for the overall health of the clu
- The throttler confirms it is still the primary tablet for its shard.
- Every `10sec`, the throttler uses the topology server to refresh the shard's tablets list.
-- The throttler probes all `REPLICA` tablets for their replication lag. This is done by querying the `_vt.heartbeat` table.
+- The throttler probes all `REPLICA` tablets (or other types of tablets, see [Configuration](#configuration)) for their own throttler metrics. This is done via gRPC.
- The throttler begins in dormant probe mode. As long as no application or client is actually looking for metrics, it probes the servers at multi-second intervals.
- When applications check for throttle advice, the throttler begins probing servers in subsecond intervals. It reverts to dormant probe mode if no requests are made in the duration of `1min`.
- The throttler aggregates the last probed values from all relevant tablets. This is _the cluster's metric_.
@@ -100,68 +100,42 @@ It is possible for the throttler to respond differently -- to some extent -- to
It is possible to _restrict_ the throttler's response to one or more apps. For example, it's possible to completely throttle "vreplication" while still responding `HTTP 200` to other apps. This is typically used to give way or precedence to one or two apps, or otherwise to further reduce the incoming load from a specific app.
-It is _not possible_ to give an app more way than the throttler's standard behavior. That is, if the throttler is set to throttler at `5s` replication lag, it is _not possible_ to respond wih `HTTP 200` to a specific app with replication lag at `7s`.
+Starting `v18`, it is also possible to _exempt_ an app from throttling, even if the throttler is otherwise rejecting requests with metrics beyond the threshold. This is an advanced feature that users should treat with great care, and only in situations where they absolutely must give a specific workflow/migration the highest priority above all else. See discussion in examples, below.
## Configuration
{{< warning >}}
-Configuration in v16 differs from v15 and earlier. Please note the different configuration options for your version.{{< /warning >}}
+Per-tablet throttler configuration, as used in `v15` and supported in `v16`, is no longer supported in `v18`.{{< /warning >}}
-`v16` is backwards compliant with `v15` and still default to the `v15` configuration. We illustrate both configurations so that you understand how to transition from one to the other.
+Throttler configuration is found in the [local topology server](../../../concepts/topology-service/). There is one configuration per keyspace. All shards and all tablets in all cells have the same throttler configuration: they are all enabled or disabled, and all share the same threshold or custom query. Since configuration is stored outside the tablet, it survives tablet restarts.
-### v17 and forward
+`v16` introduced a new opt-in `vttablet` flag, `--throttler-config-via-topo`, and the flag defaulted `false`. In `v17` the flag now defaulted to `true`. In `v18`, the flag is not used anymore, and the tablet looks for configuration in the topology server, and will watch and apply any changes made there.
-In `v17`, throttler configuration is found in the [local topology server](../../../concepts/topology-service/). There is one configuration per keyspace. All shards and all tablets in all cells have the same throttler configuration: they are all enabled or disabled, and all share the same threshold or custom query. Since configuration is stored outside the tablet, it survives tablet restarts.
+The following flags are deprecated (and will be removed in `v19`):
-`v16` introduced a new opt-in `vttablet` flag, `--throttler-config-via-topo`. In `v16` this flag defaulted `false`. In `v17` this flag now defaults `true`. With `--throttler-config-via-topo` set, the tablet will look for configuration in the topology server, and will watch and apply any changes made there.
-
-When the flag `--throttler-config-via-topo` is set (and it is set by default), the following flags are ignored even if specified. These flags are scheduled to be removed in `v18`and `v19`:
-
-- `--enable_lag_throttler`
- `--throttle_threshold`
- `--throttle_metrics_query`
- `--throttle_metrics_threshold`
- `--throttle_check_as_check_self`
+- `--throttler-config-via-topo`
+The following flag was removed:
+
+- `--enable_lag_throttler`
Updating the throttler config is done via `vtctlclient` or `vtctldclient`. For example:
```sh
$ vtctlclient -- UpdateThrottlerConfig --enable --threshold 3.0 commerce
$ vtctldclient UpdateThrottlerConfig --disable commerce
+$ vtctldclient UpdateThrottlerConfig --throttle-app="vreplication" --throttle-app-ratio 0.5 --throttle-app-duration "30m" commerce
```
See [vtctl UpdateThrottlerConfig](../../programs/vtctl/throttler#updatethrottlerconfig).
-If you are still using the `v15` flags, we recommend that you transition to the new throttler configuration scheme: first populate topo with a new throttler configuration via `UpdateThrottlerConfig`. At the very least, set a `--threshold`. You likely also want to `--enable`. Then, reconfigure `vttablet`s with `--throttler-config-via-topo`, and restart them.
-
-
-### v16 and before
-
-In earlier versions, the throttler is configured per tablet. Each tablet can have throttler enabled/disabled independently, or have different thresholds.
-
-`v17` still supports the per-tablet configuration if you specify `--throttler-config-via-topo=false`, but this will be removed in `v18`.
-
-- The throttler is **disabled** by default. Use the `vttablet` option `--enable-lag-throttler` to enable the throttler.
- When the throttler is disabled, it still serves `/throttler/check` and `/throttler/check-self` API endpoints, and responds with `HTTP 200 OK` to all requests.
- When the throttler is enabled, it implicitly also runs heartbeat injections.
-- Use the `vttablet` flag `--throttle_threshold` to set a lag threshold value. The default threshold is `1sec` and is set upon tablet startup. For example, to set a half-second lag threshold, use the flag `--throttle_threshold=0.5s`.
-- To set the tablet types that the throttler queries for lag, use the `vttablet` flag `--throttle_tablet_types="replica,rdonly"`. The default tablet type is `replica`; this type is always implicitly included in the tablet types list. You may add any other tablet type. Any type not specified is ignored by the throttler.
-- To override the default lag evaluation, and measure a different metric, use `--throttle_metrics_query`. The query must be either of these forms:
- - `SHOW GLOBAL STATUS LIKE ''`
- - `SHOW GLOBAL VARIABLES LIKE ''`
- - `SELECT FROM ...`, expecting single column, single row result
-- To override the throttle threshold, use `--throttle_metrics_threshold`. Floating point values are accepted.
-- Use `--throttle_check_as_check_self` to implicitly reroute any `/throttler/check` call into `/throttler/check-self`. This makes sense when the user supplies a custom query, and where the user wishes to throttle writes to the cluster based on the primary tablet's health, rather than the overall health of the cluster.
+If you are still using the `v15` flags, you will have to transition to the new throttler configuration scheme: first populate topo with a new throttler configuration via `UpdateThrottlerConfig`. At the very least, set a `--threshold`. You likely also want to `--enable`. Then, reconfigure `vttablet`s with `--throttler-config-via-topo`, and restart them.
-An example for custom query & threshold setup, using the MySQL metrics `Threads_running` (number of threads actively executing a query at a given time) on the primary, might look like:
-
-```shell
-$ vttablet
- --throttle_metrics_query "show global status like 'threads_running'"
- --throttle_metrics_threshold 150
- --throttle_check_as_check_self
-```
+The list of tablet types included in the throttler's logic is dictated by `vttablet --throttle_tablet_types`. The value is a comma delimited list of tablet types. The default value is `"replica"`. You may, for example, set it to be `"replica,rdonly"`.
## Heartbeat configuration
@@ -183,7 +157,7 @@ Applications use these API endpoints:
#### Examples:
-- `gh-ost` uses this throttler endpoint: `/throttler/check?app=gh-ost&p=low`
+- `gh-ost` uses this throttler endpoint: `/throttler/check?app=online-ddl:gh-ost:&p=low`
- A data backfill application will identify as such, and use _normal_ priority: `/throttler/check?app=my_backfill` (priority not indicated in URL therefore assumed to be _normal_)
- An app reading a massive amount of data directly from a replica tablet will use `/throttler/check-self?app=my_data_reader`
@@ -195,32 +169,123 @@ A `HEAD` request is sufficient. A `GET` request also provides a `JSON` output. F
In the first two above examples we can see that the tablet is configured to throttle at `1sec`
-### Instructions
+### Control
-- `/throttler/throttle-app?app=&duration=[&ratio=][&p=low]`: instructs the throttler to begin throttling requests from given app.
- - A mandatory `duration` value auto expires the throttling after indicated time. You may specify these units: `s` (seconds), `m` (minutes), `h` (hours) or combinations. Example values: `90s`, `30m`, `1h`, `1h30m`, etc.
- - An optional `ratio` value indicates the throttling intensity, ranging from `0` (no throttling at all) to `1.0` (the default, full throttle).
- With a value of `0.3`, for example, `3` out of `10`, on average, checks by the app, are flat out denied, regardless of present metrics and threshold. The remaining `7` out of `10` checks, will get a response that is based on the actual metrics and threshold (thereby, thay may be approved, or they may be rejected).
- - Applications may also declare themselves to be _low priority_ via `?p=low` param. Managed online schema migrations (`gh-ost`, `pt-online-schema-change`) do so, as does the table purge process.
-- `/throttler/unthrottle-app?app=`: instructs the throttler to stop throttling for the given app. This removes any previous throttling instruction for the app. the throttler still reserves the right to throttle the app based on cluster status.
+All controls below apply to a given keyspace (`commerce` in the next examples). All of the keyspace's tablets, in all shards and cells, are affected.
-#### Examples:
+Enable the throttler:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --enable commerce
+```
+
+Disable the throttler
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --disable commerce
+```
-- `/throttler/throttle-app?app=vreplication&duration=2h` rejects all requests made by `vreplication` for the next `2` hours, after which the app is unthrottled.
-- `/throttler/throttle-app?app=vreplication&duration=2h&ratio=0.25` rejects on average 1 out of 4 requests made by `vreplication` for the next `2` hours, after which the app is unthrottled.
+Enable and also set a replication lag threshold:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --enable --threshold 15.0 commerce
+```
-{{< info >}}
-If using `curl` from a shell prompt/script, make sure to enclose URL with quotes, like so:
+Set a custom query and a matching threshold. Does not affect enabled state:
+```sh
+$ vtctldclient UpdateThrottlerConfig --custom-query "show global status like 'threads_running'" --threshold 40 --check-as-check-self commerce
```
-$ curl -s 'http://localhost:15000/throttler/throttle-app?app=test&ratio=0.25'
+
+In the above, we use `--check-as-check-self` because we want the shard's `PRIMARY`'s metric (concurrent threads) to be the throttling factor.
+
+Return to default throttling metric (replication lag):
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --custom-query "" --threshold 15.0 --check-as-check-shard commerce
+```
+
+In the above, we use `--check-as-check-self` because we want the shard's replicas metric (lag) to be the throttling factor.
+
+Throttle a specific app, `vreplication`, so that `80%` of its eligible requests are denied (slowing it down to `20%` potential speed), auto-expiring after `30` minutes:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --throttle-app "vreplication" --throttle-app-ratio=0.8 --throttle-app-duration "30m" commerce
+```
+
+Unthrottle an app:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --unthrottle-app "vreplication" commerce
+```
+
+An altrnative method to unthrottle is to set a throttling rule that expires immediately:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --throttle-app "vreplication" --throttle-app-duration 0 commerce
+```
+
+Fully throttle all Online DDL (schema changes) for the next hour and a half:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --throttle-app "online-ddl" --throttle-app-ratio=1.0 --throttle-app-duration "1h30m" commerce
+```
+
+Exempt `vreplication` from being throttled, even if otherwise the metrics are past the throttler threshold (e.g. replication lag is high):
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --throttle-app "vreplication" --throttle-app-duration "30m" --throttle-app-exempt commerce
+```
+
+Use the above with great care. Exempting one app can cause starvation to all other apps. Consider, for example, the common use case where throttling is based on replication lag. By exempting `vreplication`, it is free to grab all the resources it wants. It is possible and likely that it will drive replication lag higher than the threshold, which means all other throttler clients will be fully throttled and with all requests rejected.
+
+Exemption times out just as other throttling rules. To remove an exemption, any of the following will do:
+
+```sh
+$ vtctldclient UpdateThrottlerConfig --throttle-app "vreplication" --throttle-app-exempt=false commerce
+$ vtctldclient UpdateThrottlerConfig --throttle-app "vreplication" --throttle-app-duration "0" commerce
+$ vtctldclient UpdateThrottlerConfig --unthrottle-app "vreplication" commerce
```
-{{< /info >}}
### Information
+Throttler configuration is part of the `Keyspace` entry:
+
+```sh
+$ vtctldclient GetKeyspace commerce
+```
+
+```json
+{
+ "name": "commerce",
+ "keyspace": {
+ "served_froms": [],
+ "keyspace_type": 0,
+ "base_keyspace": "",
+ "snapshot_time": null,
+ "durability_policy": "semi_sync",
+ "throttler_config": {
+ "enabled": true,
+ "threshold": 15.0,
+ "custom_query": "",
+ "check_as_check_self": false,
+ "throttled_apps": {
+ "vreplication": {
+ "name": "vreplication",
+ "ratio": 0.5,
+ "expires_at": {
+ "seconds": "1687864412",
+ "nanoseconds": 142717831
+ }
+ }
+ }
+ },
+ "sidecar_db_name": "_vt"
+ }
+}
+```
+
- `/throttler/status` endpoint. This is useful for monitoring and management purposes.
-- `/throttler/throttled-apps` endpoint, listing all apps for which there's a throttling instruction
Vitess also accepts the SQL syntax:
@@ -310,22 +375,6 @@ This API call returns the following JSON object:
The replica tablet only presents `mysql/self` metric (measurement of its own backend MySQL's lag). It does not serve checks for the shard in general.
-#### Example: throttled-apps
-
-```sh
-$ curl -s 'http://127.0.0.1:15100/throttler/throttled-apps'
-```
-
-```json
-[
- {
- "AppName": "always-throttled-app",
- "ExpireAt": "2032-05-08T11:33:19.683767744Z",
- "Ratio": 1
- }
-]
-```
-
## Resources
- [freno](https://github.com/github/freno) project page
diff --git a/content/en/docs/18.0/reference/features/topology-service.md b/content/en/docs/18.0/reference/features/topology-service.md
index 4c155015a..8ec6e1f8a 100644
--- a/content/en/docs/18.0/reference/features/topology-service.md
+++ b/content/en/docs/18.0/reference/features/topology-service.md
@@ -95,7 +95,7 @@ tasks cannot concurrently alter the data.
### VSchema data
The VSchema data contains sharding and routing information for
-the [VTGate V3](https://github.com/vitessio/vitess/blob/main/doc/VTGateV3Features.md) API.
+the [VTGate API](https://github.com/vitessio/vitess/blob/main/doc/design-docs/VTGateV3Features.md).
## Local data
@@ -360,7 +360,7 @@ others wait for files with older ModRevisions to disappear.
Leader elections also use a subdirectory, named after the election Name, and use
a similar method as the locks, with ephemeral files.
-We store the proto3 binary data for each object (as the v3 API allows us to store
+We store the proto3 binary data for each object (as the API allows us to store
binary data). Note that this means that if you want to interact with etcd using
the `etcdctl` tool, you will have to tell it to use the v3 API, e.g.:
diff --git a/content/en/docs/18.0/reference/features/vindexes.md b/content/en/docs/18.0/reference/features/vindexes.md
index 04d5fc6e1..fb5ebc87f 100644
--- a/content/en/docs/18.0/reference/features/vindexes.md
+++ b/content/en/docs/18.0/reference/features/vindexes.md
@@ -149,7 +149,7 @@ Vindexes are defined in the [VSchema](../vschema/) inside the `Vindexes` section
In the above case, the name of the vindex is `name_keyspace_idx`. It is of type `lookup`, and it is owned by the `user` table.
-Every Vindex has an optional `params` section that contains a map of string key-value pairs. The keys and values differ depending on the vindex type and are explained below.
+Every Vindex has an optional `params` section that contains a map of string key-value pairs. The keys and values differ depending on the vindex type and are explained below.
There is an optional fourth parameter: `batch_lookup`. To read more about how to use `batch_lookup` see our [Unique Lookup user guide](../../../user-guides/vschema-guide/unique-lookup/).
@@ -322,3 +322,27 @@ hex_keyspace_id: d9e62c0ad204fe91658ecc758049e515
1 row in set (0.00 sec)
```
+
+### Unknown Vindex parameters
+
+Most Vindexes will accept unknown parameters without complaint. For example, the following `lookup` Vindex can be applied without error:
+
+```json
+ "name_keyspace_idx": {
+ "type": "lookup",
+ "params": {
+ "table": "name_keyspace_idx",
+ "from": "name",
+ "to": "keyspace_id",
+ "rear_lock": "none"
+ },
+ "owner": "user"
+ }
+```
+
+In this example, the user intended to use `read_lock` but typed `rear_lock` by mistake. They will be in for an unpleasant surprise during the traffic peak and `rear_lock` does nothing to mitigate lock contention.
+
+To help users avoid these kinds of unpleasant surprises, Vindexes may expose unknown parameters in the following ways:
+
+ * [As warnings](../../programs/vtctl/schema-version-permissions/#warnings) in the output of `ApplyVSchema`.
+ * As a [VTGate stat](../../../user-guides/configuration-basic/monitoring/#vindexunknownparameters) named `VindexUnknownParameters`.
diff --git a/content/en/docs/18.0/reference/programs/vtbackup.md b/content/en/docs/18.0/reference/programs/vtbackup.md
index df2f25388..afed9dc40 100644
--- a/content/en/docs/18.0/reference/programs/vtbackup.md
+++ b/content/en/docs/18.0/reference/programs/vtbackup.md
@@ -224,6 +224,7 @@ While it is running, `vtbackup` serves debugging info and metrics on port `15500
| --topo_zk_tls_ca | string | the server ca to use to validate servers when connecting to the zk topo server |
| --topo_zk_tls_cert | string | the cert to use to connect to the zk topo server, requires topo_zk_tls_key, enables TLS |
| --topo_zk_tls_key | string | the key to use to connect to the zk topo server, enables TLS |
+| --upgrade-safe | boolean | Whether to use innodb_fast_shutdown=0 for the backup so it is safe to use for MySQL upgrades |
| --v | Level | log level for V logs |
| -v, --version | | print binary version |
| --vmodule | moduleSpec | comma-separated list of pattern=N settings for file-filtered logging |
diff --git a/content/en/docs/18.0/reference/programs/vtctl/_index.md b/content/en/docs/18.0/reference/programs/vtctl/_index.md
index b9809719e..53eca97e7 100644
--- a/content/en/docs/18.0/reference/programs/vtctl/_index.md
+++ b/content/en/docs/18.0/reference/programs/vtctl/_index.md
@@ -32,7 +32,7 @@ Note that wherever `vtctl` commands produced master or MASTER for tablet type, t
| [ExecuteFetchAsApp](../vtctl/tablets#executefetchasapp) | `ExecuteFetchAsApp -- [--max_rows=10000] [--json] [--use_pool] ` |
| [ExecuteFetchAsDba](../vtctl/tablets#executefetchasdba) | `ExecuteFetchAsDba -- [--max_rows=10000] [--disable_binlogs] [--json] ` |
| [VReplicationExec](../vtctl/tablets#vreplicationexec) | `VReplicationExec -- [--json] ` |
-| [Backup](../vtctl/tablets#backup) | `Backup -- [--concurrency=4] [--allow_primary=false] ` |
+| [Backup](../vtctl/tablets#backup) | `Backup -- [--concurrency=4] [--allow_primary=false] [--upgrade-safe=false] ` |
| [RestoreFromBackup](../vtctl/tablets#restorefrombackup) | `RestoreFromBackup ` |
| [ReparentTablet](../vtctl/tablets#reparenttablet) | `ReparentTablet ` |
@@ -55,7 +55,7 @@ Note that wherever `vtctl` commands produced master or MASTER for tablet type, t
| [RemoveShardCell](../vtctl/shards#removeshardcell) | `RemoveShardCell -- [--force] [--recursive] ` |
| [DeleteShard](../vtctl/shards#deleteshard) | `DeleteShard -- [--recursive] [--even_if_serving] ...` |
| [ListBackups](../vtctl/shards#listbackups) | `ListBackups ` |
-| [BackupShard](../vtctl/shards#backupshard) | `BackupShard -- [--allow_primary=false] ` |
+| [BackupShard](../vtctl/shards#backupshard) | `BackupShard -- [--allow_primary=false] [--upgrade-safe=false] ` |
| [RemoveBackup](../vtctl/shards#removebackup) | `RemoveBackup ` |
| (DEPRECATED) [InitShardPrimary](../vtctl/shards#initshardprimary) | `InitShardPrimary -- [--force] [--wait_replicas_timeout=] ` |
| [PlannedReparentShard](../vtctl/shards#plannedreparentshard) | `PlannedReparentShard -- --keyspace_shard= [--new_primary=] [--avoid_tablet=] [--wait_replicas_timeout=]` |
@@ -99,7 +99,7 @@ Note that wherever `vtctl` commands produced master or MASTER for tablet type, t
| [ReloadSchemaKeyspace](../vtctl/schema-version-permissions#reloadschemakeyspace) | `ReloadSchemaKeyspace -- [--concurrency=10] [--include_primary=false] ` |
| [ValidateSchemaShard](../vtctl/schema-version-permissions#validateschemashard) | `ValidateSchemaShard -- [--exclude_tables=''] [--include-views] ` |
| [ValidateSchemaKeyspace](../vtctl/schema-version-permissions#validateschemakeyspace) | `ValidateSchemaKeyspace -- [--exclude_tables=''] [--include-views] ` |
-| [ApplySchema](../vtctl/schema-version-permissions#applyschema) | `ApplySchema -- [--allow_long_unavailability] [--wait_replicas_timeout=10s] {--sql= \|\| --sql-file=} ` |
+| [ApplySchema](../vtctl/schema-version-permissions#applyschema) | `ApplySchema -- [--wait_replicas_timeout=10s] {--sql= \|\| --sql-file=} ` |
| [CopySchemaShard](../vtctl/schema-version-permissions#copyschemashard) | `CopySchemaShard -- [--tables=,,...] [--exclude_tables=,,...] [--include-views] [--skip-verify] [--wait_replicas_timeout=10s] {