Vitess v21.0.0

Release of Vitess v21.0.0

Summary

Table of Contents

• Known Issue
  • Backup reports itself as successful despite failures
• Major Changes
  • Deprecations and Deletions
    • Deprecated VTTablet Flags
    • Deletion of deprecated metrics
    • Deprecated Metrics
  • Traffic Mirroring
  • Atomic Distributed Transaction Support
  • New VTGate Shutdown Behavior
  • Tablet Throttler: Multi-Metric support
  • Allow Cross Cell Promotion in PRS
  • Support for recursive CTEs
  • VTGate Tablet Balancer
  • Query Timeout Override
  • New Backup Engine
  • Dynamic VReplication Configuration
  • Reference Table Materialization
  • New VEXPLAIN Modes: TRACE and KEYS
  • Automatically Replace MySQL auto_increment Clauses with Vitess Sequences
  • Experimental MySQL 8.4 support
  • Current Errant GTIDs Count Metric
  • vtctldclient ChangeTabletTags
  • Support for specifying expected primary in reparents

Known Issue

Backup reports itself as successful despite failures

In this release, we identified an issue where a backup may succeed even if a file fails to be backed up.
Leading to a successful backup, even if some errors occurred.
This only happen with the Builtin Backup Engine, and when all files have already been initiated in the backup process.
For more details, please refer to the related GitHub Issue #17063.

Major Changes

Deprecations and Deletions

Deprecated VTTablet Flags

• queryserver-enable-settings-pool flag, added in v15, has been on by default since v17.
  It is now deprecated and will be removed in a future release.

Deletion of deprecated metrics

The following VTOrc metrics were deprecated in v20. They have now been deleted.

Metric Name
analysis.change.write
audit.write
discoveries.attempt
discoveries.fail
discoveries.instance_poll_seconds_exceeded
discoveries.queue_length
discoveries.recent_count
instance.read
instance.read_topology
emergency_reparent_counts
planned_reparent_counts
reparent_shard_operation_timings

Deprecated Metrics

The following metrics are now deprecated and will be deleted in a future release, please use their replacements.

Component	Metric Name	Replaced By
vttablet	QueryCacheLength	QueryEnginePlanCacheLength
vttablet	QueryCacheSize	QueryEnginePlanCacheSize
vttablet	QueryCacheCapacity	QueryEnginePlanCacheCapacity
vttablet	QueryCacheEvictions	QueryEnginePlanCacheEvictions
vttablet	QueryCacheHits	QueryEnginePlanCacheHits
vttablet	QueryCacheMisses	QueryEnginePlanCacheMisses

Traffic Mirroring

Traffic mirroring is intended to help reduce some of the uncertainty inherent to MoveTables SwitchTraffic. When
traffic mirroring is enabled, VTGate will mirror a percentage of traffic from one keyspace to another.

Mirror rules may be enabled through vtctldclient with MoveTables MirrorTraffic. For example:

$ vtctldclient --server :15999 MoveTables --target-keyspace customer --workflow commerce2customer MirrorTraffic --percent 5.0

Mirror rules can be inspected with GetMirrorRules.

Atomic Distributed Transaction Support

We have introduced atomic distributed transactions as an experimental feature.
Users can now run multi-shard transactions with stronger guarantees.
Vitess now provides two modes of transactional guarantees for multi-shard transactions: Best Effort and Atomic.
These can be selected based on the user’s requirements and the trade-offs they are willing to make.

Follow the documentation to enable Atomic Distributed Transaction

For more details on the implementation and trade-offs, please refer to the RFC

New VTGate Shutdown Behavior

We added a new option to VTGate to disallow new connections while VTGate is shutting down,
while allowing existing connections to finish their work until they manually disconnect or until
the --onterm_timeout is reached, without getting a Server shutdown in progress error.

This new behavior can be enabled by specifying the new --mysql-server-drain-onterm flag to VTGate.

You can find more information about this option in the RFC.

Tablet Throttler: Multi-Metric support

Up until v20, the tablet throttler would only monitor and use a single metric. That would be replication lag, by
default, or could be the result of a custom query. In this release, we introduce a major redesign so that the throttler
monitors and uses multiple metrics at the same time, including the above two.

