Skip to content

Commit b204879

Browse files
shlomi-noachshlomi-noach
committed
resolved conflict
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
2 parents 21fb5f0 + ee74410 commit b204879

13 files changed

Lines changed: 66 additions & 44 deletions

‎content/en/docs/18.0/concepts/query-rewriting.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -95,6 +95,7 @@ Here is a list of all the system variables that are handled by Vitess and how th
9595
| charset | VitessAware |
9696
| names | VitessAware |
9797
| session_uuid | VitessAware |
98+
| migration_context | VitessAware |
9899
| enable_system_settings | VitessAware |
99100
| read_after_write_gtid | VitessAware |
100101
| read_after_write_timeout | VitessAware |

‎content/en/docs/18.0/reference/errors/query-serving.md‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -46,6 +46,7 @@ These error messages are internal to Vitess. If you are getting other errors fro
4646
| VT05006 | The given system variable is unknown. | unknown system variable '%s' | 1193 | HY000 |
4747
| VT05007 | Table information is not available. | no table info | 0 | |
4848
| VT06001 | The given database name already exists. | cannot create database '%s'; database exists | 1007 | HY000 |
49+
| VT07001 | Kill statement is not allowed. More in docs about how to enable it and its limitations. | %s | 1095 | HY000 |
4950
| VT09001 | the table does not have a primary vindex, the operation is impossible. | table '%s' does not have a primary vindex | 1173 | 42000 |
5051
| VT09002 | This type of DML statement is not allowed on a replica target. | %s statement with a replica target | 1874 | HY000 |
5152
| VT09003 | A vindex column is mandatory for the insert, please provide one. | INSERT query does not have primary vindex column '%v' in the column list | 0 | |
@@ -58,6 +59,9 @@ These error messages are internal to Vitess. If you are getting other errors fro
5859
| VT09010 | SHOW VITESS_THROTTLER STATUS works only on primary tablet. | SHOW VITESS_THROTTLER STATUS works only on primary tablet | 0 | |
5960
| VT09011 | The prepared statement is not available | Unknown prepared statement handler (%s) given to %s | 1243 | HY000 |
6061
| VT09012 | This type of statement is not allowed on the given tablet. | %s statement with %s tablet not allowed | 0 | |
62+
| VT09013 | Durability policy wants Vitess to use semi-sync, but the MySQL instances don't have the semi-sync plugin loaded. | semi-sync plugins are not loaded | 0 | |
63+
| VT09014 | The vindex cannot be used as table in DML statement | vindex cannot be modified | 0 | |
64+
| VT09015 | This query cannot be planned without more information on the SQL schema. Please turn on schema tracking or add authoritative columns information to your VSchema. | schema tracking required | 0 | |
6165
| VT10001 | Foreign key constraints are not allowed, see https://vitess.io/blog/2021-06-15-online-ddl-why-no-fk/. | foreign key constraints are not allowed | 0 | |
6266
| VT12001 | This statement is unsupported by Vitess. Please rewrite your query to use supported syntax. | unsupported: %s | 0 | |
6367
| VT13001 | This error should not happen and is a bug. Please file an issue on GitHub: https://github.com/vitessio/vitess/issues/new/choose. | [BUG] %s | 0 | |

