changelog/10.0/10.0.0/release_notes.md
This release complies with VEP-3 which removes the upgrade order requirement. Components can be upgraded in any order. It is recommended that the upgrade order should still be followed if possible, except to canary test the new version of VTGate before upgrading the rest of the components.
Running binaries with --version or running select @@version from a MySQL client still shows 10.0.0-RC1
Online DDL cannot be used if you are using the keyspace filtering feature of VTGate
VReplication errors when a fixed-length binary column is used as the sharding key #8080
A critical vulnerability CVE-2021-44228 in the Apache Log4j logging library was disclosed on Dec 9 2021.
The project provided release 2.15.0 with a patch that mitigates the impact of this CVE. It was quickly found that the initial patch was insufficient, and additional CVEs
CVE-2021-45046 and CVE-2021-44832 followed.
These have been fixed in release 2.17.1. This release of Vitess, v10.0.0, uses a version of Log4j below 2.17.1, for this reason, we encourage you to use version v10.0.5 instead, to benefit from the vulnerability patches.
An issue where the value of the -force flag is used instead of -keep_data flag's value in v2 vreplication workflows (#9174) is known to be present in this release. A workaround is available in the description of issue #9174.
select current_user() #7705SilenceErrors on the root command, so we don't double-log #7404maxReplPosSearch struct out to topotools #7420ErrorGroup to package concurrency, use in waitOnNMinusOneTablets #7429EmergencyReparentShard logic to dedicated struct and add unit tests #7464RebuildKeyspaceGraph command #7442SetMaster, or fail #7486Vitess 10.0 introduces a highly-experimental multi-cluster admin API and web UI, called VTAdmin. Deploying the vtadmin-api and vtadmin-web components is completely opt-in. If you're interested in trying it out and providing early feedback, come find us in #feat-vtadmin in the Vitess slack. Note that VTAdmin relies on the new VtctldServer API, so you must be running the new grpc-vtctld service on your vtctlds in order to use it.
cluster field to vtadmin-api's /api/gates response #7425As part of an ongoing effort to transition from the VtctlServer gRPC API to the newer VtctldServer gRPC API, we have updated the local example to use the corresponding new vtctldclient to perform InitShardPrimary (formerly, InitShardMaster) operations.
To enable the new VtctldServer in your vtctld components, update the -service_map flag to include grpc-vtctld. You may specify both grpc-vtctl,grpc-vtctld to gracefully transition.
The migration is still underway, but you may begin to transition to the new client for migrated commands. For a full listing, refer either to proto/vtctlservice.proto or consult vtctldclient --help.