vitess

Release of Vitess v23.0.8

Summary

Unsupported sql_mode values are rejected

VTGate

VTGate already rejected SET sql_mode = ... statements that enable a mode the Vitess parser does not support (ANSI_QUOTES, NO_BACKSLASH_ESCAPES, PIPES_AS_CONCAT, REAL_AS_FLOAT). The check compared mode names textually and could be bypassed. VTGate now implements MySQL 8.x's sql_mode assignment semantics and validates every assignment against them:

• Setting an unsupported mode is rejected even when the underlying MySQL already runs with that mode, that is, when the SET would not change the value. Such statements previously succeeded, even though VTGate does not parse queries under these modes. The combination mode ANSI is rejected as well, because it enables ANSI_QUOTES, PIPES_AS_CONCAT, and REAL_AS_FLOAT.
• IGNORE_SPACE and HIGH_NOT_PRECEDENCE are now also rejected. They are the two remaining modes that change how SQL text is interpreted. The Vitess parser does not honor them, so VTGate would parse queries differently than the session's sql_mode promises.
• Unknown mode names and invalid numeric values fail with MySQL's own errors: ER_WRONG_VALUE_FOR_VAR (1231), and ER_UNSUPPORTED_SQL_MODE (3899) for the bits of modes removed in MySQL 8.0.
• Numeric values decode against MySQL's sql_mode bitmask. For example, SET sql_mode = 1048576 reports that NO_BACKSLASH_ESCAPES is unsupported. Valid numeric values are accepted.
• Constant values are validated at planning time, with no shard round trip. This includes constant expressions such as CONCAT over literals, and it also applies when --enable-system-settings is disabled. Non-constant expressions are validated at execution time, once their value is known.

VTTablet

VTTablet applies the same validation at its own entry points and returns the same errors: connection settings, on the settings pool and on reserved connections, and session-scope SET sql_mode statements. This covers clients that bypass VTGate's validation, such as VTGates that are not upgraded yet and clients that talk to the query service directly. SET_VAR optimizer hints are forwarded to MySQL unchanged.

Every MySQL connection Vitess creates now strips the modes that change how SQL text is interpreted from the session sql_mode it inherits from the server's global value. All other modes, such as the strict modes and the zero-date modes, are kept. This applies to every component: query serving, schema tracking, heartbeats, replication management, Online DDL, VReplication and VDiff, and connections to external MySQL servers. The global sql_mode is not changed.

Impact

• Clients that run SET sql_mode with an unsupported mode, including ANSI, IGNORE_SPACE and HIGH_NOT_PRECEDENCE, now receive an error. This also happens when the SET matches the backend's current sql_mode. Clients that set mode names MySQL would itself reject receive an error as well.
• During a rolling upgrade, VTTablets are typically upgraded before VTGates. A session that sets a now-rejected sql_mode through a VTGate that is not upgraded yet starts receiving errors from upgraded VTTablets.
• A backend whose global sql_mode includes one of these modes keeps it, but Vitess sessions no longer inherit it.

See #20883 for details.

Table ACL: callers with every role on every table may run statements whose tables cannot be determined