‎content/en/docs/18.0/reference/programs/vtctl/_index.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ Note that wherever `vtctl` commands produced master or MASTER for tablet type, t
9999
| [ReloadSchemaKeyspace](../vtctl/schema-version-permissions#reloadschemakeyspace) | `ReloadSchemaKeyspace -- [--concurrency=10] [--include_primary=false] <keyspace>` |
100100
| [ValidateSchemaShard](../vtctl/schema-version-permissions#validateschemashard) | `ValidateSchemaShard -- [--exclude_tables=''] [--include-views] <keyspace/shard>` |
101101
| [ValidateSchemaKeyspace](../vtctl/schema-version-permissions#validateschemakeyspace) | `ValidateSchemaKeyspace -- [--exclude_tables=''] [--include-views] <keyspace name>` |
102-
| [ApplySchema](../vtctl/schema-version-permissions#applyschema) | `ApplySchema -- [--wait_replicas_timeout=10s] {--sql=<sql> \|\| --sql-file=<filename>} <keyspace>` |
102+
| [ApplySchema](../vtctl/schema-version-permissions#applyschema) | `ApplySchema -- [--wait_replicas_timeout=10s] {--sql=<sql> \|\| --sql-file=<filename>} [--batch-size=100] <keyspace>` |
103103
| [CopySchemaShard](../vtctl/schema-version-permissions#copyschemashard) | `CopySchemaShard -- [--tables=<table1>,<table2>,...] [--exclude_tables=<table1>,<table2>,...] [--include-views] [--skip-verify] [--wait_replicas_timeout=10s] {<source keyspace/shard> \|\| <source tablet alias>} <destination keyspace/shard>` |
104104
| [ValidateVersionShard](../vtctl/schema-version-permissions#validateversionshard) | `ValidateVersionShard <keyspace/shard>` |
105105
| [ValidateVersionKeyspace](../vtctl/schema-version-permissions#validateversionkeyspace) | `ValidateVersionKeyspace <keyspace name>` |

‎content/en/docs/18.0/reference/programs/vtctl/schema-version-permissions.md‎

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -149,11 +149,11 @@ Validates that the schema on the primary tablet for shard 0 matches the schema o
149149

150150
### ApplySchema
151151

152-
Applies the schema change to the specified keyspace on all shards. The recommended method of applying schema changes is via [Online DDL](../../../../user-guides/schema-changes/managed-online-schema-changes/), which ensures migrations are non-blocking and keeps replication in sync throughout the operation. --ddl_strategy is used to instruct migrations via vreplication, `gh-ost` or `pt-osc` with optional parameters. -request_context allows the user to specify a custom request context for online DDL migrations. If --skip_preflight, SQL goes directly to shards without going through sanity checks.
152+
Applies the schema change to the specified keyspace on all shards. The recommended method of applying schema changes is via [Online DDL](../../../../user-guides/schema-changes/managed-online-schema-changes/), which ensures migrations are non-blocking and keeps replication in sync throughout the operation. --ddl_strategy is used to instruct migrations via vreplication, `gh-ost` or `pt-osc` with optional parameters. -request_context allows the user to specify a custom request context for online DDL migrations.
153153

154154
#### Example
155155

156-
<pre class="command-example">ApplySchema -- [--wait_replicas_timeout=10s] [--ddl_strategy=<ddl_strategy>] [--request_context=<unique-request-context>] [--skip_preflight] {--sql=&lt;sql&gt; || --sql-file=&lt;filename&gt;} &lt;keyspace&gt;</pre>
156+
<pre class="command-example">ApplySchema -- [--wait_replicas_timeout=10s] [--ddl_strategy=<ddl_strategy>] [--request_context=<unique-request-context>] {--sql=&lt;sql&gt; || --sql-file=&lt;filename&gt;} &lt;keyspace&gt;</pre>
157157

158158
#### Flags
159159

@@ -162,7 +162,6 @@ Applies the schema change to the specified keyspace on all shards. The recommend
162162
| caller_id | string | Effective caller ID used for the operation and should map to an ACL name which grants this identity the necessary permissions to perform the operation (this is only necessary when strict table ACLs are used). |
163163
| ddl_strategy | string | Online DDL strategy, compatible with @@ddl_strategy session variable (examples: 'gh-ost', 'pt-osc', 'gh-ost --max-load=Threads_running=100' (default "direct"). |
164164
| request_context | string | For Only DDL, optionally supply a custom unique string used as context for the migration(s) in this command. By default a unique context is auto-generated by Vitess. |
165-
| skip_preflight | Boolean | Skip pre-apply schema checks, and directly forward schema change query to shards. Ignored when using Online DDL |
166165
| sql | string | A list of semicolon-delimited SQL commands. |
167166
| sql-file | string | Identifies the file that contains the SQL commands. This file needs to exist on the server, rather than on the client. |
168167
| wait_replicas_timeout | Duration | The amount of time to wait for replicas to receive the schema change via replication (default 10s). |

‎content/en/docs/18.0/reference/programs/vtctldclient/vtctldclient_ApplySchema.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ vtctldclient ApplySchema [--ddl-strategy <strategy>] [--uuid <uuid> ...] [--migr
3030

3131
```
3232
--allow-long-unavailability Deprecated and has no effect.
33-
--batch-size int How many queries to batch together. Only applicabel when all queries are CREATE TABLE|VIEW
33+
--batch-size int How many queries to batch together. Only applicable when all queries are CREATE TABLE|VIEW
3434
--caller-id string Effective caller ID used for the operation and should map to an ACL name which grants this identity the necessary permissions to perform the operation (this is only necessary when strict table ACLs are used).
3535
--ddl-strategy string Online DDL strategy, compatible with @@ddl_strategy session variable (examples: 'gh-ost', 'pt-osc', 'gh-ost --max-load=Threads_running=100'. (default "direct")
3636
-h, --help help for ApplySchema

‎content/en/docs/18.0/user-guides/migration/troubleshooting.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -137,9 +137,9 @@ This can be caused by a DDL executed on the source table as by default — contr
137137
If you want the same or similar DDL to be applied on the target then you can apply that DDL on the target keyspace
138138
and then restart the workflow. For example, using the example above:
139139
```bash
140-
$ vtctlclient ApplySchema -- --ddl_strategy=direct --sql="alter table customer add notes varchar(100) not null" customer
140+
$ vtctldclient ApplySchema --ddl-strategy=direct --sql="alter table customer add notes varchar(100) not null" customer
141141

142-
$ vtctlclient Workflow -- customer.commerce2customer start
142+
$ vtctldclient Workflow customer.commerce2customer start
143143
```
144144

145145
If the tables are not very large or the workflow has not made much progress, you can alternatively `Cancel` the current

‎content/en/docs/18.0/user-guides/schema-changes/advanced-usage.md‎

Lines changed: 23 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -33,9 +33,9 @@ Thus, the new migration does not get to execute if an identical previous migrati
3333
Usage:
3434

3535
```sh
36-
$ vtctldclient ApplySchema -- --migration_context="1111-2222" --skip_preflight --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
36+
$ vtctldclient ApplySchema -- --migration_context="1111-2222" --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
3737

38-
$ vtctldclient ApplySchema -- --migration_context="1111-2222" --skip_preflight --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
38+
$ vtctldclient ApplySchema -- --migration_context="1111-2222" --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
3939
```
4040

4141
In the above, the two calls are identical. Specifically, they share the exact same `--migration_context` value of `1111-2222`, and the exact same `--sql`.
@@ -49,16 +49,26 @@ Notes:
4949
- Continuing the above example: if the new migration is successful, the previous migration remains in `failed` state.
5050
- The decision whether to run the migration or to mark it as implicitly `complete` only takes place when the migration is scheduled to run.
5151

52+
The context may also be set via VTGate:
53+
54+
```sql
55+
mysql> set @@ddl_strategy='vitess --';
56+
mysql> set @@migration_context='1111-2222';
57+
mysql> alter table customer add column status int unsigned not null;
58+
```
59+
60+
By default, the migration context for an Online DDL issued via VTGate is the value of `@@session_uuid`. If `@@migration_context` is non-empty, then its value is used.
61+
5262
## Duplicate migration indication
5363

5464
You may go one step beyond [duplicate migration detection](#duplicate-migration-detection) by explicitly supplying migration UUIDs such that duplicate migrations are never submitted in the first place.
5565

5666
Consider the following example, note `--uuid_list` flag:
5767

5868
```sh
59-
$ vtctldclient ApplySchema -- --uuid_list "73380089_7764_11ec_a656_0a43f95f28a3" --skip_preflight --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
69+
$ vtctldclient ApplySchema -- --uuid_list "73380089_7764_11ec_a656_0a43f95f28a3" --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
6070

61-
$ vtctldclient ApplySchema -- --uuid_list "73380089_7764_11ec_a656_0a43f95f28a3" --skip_preflight --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
71+
$ vtctldclient ApplySchema -- --uuid_list "73380089_7764_11ec_a656_0a43f95f28a3" --ddl_strategy='vitess' --sql "alter table customer add column status int unsigned not null" commerce
6272
```
6373

6474
Normally Vitess generates a `UUID` for each migration, thus having a new, unique ID per migration. With `-uuid_list`, you can force Vitess into using your own supplied UUID. There cannot be two migrations with the same `UUID`. Therefore, any subsequent submission of a migration with an already existing `UUID` is implicitly discarded. The 2nd call does return the migration `UUID`, but is internally discarded.
@@ -86,7 +96,7 @@ The user may submit multiple migrations such that non auto-completes. The user c
8696
Consider the following:
8797

8898
```sh
89-
$ vtctldclient ApplySchema --skip_preflight --ddl_strategy='vitess --postpone-completion --allow-concurrent' --sql "alter table customer add column country int not null default 0; alter table order add column shipping_country int not null default 0" commerce
99+
$ vtctldclient ApplySchema --ddl_strategy='vitess --postpone-completion --allow-concurrent' --sql "alter table customer add column country int not null default 0; alter table order add column shipping_country int not null default 0" commerce
90100
29231906_776f_11ec_a656_0a43f95f28a3
91101
3cc4ae0e_776f_11ec_a656_0a43f95f28a3
92102
```
@@ -98,14 +108,14 @@ A `show vitess_migrations like '29231906_776f_11ec_a656_0a43f95f28a3'` presents
98108
When all migrations for the relevant UUIDs show `1` for `ready_to_complete`, the user can then either:
99109

100110
```sh
101-
$ vtctldclient ApplySchema --skip_preflight --sql "alter vitess_migration complete all" commerce
111+
$ vtctldclient ApplySchema --sql "alter vitess_migration complete all" commerce
102112
```
103113

104114
Assuming these are the only migrations awaiting completion, or, explicitly issue a complete for each of the migrations:
105115

106116
```sh
107-
$ vtctldclient ApplySchema --skip_preflight --sql "alter vitess_migration '29231906_776f_11ec_a656_0a43f95f28a3' complete all" commerce
108-
$ vtctldclient ApplySchema --skip_preflight --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' complete all" commerce
117+
$ vtctldclient ApplySchema --sql "alter vitess_migration '29231906_776f_11ec_a656_0a43f95f28a3' complete all" commerce
118+
$ vtctldclient ApplySchema --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' complete all" commerce
109119
```
110120

111121
## Near instant REVERTs
@@ -125,14 +135,14 @@ The use case and workflow is as follows:
125135
Consider the following example. We run a 5 hour long migration to drop an index:
126136

127137
```sh
128-
$ vtctldclient ApplySchema --skip_preflight --ddl_strategy='vitess' --sql "alter table customer drop index joined_timestamp_idx" commerce
138+
$ vtctldclient ApplySchema --ddl_strategy='vitess' --sql "alter table customer drop index joined_timestamp_idx" commerce
129139
29231906_776f_11ec_a656_0a43f95f28a3
130140
```
131141

132142
As soon as the migration completes, we run:
133143

134144
```sh
135-
$ vtctldclient ApplySchema --skip_preflight --ddl_strategy='vitess --postpone-completion --allow-concurrent' --sql "revert vitess_migration '29231906_776f_11ec_a656_0a43f95f28a3'" commerce
145+
$ vtctldclient ApplySchema --ddl_strategy='vitess --postpone-completion --allow-concurrent' --sql "revert vitess_migration '29231906_776f_11ec_a656_0a43f95f28a3'" commerce
136146
3cc4ae0e_776f_11ec_a656_0a43f95f28a3
137147
```
138148

@@ -141,15 +151,15 @@ The above begins a `REVERT` migration that is open-ended (does not complete), vi
141151
Finally, if we are satisfied that the `drop index` migration went well, we issue:
142152

143153
```sh
144-
$ vtctldclient ApplySchema --skip_preflight --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' cancel" commerce
154+
$ vtctldclient ApplySchema --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' cancel" commerce
145155
```
146156

147157
That is, we cancel the `REVERT` operation.
148158

149159
Or, should we have not dropped the index? If our migration seems to have been wrong, we run:
150160

151161
```sh
152-
$ vtctldclient ApplySchema --skip_preflight --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' complete" commerce
162+
$ vtctldclient ApplySchema --sql "alter vitess_migration '3cc4ae0e_776f_11ec_a656_0a43f95f28a3' complete" commerce
153163
```
154164

155165
Which means we want to apply the revert. Since the revert is already running in the background, it is likely that binary log processing is up to date, and cut-over is near instantaneous.
@@ -171,7 +181,7 @@ Note that there can be scenarios with impossible ordering. Those hardly make sen
171181
An example for in-order submission:
172182

173183
```sh
174-
$ vtctldclient ApplySchema --skip_preflight --ddl_strategy='vitess --allow-concurrent --in-order-completion' --sql "create table t1 (id int primary key); create view v1 as select id from t1;" commerce
184+
$ vtctldclient ApplySchema --ddl_strategy='vitess --allow-concurrent --in-order-completion' --sql "create table t1 (id int primary key); create view v1 as select id from t1;" commerce
175185
```
176186

177187
{{< info >}}

0 commit comments

Comments
 (0)