vitess 20.0.0 #175747
Merged
vitess 20.0.0 #175747
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
go
chenrui333
approved these changes
Jun 27, 2024
|
🤖 An automated task has requested bottles to be published to this PR. |
github-actions
bot
added
the
CI-published-bottle-commits
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bumpCreated with
brew bump-formula-pr.release notes
Major Changes
--vreplication_tablet_typeflaggh-ostbinary and endtoend testsEmergencyReparentShardstatsshutdown_grace_periodDefault ChangeunmanagedFlag anddisable_active_reparentsdeprecationrecovery-period-block-durationFlag deprecationmysqlctldonterm-timeoutDefault ChangeMoveTablesnow removesauto_incrementclauses by default when moving tables from an unsharded keyspace to a sharded oneDurablerinterface method renamingpprof-httpdefault changehealthcheck-dial-concurrencyflag--buffer_min_time_between_failoverstrack-udfsvtgate flag--lock-timeout--querylog-sample-rateflag--tablet-filter-tagsflagMinor Changes
SIGHUPreload of gRPC client static auth credsMajor Changes
Deletion
--vreplication_tablet_typeflagThe previously deprecated flag
--vreplication_tablet_typehas been deleted.Pool Capacity Flags
The previously deprecated flags
--queryserver-config-query-pool-waiter-cap,--queryserver-config-stream-pool-waiter-capand--queryserver-config-txpool-waiter-caphave been deleted.vitess/baseandvitess/k8sDocker imagesSince we have deleted MySQL from our
vitess/liteimage, we are removing thevitess/baseandvitess/k8simages.These images are no longer useful since we can use
vitess/liteas the base of many other Docker images (vitess/vtgate,vitess/vtgate, ...).gh-ostbinary and endtoend testsVitess 20.0 drops support for
gh-ostDDL strategy.vttabletbinary no longer embeds agh-ostbinary. Users ofgh-ostDDL strategy will need to supply agh-ostbinary on thevttablethost or pod. Vitess will look for thegh-ostbinary in the systemPATH; otherwise the user should supplyvttablet --gh-ost-path.Vitess' endtoend tests no longer use nor test
gh-ostmigrations.Legacy
EmergencyReparentShardstatsThe following
EmergencyReparentShardstats were deprecated in Vitess 18.0 and are removed in Vitess 20.0:ers_counterers_success_counterers_failure_counterThese counters are replaced by the following stats (introduced in Vitess 18.0):
emergency_reparent_counts- Number of timesEmergencyReparentShardhas been run. It is further subdivided by the keyspace, shard and the result of the operation.planned_reparent_counts- Number of timesPlannedReparentShardhas been run. It is further subdivided by the keyspace, shard and the result of the operation.Also, the
reparent_shard_operation_timingsstat 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/varsfor 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.analysis.change.writeAnalysisChangeWritevtorc_analysis_change_writeaudit.writeAuditWritevtorc_audit_writediscoveries.attemptDiscoveriesAttemptvtorc_discoveries_attemptdiscoveries.failDiscoveriesFailvtorc_discoveries_faildiscoveries.instance_poll_seconds_exceededDiscoveriesInstancePollSecondsExceededvtorc_discoveries_instance_poll_seconds_exceededdiscoveries.queue_lengthDiscoveriesQueueLengthvtorc_discoveries_queue_lengthdiscoveries.recent_countDiscoveriesRecentCountvtorc_discoveries_recent_countinstance.readInstanceReadvtorc_instance_readinstance.read_topologyInstanceReadTopologyvtorc_instance_read_topologyemergency_reparent_countsEmergencyReparentCountsvtorc_emergency_reparent_countsplanned_reparent_countsPlannedReparentCountsvtorc_planned_reparent_countsreparent_shard_operation_timingsReparentShardOperationTimingsvtorc_reparent_shard_operation_timings_bucketENUM and SET column handling in VTGate VStream API
The VTGate VStream API now returns
ENUMandSETcolumn type values inVEventmessages (in the embeddedRowChangemessages) 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 theVStreamAPI more user-friendly, intuitive, and to align the behavior across both phases. Before this change the values forENUMandSETcolumns 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 eachVStreamclient/consumer (e.g. theDebeziumVitess 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 theFieldEventmessage calledEnumSetStringValues. When that field isfalse(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 istrue, 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 receivedVEventsas strings) when streaming a singleenum_set_testtable from the unshardedcommercekeyspace so that we can see what the VStream looks like before and after when we start a new VStream in copy/snapshot mode and then transition to streaming mode for the following table:And with the table having this data when we start our
VStreamand begin the copy/snapshot phase:And finally we will perform the following inserts and updates to the table during the streaming phase:
Vitess v19 and older:
Vitess v20 and newer:
An example key difference there being that
after:{lengths:1 lengths:9 lengths:1 lengths:3 values:"2Sally Mae1147"}from Vitess v19 and older becomesafter:{lengths:1 lengths:9 lengths:5 lengths:31 values:"2Sally Maesmallknitting,cooking,hiking,reading"}from Vitess v20 and newer. So1->smalland147->knitting,cooking,hiking,readingfor theENUMandSETcolumn values respectively. This also demonstrates why this mapping is necessary in consumers/clients, as147has no logical meaning/value for this column outside of MySQL internals.If you're using the
DebeziumVitess connector, you should upgrade your connector to 2.7 (the next release) — which should contain the relevant necessary changes — prior to upgrading Vitess to v20.0.1 or later. If you're using any of the PlanetScale connectors (AirByte,FiveTran, orsinger-tap) then no actions are required.If you're using a custom
VStreamclient/consumer, then you will need to build a new client with the updated v20 binlogdata protos (source for which would be inmainor therelease-20.0branch) before needing to support Vitess v20.0.1 or later. Your client will then be able to handle old and new messages, with older messages always having this new field set tofalse.shutdown_grace_periodDefault ChangeThe
--shutdown_grace_periodflag, which was introduced in v2 with a default of0 seconds, has now been changed to default to3 seconds.This makes reparenting in Vitess resilient to client errors, and prevents PlannedReparentShard from timing out.
In order to preserve the old behaviour, the users can set the flag back to
0 secondscausing open transactions to never be shutdown, but in that case, they run the risk of PlannedReparentShard calls timing out.New
unmanagedFlag anddisable_active_reparentsdeprecationNew flag
--unmanagedhas been introduced in this release to make it easier to flag unmanaged tablets. It also runs validations to make sure the unmanaged tablets are configured properly.--disable_active_reparentsflag has been deprecated forvttablet,vtcomboandvttestserverbinaries and will be removed in future releases. Specifying the--unmanagedflag will also block replication commands and replication repairs.Starting this release, all unmanaged tablets should specify this flag.
recovery-period-block-durationFlag deprecationThe flag
--recovery-period-block-durationhas been deprecated in VTOrc from this release. Its value is now ignored and the flag will be removed in later releases.VTOrc no longer blocks recoveries for a certain duration after a previous recovery has completed. Since VTOrc refreshes the required information after
acquiring a shard lock, blocking of recoveries is not required.
mysqlctldonterm_timeoutDefault ChangeThe
--onterm_timeoutflag default value has changed formysqlctld. It now is by default long enough to be able to wait for the default--shutdown-wait-timewhen shutting down on aTERMsignal.This is necessary since otherwise MySQL would never shut down cleanly with the old defaults, since
mysqlctldwould shut down already after 10 seconds by default.MoveTablesnow removesauto_incrementclauses by default when moving tables from an unsharded keyspace to a sharded oneA new
--remove-sharded-auto-incrementflag has been added to theMoveTablescreate sub-command and it is set totrueby default. This flag controls whether any MySQLauto_incrementclauses should be removed from the table definitions when moving tables from an unsharded keyspace to a sharded one. This is now done by default asauto_incrementclauses should not typically be used with sharded tables and you should instead rely on externally generated values such as a form of universally/globally unique identifiers or use Vitess sequences in order to ensure that each row has a unique identifier (Primary Key value) across all shards. If for some reason you want to retain them you can set this new flag tofalsewhen creating the workflow.Durablerinterface method renamingThe methods of the
Durablerinterface ingo/vt/vtctl/reparentutilwere renamed to be public (capitalized) methods to make it easier to integrate custom Durability Policies from external packages. See RFC for details.Users of custom Durability Policies must rename private
Durablermethods.Changes:
promotionRulemethod was renamed toPromotionRulesemiSyncAckersmethod was renamed toSemiSyncAckersisReplicaSemiSyncmethod was renamed toIsReplicaSemiSyncQuery Compatibility
Vindex Hints
Vitess now supports Vindex hints that provide a way for users to influence the shard routing of queries in Vitess by specifying, which vindexes should be considered or ignored by the query planner. This feature enhances the control over query execution, allowing for potentially more efficient data access patterns in sharded databases.
Example:
For more information about Vindex hints and its usage, please consult the documentation.
Update with Limit Support
Support is added for sharded update with limit.
Example:
update t1 set t1.foo = 'abc', t1.bar = 23 where t1.baz > 5 limit 1The support is built on performing a selection of primary keys and then performing an update with those primary keys.
For query syntax, refer to the MySQL Docs
Update with Multi Table Support
Support is added for sharded multi-table update with column update on single target table using multiple table join.
Example:
update t1 join t2 on t1.id = t2.id join t3 on t1.col = t3.col set t1.baz = 'abc', t1.apa = 23 where t3.foo = 5 and t2.bar = 7The support is built on performing a selection of primary keys and then performing an update with those primary keys.
For query syntax, refer to the MySQL Docs
Update with Multi Target Support
Support is added for sharded multi table target update.
Example:
update t1 join t2 on t1.id = t2.id set t1.foo = 'abc', t2.bar = 23The support is built on performing a selection of primary keys from all target tables and
then performing an update for each table with their selected primary keys.
For query syntax, refer to the MySQL Docs
Delete with Subquery Support
Support is added for sharded table delete with subquery
Example:
delete from t1 where id in (select col from t2 where foo = 32 and bar = 43)The support is built by performing the uncorrelated subquery first and then providing the value for deletion.
Delete with Multi Target Support
Support is added for sharded multi table target delete.
Example:
delete t1, t3 from t1 join t2 on t1.id = t2.id join t3 on t1.col = t3.colThe support is built on performing a selection of primary keys from all target tables and
then performing a delete operation for each table with their selected primary keys.
For query syntax, refer to the MySQL Docs
User Defined Functions Support
VTGate can track any user defined functions for better planning.
User Defined Functions (UDFs) should be directly loaded in the underlying MySQL.
It should be enabled in VTGate with the
--track-udfsflag.This will enable the tracking of UDFs in VTGate and will be used for planning.
Without this flag, VTGate will not be aware that there might be aggregating user-defined functions in the query that need to be pushed down to MySQL.
More details about how to load UDFs is available in MySQL Docs
Insert Row Alias Support
Support is added to have row alias in Insert statement to be used with
on duplicate key update.Example:
insert into user(id, name, email) valies (100, 'Alice', '[email protected]') as new on duplicate key update name = new.name, email = new.emailinsert into user(id, name, email) valies (100, 'Alice', '[email protected]') as new(m, n, p) on duplicate key update name = n, email = pFor query syntax, refer to the MySQL Docs
Query Timeout
On a query timeout, Vitess closed the connection using the
kill connectionstatement. This leads to connection churnwhich is not desirable in some cases. To avoid this, Vitess now uses the
kill querystatement to cancel the query.This will only cancel the query and does not terminate the connection.
Flag Changes
pprof-httpDefault ChangeThe
--pprof-httpflag, which was introduced in v19 with a default oftrue, has now been changed to default tofalse.This makes HTTP
pprofendpoints now an opt-in feature, rather than opt-out.To continue enabling these endpoints, explicitly set
--pprof-httpwhen starting up Vitess components.New
--healthcheck-dial-concurrencyflagThe new
--healthcheck-dial-concurrencyflag defines the maximum number of healthcheck connections that can open concurrently. This limit is to avoid hitting Go runtime panics on deployments watching enough tablets to hit the runtime's maximum thread limit of10000due to blocking network syscalls. This flag applies tovtcombo,vtctldandvtgateonly and a value less than the runtime max thread limit (10000) is recommended.New minimum for
--buffer_min_time_between_failoversThe
--buffer_min_time_between_failoversvttabletflag now has a minimum value of1s. This is because a value of 0 can cause issues with the buffering mechanics resulting in unexpected and unnecessary query errors — in particular duringMoveTables SwitchTrafficoperations. If you are currently specifying a value of 0 for this flag then you will need to update the config value to 1s prior to upgrading to v20 or later asvttabletwill report an error and terminate if you attempt to start it with a value of 0.New
--track-udfsvtgate flagThe new
--track-udfsflag enables VTGate to track user defined functions for better planning.Help text fix for
--lock-timeoutThe help text for the flag
--lock-timeoutwas incorrect. We were documenting it as a flag that controlled the duration for which the shard lock was acquired. It is actually the maximum duration for which we wait while attempting to acquire a lock from the topology server.New
--querylog-sample-rateflagThe new flag
--querylog-sample-rate floatadds support for sampling queries based on a float value between 0.0 (no logging) and 1.0 (all queries logged). If configured, this filtering is applied after the existing--querylog-filter-tagfilter.New
--tablet-filter-tagsflagThe new flag
--tablet-filter-tags StringMapadds support to VTGate for filtering tablets by tablet tag key/values, specified as comma-separated list of key:values. The tags of a tablet are defined by the VTTablet flag--init_tags, which is also defined as a comma-separated list of key:values.VReplication
Multi-tenant Imports
Support for multi-tenant imports has been added to
MoveTables. If you have a multi-tenant architecture where eachtenant has their own database, you can import the tenants using multiple
MoveTablesworkfows, one per tenant.Each import is initiated with the new
--tenant-idflag. The column name (and data type) need to be specified inthe VSchema of the target keyspace.
VDiff support for OnlineDDL migrations
You can now run
VDiffs on OnlineDDL schema change migrations, which are not yet cut over.Minor Changes
New Stats
VTTablet Query Cache Hits and Misses
VTTablet exposes two new counter stats:
QueryCacheHits: Query engine query cache hitsQueryCacheMisses: Query engine query cache missesVTTablet Query Text Characters Processed
VTGate and VTTablet expose a new counter stat
QueryTextCharactersProcessedto reflect the number of query text characters processed.VTGate groups this metric by Operation, Keyspace and TabletType. On VTTablet it is grouped by Table, Plan and optionally Workload.
SIGHUPreload of gRPC client static auth credsThe internal gRPC client now caches the static auth credentials and supports reloading via the
SIGHUPsignal. Previous to v20 the credentials were not cached. They were re-loaded from disk on every use.VTAdmin
vtadmin-web updated to node v20.12.2 (LTS)
Building
vtadmin-webnow requires node >= v20.12.0 (LTS). Breaking changes from v18 to v20 can be found at https://nodejs.org/en/blog/release/v20.12.0 -- with no known issues that apply to VTAdmin.Full details on the node v20.12.2 release can be found at https://nodejs.org/en/blog/release/v20.12.2.
Replaced highcharts with d3
The vtadmin-web UI no longer has a dependency on highcharts for licensing reasons. The tablet QPS, tablet VReplication QPS, and workflow streams lag charts have all been replaced by d3. We'll be iteratively improving the d3 charts until they reach feature parity with the original highcharts charts.
The entire changelog for this release can be found here.
The release includes 419 merged Pull Requests.
Thanks to all our contributors: @Aoang, @Ari1009, @GuptaManan100, @Its-Maniaco, @Maniktherana, @VaibhavMalik4187, @ajm188, @aparajon, @app/dependabot, @app/github-actions, @app/vitess-bot, @arthurschreiber, @bddicken, @beingnoble03, @brendar, @crazeteam, @dbussink, @deepthi, @demmer, @derekperkins, @ejortegau, @frouioui, @harshit-gangal, @mattlord, @maxenglander, @mdlayher, @notfelineit, @pavedroad, @rafer, @rohit-nayak-ps, @rvrangel, @shlomi-noach, @systay, @timvaillancourt, @tycol7, @vitess-bot, @vmg, @wangweicugw, @whuang8, @yoheimuta