The default behavior now is to monitor all metrics, but only use lag (if the custom query is undefined) or the custom
metric (if the custom query is defined). This is backwards-compatible with v20. A v20 PRIMARY is compatible with
a v21 REPLICA, and a v21 PRIMARY is compatible with a v20 REPLICA.

However, it is now possible to assign any combination of one or more metrics for a given app. The throttler
would then accept or reject the app's requests based on the health of all assigned metrics. We have provided a pre-defined
list of metrics:

• lag: replication lag based on heartbeat injection.
• threads_running: concurrent active threads on the MySQL server.
• loadavg: per core load average measured on the tablet instance/pod.
• custom: the result of a custom query executed on the MySQL server.

Each metric has a default threshold which can be overridden by the UpdateThrottlerConfig command.

The throttler also supports the catch-all "all" app name, and it is thus possible to assign metrics to all apps.
Explicit app to metric assignments will override the catch-all configuration.

Metrics are assigned a default scope, which could be self (isolated to the tablet) or shard (max, aka worst
value among shard tablets). It is further possible to require a different scope for each metric.

Allow Cross Cell Promotion in PRS

Up until now if the users wanted to promote a replica in a different cell from the current primary
using PlannedReparentShard, they had to specify the new primary with the --new-primary flag.

We have now added a new flag --allow-cross-cell-promotion that lets PlannedReparentShard choose a primary in a
different cell even if no new primary is provided explicitly.

Experimental support for recursive CTEs

We have added experimental support for recursive CTEs in Vitess. We are marking it as experimental because it is not yet
fully tested and may have some limitations. We are looking for feedback from the community to improve this feature.

VTGate Tablet Balancer

When a VTGate routes a query and has multiple available tablets for a given shard / tablet type (e.g. REPLICA), the
current default behavior routes the query with local cell affinity and round robin policy. The VTGate Tablet Balancer
provides an alternate mechanism that routes queries to maintain an even distribution of query load to each tablet, while
preferentially routing to tablets in the same cell as the VTGate.

The tablet balancer is enabled by a new flag --enable-balancer and configured by --balancer-vtgate-cells
and --balancer-keyspaces.

See the RFC for more details on the design and configuration of this feature.

Query Timeout Override

VTGate sends an authoritative query timeout to VTTablet when the QUERY_TIMEOUT_MS comment directive,
query_timeout session system variable, or query-timeout flag is set.
The order of precedence is: comment directive > session variable > VTGate flag.
VTTablet overrides its default query timeout with the value received from VTGate.
All timeouts are specified in milliseconds.

When a query is executed inside a transaction, there is an additional nuance. The actual timeout used will be the smaller
of the transaction timeout and the query timeout.

A query can also be set to have no timeout by using the QUERY_TIMEOUT_MS comment d...

Vitess v21.0.0-rc2

Release of Vitess v21.0.0

Summary

Table of Contents

• Major Changes
  • Deprecations and Deletions
    • Deprecated VTTablet Flags
    • Deletion of deprecated metrics
    • Deprecated Metrics
  • Traffic Mirroring
  • New VTGate Shutdown Behavior
  • Tablet Throttler: Multi-Metric support
  • Allow Cross Cell Promotion in PRS
  • Support for recursive CTEs
  • VTGate Tablet Balancer
  • Query Timeout Override
  • New Backup Engine
  • Dynamic VReplication Configuration
  • Reference Table Materialization
  • New VEXPLAIN Modes: TRACE and KEYS
  • Errant GTID Detection on VTTablets
  • Automatically Replace MySQL auto_increment Clauses with Vitess Sequences
  • Experimental MySQL 8.4 support
  • Current Errant GTIDs Count Metric
  • vtctldclient ChangeTabletTags
  • Support for specifying expected primary in reparents

Major Changes

Deprecations and Deletions

Deprecated VTTablet Flags

• queryserver-enable-settings-pool flag, added in v15, has been on by default since v17.
  It is now deprecated and will be removed in a future release.

Deletion of deprecated metrics

The following VTOrc metrics were deprecated in v20. They have now been deleted.

