Releases: vitessio/vitess
Vitess v24.0.1
Contributors
Assets 5
Vitess v23.0.4
Release of Vitess v23.0.4
The entire changelog for this release can be found here.
The release includes 44 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @arthurschreiber, @mattlord, @vitess-bot
Contributors
Assets 5
Vitess v24.0.0
Release of Vitess v24.0.0
Summary
Table of Contents
- Major Changes
- Minor Changes
Major Changes
New Support
Window function pushdown for sharded keyspaces
This release introduces an optimization that allows window functions to be pushed down to individual shards when they are partitioned by a column that matches a unique vindex.
Previously, all window function queries required single-shard routing, which limited their applicability on sharded tables. With this change, queries where the PARTITION BY clause aligns with a unique vindex can now be pushed down and executed on each shard.
For examples and more details, see the documentation.
View Routing Rules
Vitess now supports routing rules for views, and can be applied the same as tables with vtctldclient ApplyRoutingRules. When a view routing rule is active, VTGate rewrites queries that reference the source view to use the target view's definition instead. For example, given this routing rule:
{
"rules": [
{
"from_table": "source_ks.my_view",
"to_tables": ["target_ks.my_view"]
}
]
}And this view definition:
CREATE VIEW target_ks.my_view AS SELECT id, name FROM user;A query like SELECT * FROM source_ks.my_view would be internally rewritten to:
SELECT * FROM (SELECT id, name FROM target_ks.user) AS my_view;View routing rules require the schema tracker to monitor views, which means VTGate must be started with the --enable-views flag and VTTablet with the --queryserver-enable-views flag. The target view must exist in the specified keyspace for the routing rule to function correctly. For more details, see the Schema Routing Rules documentation.
Tablet targeting via USE statement
VTGate now supports routing queries to a specific tablet by alias using an extended USE statement syntax:
USE keyspace:shard@tablet_type|tablet_alias;For example, to target a specific replica tablet:
USE commerce:-80@replica|zone1-0000000100;Once set, all subsequent queries in the session route to the specified tablet until cleared with a standard USE keyspace or USE keyspace@tablet_type statement. This is useful for debugging, per-tablet monitoring, cache warming, and other operational tasks where targeting a specific tablet is required.
Note: A shard must be specified when using tablet targeting. Like shard targeting, this bypasses vindex-based routing, so use with care.
Binlog Streaming Support
VTGate now supports GTID-based binlog streaming through two protocols:
- MySQL protocol: Clients can connect using the standard MySQL
COM_BINLOG_DUMP_GTIDreplication protocol command—no special VStream-aware adapters or direct MySQL access required. - gRPC: The new
BinlogDumpGTIDstreaming RPC invtgateserviceprovides native gRPC access for custom clients without the MySQL protocol dependency.
Note: Only GTID-based streaming is supported. File/position-based streaming is not available through either COM_BINLOG_DUMP or COM_BINLOG_DUMP_GTID and returns an error.
This feature is disabled by default. Enable it with --enable-binlog-dump.
New flags:
--enable-binlog-dump: Enables binlog dump support. Without this flag, binlog dump requests return an error.--binlog-dump-authorized-users: Comma-separated list of users authorized to execute binlog dump operations, or%to allow all users.
Requirements:
When initiating a binlog dump connection, clients must specify:
- An empty filename
- A file position (
filepos) of 4 - A GTID position
For gRPC clients, specify the keyspace, shard, and optionally the tablet type or tablet alias directly in the BinlogDumpGTIDRequest.
Limitations:
- Each stream operates on a single tablet—no data aggregation across shards.
- No automatic failover—if the targeted tablet becomes unavailable, the stream fails and the client must reconnect to a different tablet.
- Not compatible with
MoveTablesorReshardoperations. Use the VStream API for those use cases.
Structured logging
Vitess now uses structured JSON logging by default. Log output is emitted as JSON to stderr. To configure the minimum log level, pass --log-level (one of debug, info, warn, error; default info). For a human-readable format with automatic color detection, pass --log-format=text. To revert to the previous glog backend, pass --log-structured=false.
glog is deprecated as of v24 and will be removed in v25.
Breaking Changes
External Decompressor No Longer Read from Backup MANIFEST by Default
The external decompressor command stored in a backup's MANIFEST file is no longer used at restore time by default. Previously, when no --external-decompressor flag was provided, VTTablet would fall back to the command specified in the MANIFEST. This posed a security risk: an attacker with write access to backup storage could modify the MANIFEST to execute arbitrary commands on the tablet.
Starting in v24, the MANIFEST-based decompressor is ignored unless you explicitly opt in with the new --external-decompressor-use-manifest flag. If you rely on this behavior, add the flag to your VTTablet configuration, but be aware of the security implications.
See #19460 for details.
Minor Changes
VReplication
--shards flag for MoveTables/Reshard start and stop
The start and stop commands for MoveTables and Reshard workflows now support the --shards flag, allowing users to start or stop workflows on a specific subset of shards rather than all shards at once.
Example usage:
# Start workflow on specific shards only
vtctldclient MoveTables --target-keyspace customer --workflow commerce2customer start --shards="-80,80-"
# Stop workflow on specific shards only
vtctldclient Reshard --target-keyspace customer --workflow cust2cust stop --shards="80-"Automatic tablet retry for tablet-specific errors
VReplication workflows now automatically retry with different tablets when encountering tablet-specific errors. Previously, workflows without a cell preference would default to the local cell and could get stuck retrying the same failing tablet indefinitely.
When a tablet encounters errors like binary log purging (MySQL error 1236 or 1789) or GTID set mismatches, VReplication adds that tablet to an ignore list and tries other tablets across all cells. Once all matching tablets have been tried, the ignore list is cleared and the workflow retries from scra...
Contributors
Assets 5
Vitess v24.0.0-rc1
Release of Vitess v24.0.0
Summary
Table of Contents
- Major Changes
- Minor Changes
Major Changes
New Support
Window function pushdown for sharded keyspaces
This release introduces an optimization that allows window functions to be pushed down to individual shards when they are partitioned by a column that matches a unique vindex.
Previously, all window function queries required single-shard routing, which limited their applicability on sharded tables. With this change, queries where the PARTITION BY clause aligns with a unique vindex can now be pushed down and executed on each shard.
For examples and more details, see the documentation.
View Routing Rules
Vitess now supports routing rules for views, and can be applied the same as tables with vtctldclient ApplyRoutingRules. When a view routing rule is active, VTGate rewrites queries that reference the source view to use the target view's definition instead. For example, given this routing rule:
{
"rules": [
{
"from_table": "source_ks.my_view",
"to_tables": ["target_ks.my_view"]
}
]
}And this view definition:
CREATE VIEW target_ks.my_view AS SELECT id, name FROM user;A query like SELECT * FROM source_ks.my_view would be internally rewritten to:
SELECT * FROM (SELECT id, name FROM target_ks.user) AS my_view;View routing rules require the schema tracker to monitor views, which means VTGate must be started with the --enable-views flag and VTTablet with the --queryserver-enable-views flag. The target view must exist in the specified keyspace for the routing rule to function correctly. For more details, see the Schema Routing Rules documentation.
Tablet targeting via USE statement
VTGate now supports routing queries to a specific tablet by alias using an extended USE statement syntax:
USE keyspace:shard@tablet_type|tablet_alias;For example, to target a specific replica tablet:
USE commerce:-80@replica|zone1-0000000100;Once set, all subsequent queries in the session route to the specified tablet until cleared with a standard USE keyspace or USE keyspace@tablet_type statement. This is useful for debugging, per-tablet monitoring, cache warming, and other operational tasks where targeting a specific tablet is required.
Note: A shard must be specified when using tablet targeting. Like shard targeting, this bypasses vindex-based routing, so use with care.
Breaking Changes
External Decompressor No Longer Read from Backup MANIFEST by Default
The external decompressor command stored in a backup's MANIFEST file is no longer used at restore time by default. Previously, when no --external-decompressor flag was provided, VTTablet would fall back to the command specified in the MANIFEST. This posed a security risk: an attacker with write access to backup storage could modify the MANIFEST to execute arbitrary commands on the tablet.
Starting in v24, the MANIFEST-based decompressor is ignored unless you explicitly opt in with the new --external-decompressor-use-manifest flag. If you rely on this behavior, add the flag to your VTTablet configuration, but be aware of the security implications.
See #19460 for details.
Minor Changes
Logging
Structured logging
Vitess now uses structured JSON logging by default. Log output is emitted as JSON to stderr. To configure the minimum log level, pass --log-level (one of debug, info, warn, error; default info). For a human-readable format with automatic color detection, pass --log-format=text. To revert to the previous glog backend, pass --log-structured=false.
glog is deprecated as of v24 and will be removed in v25.
VReplication
--shards flag for MoveTables/Reshard start and stop
The start and stop commands for MoveTables and Reshard workflows now support the --shards flag, allowing users to start or stop workflows on a specific subset of shards rather than all shards at once.
Example usage:
# Start workflow on specific shards only
vtctldclient MoveTables --target-keyspace customer --workflow commerce2customer start --shards="-80,80-"
# Stop workflow on specific shards only
vtctldclient Reshard --target-keyspace customer --workflow cust2cust stop --shards="80-"Automatic tablet retry for tablet-specific errors
VReplication workflows now automatically retry with different tablets when encountering tablet-specific errors. Previously, workflows without a cell preference would default to the local cell and could get stuck retrying the same failing tablet indefinitely.
When a tablet encounters errors like binary log purging (MySQL error 1236 or 1789) or GTID set mismatches, VReplication adds that tablet to an ignore list and tries other tablets across all cells. Once all matching tablets have been tried, the ignore list is cleared and the workflow retries from scratch.
This is particularly useful in multi-cell deployments where a tablet in the local cell may lack the required binary logs, but tablets in other cells still have them.
VTGate
Removed --grpc-send-session-in-streaming flag
The VTGate flag --grpc-send-session-in-streaming has been removed. This flag was deprecated in v22 via #17907 and defaulted to true.
The session is now always sent as the last packet in the streaming response for StreamExecute and StreamExecuteMulti RPCs. This behavior is required to support transactions in streaming and cannot be disabled.
Impact: Remove any usage of the --grpc-send-session-in-streaming flag from VTGate startup scripts or configuration.
New default for --legacy-replication-lag-algorithm flag
The VTGate flag --legacy-replication-lag-algorithm now defaults to false, disabling the legacy approach to handling replication lag by default.
Instead, a simpler algorithm purely based on low lag, high lag and minimum number of tablets is use...
Contributors
Assets 5
Vitess v23.0.3
Release of Vitess v23.0.3
Summary
This is a security focused release. It contains fixes for two recently reported CVEs along with a number of other security related fixes.
External Decompressor No Longer Read from Backup MANIFEST by Default
This is a fix for the following security advisory and associated CVE
The external decompressor command stored in a backup's MANIFEST file is no longer used at restore time by default. Previously, when no --external-decompressor flag was provided, VTTablet would fall back to the command specified in the MANIFEST. This posed a security risk: an attacker with write access to backup storage could modify the MANIFEST to execute arbitrary commands on the tablet.
Please note that this is a breaking change. Starting in v23.0.3, the MANIFEST-based decompressor is ignored unless you explicitly opt in with the new --external-decompressor-use-manifest flag. If you rely on this behavior, add the flag to your VTTablet configuration, but be aware of the security implications.
See #19460 for details.
Prevent Path Traversals Via Backup MANIFEST Files On restore
This is a fix for the following security advisory and associated CVE
We now prevent a common Path Traversal attack that someone with write access to backup storage could use to escape the target restore directory and write files to arbitrary filesystem paths via modifications to the MANIFEST.
See #19470 for details.
The entire changelog for this release can be found here.
The release includes 22 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @bcremer, @mattlord
Contributors
Assets 5
Vitess v22.0.4
Release of Vitess v22.0.4
Summary
This is a security focused release. It contains fixes for two recently reported CVEs along with a number of other security related fixes.
External Decompressor No Longer Read from Backup MANIFEST by Default
This is a fix for the following security advisory and associated CVE
The external decompressor command stored in a backup's MANIFEST file is no longer used at restore time by default. Previously, when no --external-decompressor flag was provided, VTTablet would fall back to the command specified in the MANIFEST. This posed a security risk: an attacker with write access to backup storage could modify the MANIFEST to execute arbitrary commands on the tablet.
Please note that this is a breaking change. Starting in v22.0.4, the MANIFEST-based decompressor is ignored unless you explicitly opt in with the new --external-decompressor-use-manifest flag. If you rely on this behavior, add the flag to your VTTablet configuration, but be aware of the security implications.
See #19460 for details.
Prevent Path Traversals Via Backup MANIFEST Files On restore
This is a fix for the following security advisory and associated CVE
We now prevent a common Path Traversal attack that someone with write access to backup storage could use to escape the target restore directory and write files to arbitrary filesystem paths via modifications to the MANIFEST.
See #19470 for details.
The entire changelog for this release can be found here.
The release includes 37 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @mattlord, @vitess-bot
Contributors
Assets 5
Vitess v23.0.2
Release of Vitess v23.0.2
The entire changelog for this release can be found here.
The release includes 16 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @mattlord, @vitess-bot
Contributors
Assets 5
Vitess v23.0.1
Release of Vitess v23.0.1
The entire changelog for this release can be found here.
The release includes 51 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @mattlord, @mhamza15, @systay, @timvaillancourt, @vitess-bot
Contributors
Assets 5
Vitess v22.0.3
Release of Vitess v22.0.3
The entire changelog for this release can be found here.
The release includes 40 merged Pull Requests.
Thanks to all our contributors: @app/vitess-bot, @mattlord, @mhamza15, @timvaillancourt, @vitess-bot
Contributors
Assets 5
Vitess v22.0.2
Release of Vitess v22.0.2
The entire changelog for this release can be found here.
The release includes 59 merged Pull Requests.
Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @arthurschreiber, @mattlord, @vitess-bot
