Releases: vitessio/vitess
Vitess v17.0.7
Release of Vitess v17.0.7
The entire changelog for this release can be found here.
The release includes 14 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @frouioui, @systay, @vitess-bot
Vitess v19.0.3
Release of Vitess v19.0.3
Removal of v19.0.2
The maintainers team decided to remove the v19.0.2
release as it contained a CVE fixed in v19.0.3
.
The entire changelog for this release can be found here.
The release includes 16 merged Pull Requests.
Thanks to all our contributors: @GrahamCampbell, @app/vitess-bot, @frouioui, @rohit-nayak-ps, @shlomi-noach, @systay
Vitess v18.0.4
Release of Vitess v18.0.4
The entire changelog for this release can be found here.
The release includes 8 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @frouioui, @shlomi-noach, @systay
Vitess v19.0.1
Vitess v18.0.3
Release of Vitess v18.0.3
Summary
Table of Contents
Major Changes
Breaking Changes
ExecuteFetchAsDBA rejects multi-statement SQL
vtctldclient ExecuteFetchAsDBA
(and similarly the vtctl
and vtctlclient
commands) now reject multi-statement SQL with error.
For example, vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica
will return an error, without attempting to execute any of these queries.
Previously, ExecuteFetchAsDBA
silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
ExecuteFetchAsDBA
does allow a specific use case of multi-statement SQL, which is where all statements are in the form of CREATE TABLE
or CREATE VIEW
. This is to support a common pattern of schema initialization, formalized in ApplySchema --batch-size
which uses ExecuteFetchAsDBA
under the hood.
The entire changelog for this release can be found here.
The release includes 47 merged Pull Requests.
Thanks to all our contributors: @app/github-actions, @app/vitess-bot, @frouioui, @harshit-gangal, @rohit-nayak-ps, @shlomi-noach, @systay, @wangweicugw
Vitess v17.0.6
Release of Vitess v17.0.6
Summary
Table of Contents
Major Changes
Breaking Changes
ExecuteFetchAsDBA rejects multi-statement SQL
vtctldclient ExecuteFetchAsDBA
(and similarly the vtctl
and vtctlclient
commands) now reject multi-statement SQL with error.
For example, vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica
will return an error, without attempting to execute any of these queries.
Previously, ExecuteFetchAsDBA
silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
ExecuteFetchAsDBA
does allow a specific use case of multi-statement SQL, which is where all statements are in the form of CREATE TABLE
or CREATE VIEW
. This is to support a common pattern of schema initialization.
The entire changelog for this release can be found here.
The release includes 24 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @frouioui, @harshit-gangal, @shlomi-noach, @systay
Vitess v19.0.0
Release of Vitess v19.0.0
Summary
Table of Contents
- Major Changes
- Minor Changes
Major Changes
Dropping Support for MySQL 5.7
Oracle has marked MySQL 5.7 end of life as of October 2023. Vitess is also dropping support for MySQL 5.7 from v19 onwards. Users are advised to upgrade to MySQL 8.0 while on v18 version of Vitess before
upgrading to v19.
Vitess will however, continue to support importing from MySQL 5.7 into Vitess even in v19.
Deprecations and Deletions
- The
MYSQL_FLAVOR
environment variable is now removed from all Docker Images.
VTTablet Flags
- The following flags — which were deprecated in Vitess 7.0 — have been removed:
--vreplication_healthcheck_topology_refresh
,--vreplication_healthcheck_retry_delay
, and--vreplication_healthcheck_timeout
. - The
--vreplication_tablet_type
flag is now deprecated and ignored.
Docker Image vitess/lite
Caution
If you are using incremental backups, you must remain on the vitess/lite
image, as the official MySQL image does not have mysqlbinlog
installed.
See #16281 for more information.
The mysqld
binary is now deprecated in the vitess/lite
Docker image and will be removed in a future release.
This means that the MySQL/Percona version specific image tags for the vitess/lite
image are deprecated.
Below is a full list of available tags for v19.0.0
and their deprecation status:
Image | Deprecated |
---|---|
vitess/lite:v19.0.0 |
NO |
vitess/lite:v19.0.0-mysql57 |
YES |
vitess/lite:v19.0.0-mysql80 |
YES |
vitess/lite:v19.0.0-percona57 |
YES |
vitess/lite:v19.0.0-percona80 |
YES |
If you are currently using vitess/lite
as your mysqld
image in your vitess-operator deployment we invite you to use an official MySQL image, such as mysql:8.0.30
.
Below is an example of a kubernetes yaml file before and after upgrading to an official MySQL image:
# before:
# the image used here includes MySQL 8.0.30 and its binaries
mysqld:
mysql80Compatible: vitess/lite:v19.0.0-mysql80
# after:
# if we still want to use MySQL 8.0.30, we now have to use the
# official MySQL image with the 8.0.30 tag as shown below
mysqld:
mysql80Compatible: mysql:8.0.30 # or even mysql:8.0.34 for instance
Explain Statement Format
Explain statement format vitess
and vexplain
were deprecated in v16 and removed in v19 version.
Use VExplain Statement for understanding Vitess plans.
Breaking Changes
ExecuteFetchAsDBA rejects multi-statement SQL
vtctldclient ExecuteFetchAsDBA
(and similarly the vtctl
and vtctlclient
commands) now reject multi-statement SQL with error.
For example, vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica
will return an error, without attempting to execute any of these queries.
Previously, ExecuteFetchAsDBA
silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
ExecuteFetchAsDBA
does allow a specific use case of multi-statement SQL, which is where all statements are in the form of CREATE TABLE
or CREATE VIEW
. This is to support a common pattern of schema initialization, formalized in ApplySchema --batch-size
which uses ExecuteFetchAsDBA
under the hood.
New Stats
Stream Consolidations
Prior to 19.0 VTTablet reported how much time non-streaming executions spend waiting for consolidations to occur. In 19.0, VTTablet reports a similar stat for streaming executions in /debug/vars
stat Waits.Histograms.StreamConsolidations
.
Build Version in /debug/vars
The build version (e.g., 19.0.0-SNAPSHOT
) has been added to /debug/vars
, allowing users to programmatically inspect Vitess components' build version at runtime.
Planned Reparent Shard
--tolerable-replication-lag
Sub-flag
A new sub-flag --tolerable-replication-lag
has been added to the command PlannedReparentShard
that allows users to specify the amount of replication lag that is considered acceptable for a tablet to be eligible for promotion when Vitess makes the choice of a new primary.
This feature is opt-in and not specifying this sub-flag makes Vitess ignore the replication lag entirely.
A new flag in VTOrc with the same name has been added to control the behaviour of the PlannedReparentShard calls that VTOrc issues.
Query Compatibility
Multi Table Delete Support
Support is added for sharded multi-table delete with target on single table using multiple table join.
Example: Delete t1 from t1 join t2 on t1.id = t2.id join t3 on t1.col = t3.col where t3.foo = 5 and t2.bar = 7
More details about how it works is available in MySQL Docs
SHOW VSCHEMA KEYSPACES
Query
A SQL query, SHOW VSCHEMA KEYSPACES
is now supported in Vitess. This query prints the vschema information
for all the keyspaces. It is useful for seeing the foreign key mode, whether the keyspace is sharded, and if there is an
error in the VSchema for the keyspace.
An example output of the query looks like -
mysql> show vschema keyspaces;
+----------+---------+-------------+---------+
| Keyspace | Sharded | Foreign Key | Comment |
+----------+---------+-------------+---------+
| ks | true | managed | |
| uks | false | managed | |
+----------+---------+-------------+---------+
2 rows in set (0.01 sec)
FOREIGN_KEY_CHECKS
is now a Vitess Aware Variable
When VTGate receives a query to change the FOREIGN_KEY_CHECKS
value for a session, instead of sending the value down to MySQL, VTGate now keeps track of the value and changes the queries by adding SET_VAR(FOREIGN_KEY_CHECKS=On/Off)
style query optimizer hints wherever required.
Explain Statement
Explain
statement can handle routed table queries now. Explain
is unsupported when the tables involved in the query refers more than one keyspace. Users should use VExplain Statement in those cases.
Partial Multi-shard Commit Warnings
When using multi
transaction mode (the default), it is possible for Vitess to successfully commit to one shard, but fail to commit to a subsequent shard, thus breaking the atomicity of a multi-shard transaction.
In v19.0
, VTGate reports partial-success commits in warnings, e.g.:
mysql> commit;
ERROR 1317 (70100): target: customer.-80.primary: vttablet: rpc error: code = Aborted desc = transaction 1703182545849001001: ended at 2023-12-21 14:07:41.515 EST (exceeded timeout: 30s) (CallerID: userData1)
mysql> show warnings;
+---------+------+----------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------+
| Warning | 301 | multi-db co...
Vitess v19.0.0-rc1
Release of Vitess v19.0.0
Summary
Table of Contents
- Major Changes
- Minor Changes
Major Changes
Dropping Support for MySQL 5.7
Oracle has marked MySQL 5.7 end of life as of October 2023. Vitess is also dropping support for MySQL 5.7 from v19 onwards. Users are advised to upgrade to MySQL 8.0 while on v18 version of Vitess before
upgrading to v19.
Vitess will however, continue to support importing from MySQL 5.7 into Vitess even in v19.
Deprecations and Deletions
- The
MYSQL_FLAVOR
environment variable is now removed from all Docker Images.
VTTablet Flags
- The following flags — which were deprecated in Vitess 7.0 — have been removed:
--vreplication_healthcheck_topology_refresh
,--vreplication_healthcheck_retry_delay
, and--vreplication_healthcheck_timeout
. - The
--vreplication_tablet_type
flag is now deprecated and ignored.
Docker Image vitess/lite
The mysqld
binary is now deprecated in the vitess/lite
Docker image and will be removed in a future release.
This means that the MySQL/Percona version specific image tags for the vitess/lite
image are deprecated.
Below is a full list of available tags for v19.0.0
and their deprecation status:
Image | Deprecated |
---|---|
vitess/lite:v19.0.0 |
NO |
vitess/lite:v19.0.0-mysql57 |
YES |
vitess/lite:v19.0.0-mysql80 |
YES |
vitess/lite:v19.0.0-percona57 |
YES |
vitess/lite:v19.0.0-percona80 |
YES |
If you are currently using vitess/lite
as your mysqld
image in your vitess-operator deployment we invite you to use an official MySQL image, such as mysql:8.0.30
.
Below is an example of a kubernetes yaml file before and after upgrading to an official MySQL image:
# before:
# the image used here includes MySQL 8.0.30 and its binaries
mysqld:
mysql80Compatible: vitess/lite:v19.0.0-mysql80
# after:
# if we still want to use MySQL 8.0.30, we now have to use the
# official MySQL image with the 8.0.30 tag as shown below
mysqld:
mysql80Compatible: mysql:8.0.30 # or even mysql:8.0.34 for instance
Explain Statement Format
Explain statement format vitess
and vexplain
were deprecated in v16 and removed in v19 version.
Use VExplain Statement for understanding Vitess plans.
Breaking Changes
ExecuteFetchAsDBA rejects multi-statement SQL
vtctldclient ExecuteFetchAsDBA
(and similarly the vtctl
and vtctlclient
commands) now reject multi-statement SQL with error.
For example, vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica
will return an error, without attempting to execute any of these queries.
Previously, ExecuteFetchAsDBA
silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
ExecuteFetchAsDBA
does allow a specific use case of multi-statement SQL, which is where all statements are in the form of CREATE TABLE
or CREATE VIEW
. This is to support a common pattern of schema initialization, formalized in ApplySchema --batch-size
which uses ExecuteFetchAsDBA
under the hood.
New Stats
Stream Consolidations
Prior to 19.0 VTTablet reported how much time non-streaming executions spend waiting for consolidations to occur. In 19.0, VTTablet reports a similar stat for streaming executions in /debug/vars
stat Waits.Histograms.StreamConsolidations
.
Build Version in /debug/vars
The build version (e.g., 19.0.0-SNAPSHOT
) has been added to /debug/vars
, allowing users to programmatically inspect Vitess components' build version at runtime.
Planned Reparent Shard
--tolerable-replication-lag
Sub-flag
A new sub-flag --tolerable-replication-lag
has been added to the command PlannedReparentShard
that allows users to specify the amount of replication lag that is considered acceptable for a tablet to be eligible for promotion when Vitess makes the choice of a new primary.
This feature is opt-in and not specifying this sub-flag makes Vitess ignore the replication lag entirely.
A new flag in VTOrc with the same name has been added to control the behaviour of the PlannedReparentShard calls that VTOrc issues.
Query Compatibility
Multi Table Delete Support
Support is added for sharded multi-table delete with target on single table using multiple table join.
Example: Delete t1 from t1 join t2 on t1.id = t2.id join t3 on t1.col = t3.col where t3.foo = 5 and t2.bar = 7
More details about how it works is available in MySQL Docs
SHOW VSCHEMA KEYSPACES
Query
A SQL query, SHOW VSCHEMA KEYSPACES
is now supported in Vitess. This query prints the vschema information
for all the keyspaces. It is useful for seeing the foreign key mode, whether the keyspace is sharded, and if there is an
error in the VSchema for the keyspace.
An example output of the query looks like -
mysql> show vschema keyspaces;
+----------+---------+-------------+---------+
| Keyspace | Sharded | Foreign Key | Comment |
+----------+---------+-------------+---------+
| ks | true | managed | |
| uks | false | managed | |
+----------+---------+-------------+---------+
2 rows in set (0.01 sec)
FOREIGN_KEY_CHECKS
is now a Vitess Aware Variable
When VTGate receives a query to change the FOREIGN_KEY_CHECKS
value for a session, instead of sending the value down to MySQL, VTGate now keeps track of the value and changes the queries by adding SET_VAR(FOREIGN_KEY_CHECKS=On/Off)
style query optimizer hints wherever required.
Explain Statement
Explain
statement can handle routed table queries now. Explain
is unsupported when the tables involved in the query refers more than one keyspace. Users should use VExplain Statement in those cases.
Partial Multi-shard Commit Warnings
When using multi
transaction mode (the default), it is possible for Vitess to successfully commit to one shard, but fail to commit to a subsequent shard, thus breaking the atomicity of a multi-shard transaction.
In v19.0
, VTGate reports partial-success commits in warnings, e.g.:
mysql> commit;
ERROR 1317 (70100): target: customer.-80.primary: vttablet: rpc error: code = Aborted desc = transaction 1703182545849001001: ended at 2023-12-21 14:07:41.515 EST (exceeded timeout: 30s) (CallerID: userData1)
mysql> show warnings;
+---------+------+----------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------+
| Warning | 301 | multi-db commit failed after committing to 1 shards: 80- |
+---------+------+----------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
Vttestserver
--vtcombo-bind-host
flag
A new flag --vtcombo-bind-host
has been added to vttestserver that allows the us...
Vitess v18.0.2
Release of Vitess v18.0.2
The entire changelog for this release can be found here.
The release includes 27 merged Pull Requests.
Thanks to all our contributors: @brendar, @deepthi, @harshit-gangal, @rohit-nayak-ps, @systay
Vitess v17.0.5
Release of Vitess v17.0.5
The entire changelog for this release can be found here.
The release includes 22 merged Pull Requests.
Thanks to all our contributors: @GuptaManan100, @deepthi, @frouioui, @harshit-gangal, @shlomi-noach, @systay