Metric Name
analysis.change.write
audit.write
discoveries.attempt
discoveries.fail
discoveries.instance_poll_seconds_exceeded
discoveries.queue_length
discoveries.recent_count
instance.read
instance.read_topology
emergency_reparent_counts
planned_reparent_counts
reparent_shard_operation_timings

Deprecated Metrics

The following metrics are now deprecated and will be deleted in a future release, please use their replacements.

Component	Metric Name	Replaced By
vttablet	QueryCacheLength	QueryEnginePlanCacheLength
vttablet	QueryCacheSize	QueryEnginePlanCacheSize
vttablet	QueryCacheCapacity	QueryEnginePlanCacheCapacity
vttablet	QueryCacheEvictions	QueryEnginePlanCacheEvictions
vttablet	QueryCacheHits	QueryEnginePlanCacheHits
vttablet	QueryCacheMisses	QueryEnginePlanCacheMisses

Traffic Mirroring

Traffic mirroring is intended to help reduce some of the uncertainty inherent to MoveTables SwitchTraffic. When
traffic mirroring is enabled, VTGate will mirror a percentage of traffic from one keyspace to another.

Mirror rules may be enabled through vtctldclient with MoveTables MirrorTraffic. For example:

$ vtctldclient --server :15999 MoveTables --target-keyspace customer --workflow commerce2customer MirrorTraffic --percent 5.0

Mirror rules can be inspected with GetMirrorRules.

New VTGate Shutdown Behavior

We added a new option to VTGate to disallow new connections while VTGate is shutting down,
while allowing existing connections to finish their work until they manually disconnect or until
the --onterm_timeout is reached, without getting a Server shutdown in progress error.

This new behavior can be enabled by specifying the new --mysql-server-drain-onterm flag to VTGate.

You can find more information about this option in the RFC.

Tablet Throttler: Multi-Metric support

Up until v20, the tablet throttler would only monitor and use a single metric. That would be replication lag, by
default, or could be the result of a custom query. In this release, we introduce a major redesign so that the throttler
monitors and uses multiple metrics at the same time, including the above two.

The default behavior now is to monitor all metrics, but only use lag (if the custom query is undefined) or the custom
metric (if the custom query is defined). This is backwards-compatible with v20. A v20 PRIMARY is compatible with
a v21 REPLICA, and a v21 PRIMARY is compatible with a v20 REPLICA.

However, it is now possible to assign any combination of one or more metrics for a given app. The throttler
would then accept or reject the app's requests based on the health of all assigned metrics. We have provided a pre-defined
list of metrics:

• lag: replication lag based on heartbeat injection.
• threads_running: concurrent active threads on the MySQL server.
• loadavg: per core load average measured on the tablet instance/pod.
• custom: the result of a custom query executed on the MySQL server.

Each metric has a default threshold which can be overridden by the UpdateThrottlerConfig command.

The throttler also supports the catch-all "all" app name, and it is thus possible to assign metrics to all apps.
Explicit app to metric assignments will override the catch-all configuration.

Metrics are assigned a default scope, which could be self (isolated to the tablet) or shard (max, aka worst
value among shard tablets). It is further possible to require a different scope for each metric.

Allow Cross Cell Promotion in PRS

Up until now if the users wanted to promote a replica in a different cell from the current primary
using PlannedReparentShard, they had to specify the new primary with the --new-primary flag.

We have now added a new flag --allow-cross-cell-promotion that lets PlannedReparentShard choose a primary in a
different cell even if no new primary is provided explicitly.

Experimental support for recursive CTEs

We have added experimental support for recursive CTEs in Vitess. We are marking it as experimental because it is not yet
fully tested and may have some limitations. We are looking for feedback from the community to improve this feature.

VTGate Tablet Balancer

When a VTGate routes a query and has multiple available tablets for a given shard / tablet type (e.g. REPLICA), the
current default behavior routes the query with local cell affinity and round robin policy. The VTGate Tablet Balancer
provides an alternate mechanism that routes queries to maintain an even distribution of query load to each tablet, while
preferentially routing to tablets in the same cell as the VTGate.