v23.0.7 began denying, under strict table ACL (--queryserver-config-strict-table-acl), statements whose tables vttablet cannot determine (DO, CALL, REPAIR, OPTIMIZE, LOAD DATA, and a CREATE TABLE that vttablet's parser cannot fully parse) for every caller outside the exempt ACL (--queryserver-config-acl-exempt-acl); see GHSA-w6mx-2f8x-pqf4. A caller that is a reader, a writer and an admin in a table group cover

Release of Vitess v24.0.4

Summary

lz4 backup engine: library upgrade and --compression-level mapping

The lz4 compression engine now uses the pierrec/lz4/v4 library instead of pierrec/lz4 v2. This fixes broken block decoding on amd64 in the v2 library. The frame format is unchanged, so backups written by older Vitess versions remain restorable and backups written by this version are restorable by older versions.

The upgrade changes how --compression-level is interpreted for the lz4 engine. Values 0 and 1, including the default of 1, select the fast compressor; 1 previously requested a hash-chain search depth of 1. Values 2 through 9 now select lz4's named hash-chain levels (Level2 through Level9) instead of using the raw value as the hash-chain search depth, so higher values produce a better ratio at more CPU cost. Negative values, which previously requested an unlimited search, and values above 9, which were used as the search depth, select Level9. Other compression engines are not affected.

See #20778 for details.

Connections whose certificate revocation cannot be checked against a configured CRL are rejected

The certificate revocation lists configured with --grpc-crl, --mysql-server-ssl-crl, --tablet-grpc-crl, --vtgate-grpc-crl, and the other *-crl flags are now enforced in every SSL mode and on resumed TLS sessions, see GHSA-fxqj-c35w-x6rq. Each certificate of the peer's verified chain, except the trust anchor the chain ends at, is checked against the CRLs signed by its issuer, the next certificate of the chain.

Connections that are now rejected

In the preferred and required SSL modes, the server's certificate chain is otherwise not verified. A client with a CRL now builds that chain to the configured CA, or to the system roots when no CA is configured, and rejects the connection when the chain cannot be built or verified, rather than leave the CRL unchecked. For example:

• A client in required mode with a CRL but no CA file, connecting to a server whose certificate a private CA issued.
• A client with a CRL and the root CA configured, connecting to a server that presents its certificate without the intermediate CA that issued it.
• A client with a CRL connecting to a server whose certificate has expired or is not valid for server authentication, which these modes accept without a CRL.

To keep such connections working, configure the CA that the server's chain leads to, have the server present its whole chain and a valid certificate, or drop the CRL.

A gRPC client with a CRL configured (--tablet-grpc-crl, --vtgate-grpc-crl, --vtctld-grpc-crl, and the other *-grpc-crl flags) but neither a client certificate nor a CA now connects with TLS, verifying the server against the system roots, rather than in plaintext with the CRL silently ignored. Configure the CA along with the CRL, or drop the CRL.

Configurations that are refused at startup

The following configurations are now refused when the TLS configuration is built, at startup, because the CRL cannot be applied as configured. Most of them used to run with the CRL silently ignored.

• A server-side CRL (--grpc-crl, --mysql-server-ssl-crl) without the matching CA (--grpc-ca, --mysql-server-ssl-ca). Without a CA no client certificate is requested, so the CRL could not apply. Configure the CA, or drop the CRL.
• A server-side CRL (--grpc-crl, --mysql-server-ssl-crl) without the matching certificate and key (--grpc-cert and --grpc-key, --mysql-server-ssl-cert and --mysql-server-ssl-key). The server is then not configured for TLS at all: the gRPC server used to start in plaintext, and the MySQL server without TLS, with the CRL silently ignored. Configure the certificate and the key along with the CA, or drop the CRL.

Release of Vitess v23.0.7

Summary

lz4 backup engine: library upgrade and --compression-level mapping

The lz4 compression engine now uses the pierrec/lz4/v4 library instead of pierrec/lz4 v2. This fixes broken block decoding on amd64 in the v2 library. The frame format is unchanged, so backups written by older Vitess versions remain restorable and backups written by this version are restorable by older versions.

The upgrade changes how --compression-level is interpreted for the lz4 engine. Values 0 and 1, including the default of 1, select the fast compressor; 1 previously requested a hash-chain search depth of 1. Values 2 through 9 now select lz4's named hash-chain levels (Level2 through Level9) instead of using the raw value as the hash-chain search depth, so higher values produce a better ratio at more CPU cost. Negative values, which previously requested an unlimited search, and values above 9, which were used as the search depth, select Level9. Other compression engines are not affected.

See #20778 for details.

Connections whose certificate revocation cannot be checked against a configured CRL are rejected

The certificate revocation lists configured with --grpc-crl, --mysql-server-ssl-crl, --tablet-grpc-crl, --vtgate-grpc-crl, and the other *-crl flags are now enforced in every SSL mode and on resumed TLS sessions, see GHSA-fxqj-c35w-x6rq. Each certificate of the peer's verified chain, except the trust anchor the chain ends at, is checked against the CRLs signed by its issuer, the next certificate of the chain.

Connections that are now rejected

In the preferred and required SSL modes, the server's certificate chain is otherwise not verified. A client with a CRL now builds that chain to the configured CA, or to the system roots when no CA is configured, and rejects the connection when the chain cannot be built or verified, rather than leave the CRL unchecked. For example:

• A client in required mode with a CRL but no CA file, connecting to a server whose certificate a private CA issued.
• A client with a CRL and the root CA configured, connecting to a server that presents its certificate without the intermediate CA that issued it.
• A client with a CRL connecting to a server whose certificate has expired or is not valid for server authentication, which these modes accept without a CRL.

To keep such connections working, configure the CA that the server's chain leads to, have the server present its whole chain and a valid certificate, or drop the CRL.

A gRPC client with a CRL configured (--tablet-grpc-crl, --vtgate-grpc-crl, --vtctld-grpc-crl, and the other *-grpc-crl flags) but neither a client certificate nor a CA now connects with TLS, verifying the server against the system roots, rather than in plaintext with the CRL silently ignored. Configure the CA along with the CRL, or drop the CRL.

Configurations that are refused at startup

The following configurations are now refused when the TLS configuration is built, at startup, because the CRL cannot be applied as configured. Most of them used to run with the CRL silently ignored.

• A server-side CRL (--grpc-crl, --mysql-server-ssl-crl) without the matching CA (--grpc-ca, --mysql-server-ssl-ca). Without a CA no client certificate is requested, so the CRL could not apply. Configure the CA, or drop the CRL.
• A server-side CRL (--grpc-crl, --mysql-server-ssl-crl) without the matching certificate and key (--grpc-cert and --grpc-key, --mysql-server-ssl-cert and --mysql-server-ssl-key). The server is then not configured for TLS at all: the gRPC server used to start in plaintext, and the MySQL server without TLS, with the CRL silently ignored. Configure the certificate and the key along with the CA, or drop the CRL.
• A *-crl file that holds no C

Release of Vitess v24.0.3

Summary

VRLog Feature Removed

The VRLog feature — a streaming log of VReplication events served at VTTablet's /debug/vrlog HTTP endpoint, disabled by default since v22 — has been removed. The --vreplication-enable-http-log flag that enabled it is now a deprecated no-op and will be removed in v26.

Migration: remove --vreplication-enable-http-log from VTTablet startup arguments.

Impact: The /debug/vrlog endpoint no longer exists. Passing --vreplication-enable-http-log logs a deprecation warning and has no effect.

See #20467 for details.

The entire changelog for this release can be found here.

The release includes 61 merged Pull Requests.

Thanks to all our contributors: @app/vitess-bot, @arthurschreiber, @timvaillancourt, @yushuqin