The tablet balancer is enabled by a new flag --enable-balancer and configured by --balancer-vtgate-cells
and --balancer-keyspaces.

See the RFC for more details on the design and configuration of this feature.

Query Timeout Override

VTGate sends an authoritative query timeout to VTTablet when the QUERY_TIMEOUT_MS comment directive,
query_timeout session system variable, or query-timeout flag is set.
The order of precedence is: comment directive > session variable > VTGate flag.
VTTablet overrides its default query timeout with the value received from VTGate.
All timeouts are specified in milliseconds.

When a query is executed inside a transaction, there is an additional nuance. The actual timeout used will be the smaller
of the transaction timeout and the query timeout.

A query can also be set to have no timeout by using the QUERY_TIMEOUT_MS comment directive with a value of 0.

Example usage:
select /*vt+ QUERY_TIMEOUT_MS=30 */ col from tbl

New Backup Engine (EXPERIMENTAL)

We are introducing a new backup engine for logical backups in order to support use cases that require something other
than physical backups. This feature is experimental and is based on MySQL Shell.

The new engine is enabled by using --backup_engine_implementation=mysqlshell. There are other options that are required,
so please read the documentation to learn which options are required and how to configure them.

Dynamic VReplication Configuration

Previously, many of the configuration options for VReplication Workflows had to be provided using VTTablet flags. This
meant that any change to VReplication configuration required restarting VTTablets. We now allow these to be overridden
while creating a workflow or dynamically after the workflow is already in progress.

Reference Table Materialization

There is a new option in Materialize workflows to keep a synced copy of [reference or...

Vitess v21.0.0-rc1

Release of Vitess v21.0.0

Summary

Table of Contents

• Major Changes
  • Deprecations and Deletions
    • Deprecated VTTablet Flags
    • Deletion of deprecated metrics
    • Deprecated Metrics
  • Traffic Mirroring
  • New VTGate Shutdown Behavior
  • Tablet Throttler: Multi-Metric support
  • Allow Cross Cell Promotion in PRS
  • Support for recursive CTEs
  • VTGate Tablet Balancer
  • Query Timeout Override
  • New Backup Engine
  • Dynamic VReplication Configuration
  • Reference Table Materialization
  • New VEXPLAIN Modes: TRACE and KEYS
  • Errant GTID Detection on VTTablets
  • Automatically Replace MySQL auto_increment Clauses with Vitess Sequences
  • Experimental MySQL 8.4 support
  • Current Errant GTIDs Count Metric
  • vtctldclient ChangeTabletTags

Major Changes

Deprecations and Deletions

Deprecated VTTablet Flags

• queryserver-enable-settings-pool flag, added in v15, has been on by default since v17.
  It is now deprecated and will be removed in a future release.

Deletion of deprecated metrics

The following VTOrc metrics were deprecated in v20. They have now been deleted.

Metric Name
analysis.change.write
audit.write
discoveries.attempt
discoveries.fail
discoveries.instance_poll_seconds_exceeded
discoveries.queue_length
discoveries.recent_count
instance.read
instance.read_topology
emergency_reparent_counts
planned_reparent_counts
reparent_shard_operation_timings

Deprecated Metrics

The following metrics are now deprecated and will be deleted in a future release, please use their replacements.

Component	Metric Name	Replaced By
vttablet	QueryCacheLength	QueryEnginePlanCacheLength
vttablet	QueryCacheSize	QueryEnginePlanCacheSize
vttablet	QueryCacheCapacity	QueryEnginePlanCacheCapacity
vttablet	QueryCacheEvictions	QueryEnginePlanCacheEvictions
vttablet	QueryCacheHits	QueryEnginePlanCacheHits
vttablet	QueryCacheMisses	QueryEnginePlanCacheMisses

Traffic Mirroring

Traffic mirroring is intended to help reduce some of the uncertainty inherent to MoveTables SwitchTraffic. When
traffic mirroring is enabled, VTGate will mirror a percentage of traffic from one keyspace to another.

Mirror rules may be enabled through vtctldclient with MoveTables MirrorTraffic. For example:

$ vtctldclient --server :15999 MoveTables --target-keyspace customer --workflow commerce2customer MirrorTraffic --percent 5.0

Mirror rules can be inspected with GetMirrorRules.

New VTGate Shutdown Behavior

We added a new option to VTGate to disallow new connections while VTGate is shutting down,
while allowing existing connections to finish their work until they manually disconnect or until
the --onterm_timeout is reached, without getting a Server shutdown in progress error.

This new behavior can be enabled by specifying the new --mysql-server-drain-onterm flag to VTGate.

You can find more information about this option in the RFC.

Tablet Throttler: Multi-Metric support

Up until v20, the tablet throttler would only monitor and use a single metric. That would be replication lag, by
default, or could be the result of a custom query. In this release, we introduce a major redesign so that the throttler
monitors and uses multiple metrics at the same time, including the above two.

The default behavior now is to monitor all metrics, but only use lag (if the custom query is undefined) or the custom
metric (if the custom query is defined). This is backwards-compatible with v20. A v20 PRIMARY is compatible with
a v21 REPLICA, and a v21 PRIMARY is compatible with a v20 REPLICA.

However, it is now possible to assign any combination of one or more metrics for a given app. The throttler
would then accept or reject the app's requests based on the health of all assigned metrics. We have provided a pre-defined
list of metrics:

• lag: replication lag based on heartbeat injection.
• threads_running: concurrent active threads on the MySQL server.
• loadavg: per core load average measured on the tablet instance/pod.
• custom: the result of a custom query executed on the MySQL server.

Each metric has a default threshold which can be overridden by the UpdateThrottlerConfig command.

The throttler also supports the catch-all "all" app name, and it is thus possible to assign metrics to all apps.
Explicit app to metric assignments will override the catch-all configuration.

Metrics are assigned a default scope, which could be self (isolated to the tablet) or shard (max, aka worst
value among shard tablets). It is further possible to require a different scope for each metric.

Allow Cross Cell Promotion in PRS

Up until now if the users wanted to promote a replica in a different cell from the current primary
using PlannedReparentShard, they had to specify the new primary with the --new-primary flag.

We have now added a new flag --allow-cross-cell-promotion that lets PlannedReparentShard choose a primary in a
different cell even if no new primary is provided explicitly.

Experimental support for recursive CTEs

We have added experimental support for recursive CTEs in Vitess. We are marking it as experimental because it is not yet
fully tested and may have some limitations. We are looking for feedback from the community to improve this feature.

VTGate Tablet Balancer

When a VTGate routes a query and has multiple available tablets for a given shard / tablet type (e.g. REPLICA), the
current default behavior routes the query with local cell affinity and round robin policy. The VTGate Tablet Balancer
provides an alternate mechanism that routes queries to maintain an even distribution of query load to each tablet, while
preferentially routing to tablets in the same cell as the VTGate.

The tablet balancer is enabled by a new flag --enable-balancer and configured by --balancer-vtgate-cells
and --balancer-keyspaces.

See the RFC for more details on the design and configuration of this feature.

Query Timeout Override

VTGate sends an authoritative query timeout to VTTablet when the QUERY_TIMEOUT_MS comment directive,
query_timeout session system variable, or query-timeout flag is set.
The order of precedence is: comment directive > session variable > VTGate flag.
VTTablet overrides its default query timeout with the value received from VTGate.
All timeouts are specified in milliseconds.

When a query is executed inside a transaction, there is an additional nuance. The actual timeout used will be the smaller
of the transaction timeout and the query timeout.

A query can also be set to have no timeout by using the QUERY_TIMEOUT_MS comment directive with a value of 0.

Example usage:
select /*vt+ QUERY_TIMEOUT_MS=30 */ col from tbl

New Backup Engine (EXPERIMENTAL)

We are introducing a new backup engine for logical backups in order to support use cases that require something other
than physical backups. This feature is experimental and is based on MySQL Shell.

The new engine is enabled by using --backup_engine_implementation=mysqlshell. There are other options that are required,
so please read the documentation to learn which options are required and how to configure them.

Dynamic VReplication Configuration

Previously, many of the configuration options for VReplication Workflows had to be provided using VTTablet flags. This
meant that any change to VReplication configuration required restarting VTTablets. We now allow these to be overridden
while creating a workflow or dynamically after the workflow is already in progress.

Reference Table Materialization

There is a new option in Materialize workflows to keep a synced copy of reference or lookup tables
(countries,...

Vitess v20.0.2

Release of Vitess v20.0.2

The entire changelog for this release can be found here.

The release includes 25 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @shlomi-noach, @vitess-bot

Vitess v19.0.6

Release of Vitess v19.0.6

The entire changelog for this release can be found here.

The release includes 21 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @shlomi-noach, @systay, @vitess-bot

Vitess v18.0.7

Release of Vitess v18.0.7

The entire changelog for this release can be found here.

Known Issues

VTTablet runs an unnecessary DDL

In this release, with MySQL 8.0 whenever VTTablet's tabletserver goes through initialization, it finds
a diff in its internal schemacopy table and tries to apply a DDL to fix it. The DDL
is a no-op and this loop of applying the DDL continues to run.
If this problem is encountered, the following PR should be reverted to resolve it - #15859.

The release includes 23 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @frouioui, @shlomi-noach, @vitess-bot

Vitess v20.0.1

Release of Vitess v20.0.1

The entire changelog for this release can be found here.

The release includes 21 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @frouioui, @shlomi-noach, @vitess-bot

Vitess v19.0.5

Release of Vitess v19.0.5

The entire changelog for this release can be found here.

The release includes 40 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @harshit-gangal, @systay, @vitess-bot

Vitess v18.0.6

Release of Vitess v18.0.6

The entire changelog for this release can be found here.

Known Issues

VTTablet runs an unnecessary DDL

In this release, with MySQL 8.0 whenever VTTablet's tabletserver goes through initialization, it finds
a diff in its internal schemacopy table and tries to apply a DDL to fix it. The DDL
is a no-op and this loop of applying the DDL continues to run.
If this problem is encountered, the following PR should be reverted to resolve it - #15859.

The release includes 28 merged Pull Requests.

Thanks to all our contributors: @GuptaManan100, @app/vitess-bot, @arthurschreiber, @shlomi-noach, @vitess-bot

Vitess v20.0.0

Release of Vitess v20.0.0

Summary

Table of Contents

• Major Changes

  • Deletions
    • --vreplication_tablet_type flag
    • Pool Capacity Flags
    • vitess/base and vitess/k8s Docker images
    • gh-ost binary and endtoend tests
    • Legacy EmergencyReparentShard stats
  • Breaking changes
    • Metric Name Changes in VTOrc
    • ENUM and SET column handling in VTGate VStream API
    • shutdown_grace_period Default Change
    • New unmanaged Flag and disable_active_reparents deprecation
    • recovery-period-block-duration Flag deprecation
    • mysqlctld onterm-timeout Default Change
    • MoveTables now removes auto_increment clauses by default when moving tables from an unsharded keyspace to a sharded one
    • Durabler interface method renaming
  • Query Compatibility
    • Vindex Hints
    • Update with Limit Support
    • Update with Multi Table Support
    • Update with Multi Target Support
    • Delete with Subquery Support
    • Delete with Multi Target Support
    • User Defined Functions Support
    • Insert Row Alias Support
  • VReplication
    • Multi-tenant Imports
    • VDiff Support For OnlineDDL Migrations
  • Query Timeout
  • Flag changes
    • pprof-http default change
    • New healthcheck-dial-concurrency flag
    • New minimum for --buffer_min_time_between_failovers
    • New track-udfs vtgate flag
    • Help text fix for --lock-timeout
    • New --querylog-sample-rate flag
    • New --tablet-filter-tags flag

• Minor Changes

  • New Stats
    • VTTablet Query Cache Hits and Misses
    • VTGate and VTTablet Query Text Characters Processed
  • SIGHUP reload of gRPC client static auth creds
  • VTAdmin
    • Updated to node v20.12.2
    • Replaced highcharts with d3

Major Changes

Deletion

--vreplication_tablet_type flag

The previously deprecated flag --vreplication_tablet_type has been deleted.

Pool Capacity Flags

The previously deprecated flags --queryserver-config-query-pool-waiter-cap, --queryserver-config-stream-pool-waiter-cap and --queryserver-config-txpool-waiter-cap have been deleted.

vitess/base and vitess/k8s Docker images

Since we have deleted MySQL from our vitess/lite image, we are removing the vitess/base and vitess/k8s images.

These images are no longer useful since we can use vitess/lite as the base of many other Docker images (vitess/vtgate, vitess/vtgate, ...).

gh-ost binary and endtoend tests

Vitess 20.0 drops support for gh-ost DDL strategy.

vttablet binary no longer embeds a gh-ost binary. Users of gh-ost DDL strategy will need to supply a gh-ost binary on the vttablet host or pod. Vitess will look for the gh-ost binary in the system PATH; otherwise the user should supply vttablet --gh-ost-path.

Vitess' endtoend tests no longer use nor test gh-ost migrations.

Legacy EmergencyReparentShard stats

The following EmergencyReparentShard stats were deprecated in Vitess 18.0 and are removed in Vitess 20.0:

• ers_counter
• ers_success_counter
• ers_failure_counter

These counters are replaced by the following stats (introduced in Vitess 18.0):

• emergency_reparent_counts - Number of times EmergencyReparentShard has been run. It is further subdivided by the keyspace, shard and the result of the operation.
• planned_reparent_counts - Number of times PlannedReparentShard has been run. It is further subdivided by the keyspace, shard and the result of the operation.

Also, the reparent_shard_operation_timings stat was added to provide per-operation timings of reparent operations.

Breaking Changes

Metric Name Changes in VTOrc

The following metric names have been changed in VTOrc. The old metrics are still available in /debug/vars for this release, but will be removed in later releases. The new metric names and the deprecated metric names resolve to the same metric name on prometheus, so there is no change there.

Old Metric Name	New Metric Name	Name in Prometheus
analysis.change.write	AnalysisChangeWrite	vtorc_analysis_change_write
audit.write	AuditWrite	vtorc_audit_write
discoveries.attempt	DiscoveriesAttempt	vtorc_discoveries_attempt
discoveries.fail	DiscoveriesFail	vtorc_discoveries_fail
discoveries.instance_poll_seconds_exceeded	DiscoveriesInstancePollSecondsExceeded	vtorc_discoveries_instance_poll_seconds_exceeded
discoveries.queue_length	DiscoveriesQueueLength	vtorc_discoveries_queue_length
discoveries.recent_count	DiscoveriesRecentCount	vtorc_discoveries_recent_count
instance.read	InstanceRead	vtorc_instance_read
instance.read_topology	InstanceReadTopology	vtorc_instance_read_topology
emergency_reparent_counts	EmergencyReparentCounts	vtorc_emergency_reparent_counts
planned_reparent_counts	PlannedReparentCounts	vtorc_planned_reparent_counts
reparent_shard_operation_timings	ReparentShardOperationTimings	vtorc_reparent_shard_operation_timings_bucket

ENUM and SET column handling in VTGate VStream API

The VTGate VStream API now returns ENUM and SET column type values in VEvent messages (in the embedded RowChange messages) as their string values instead of the integer based ones — in both the copy/snapshot phase and the streaming phase. This change was done to make the VStream API more user-friendly, intuitive, and to align the behavior across both phases. Before this change the values for ENUM and SET columns were string values in the copy phase but integer values (which only have an internal meaning to MySQL) in the streaming phase. This inconsistency led to various challenges and issues for each VStream client/consumer (e.g. the Debezium Vitess connector failed to properly perform a snapshot for tables containing these column types). Now the behavior is intuitive — clients need the string values as the eventual sink is often not MySQL so each consumer needed to perform the mappings themselves — and consistent. While this is a (potentially) breaking change, a new boolean field has been added to the FieldEvent message called EnumSetStringValues. When that field is false (in Vitess v19 and older) then the consumer will need to perform the mappings during streaming phase, but not during copy phase. When this field is true, then no mapping is required. This will help to ensure a smooth transition for all consumers over time. To demonstrate, let's look at the textual output (printing the received VEvents as strings) when streaming a single enum_set_test table from the unsharded commerce keyspace so that we can see what the VStream looks like before and after when we star...