Error 2065 occurs when a client requests compression while using the deprecated asynchronous protocol, which MySQL cannot combine.
MySQL Error 2065: CR_COMPRESSION_NOT_SUPPORTED means the client asked for compressed traffic while also enabling the old asynchronous protocol. MySQL 8.0.16-8.0.20 rejected that mix and raised this connection error. Disable one of the options or upgrade both client and server to a compatible version to resolve the issue.
Compression protocol not supported with asynchronous protocol CR_COMPRESSION_NOT_SUPPORTED was added in 8.0.16, removed after 8.0.20.
The client library raises code 2065 when it detects an attempt to enable connection compression together with the deprecated asynchronous client protocol. MySQL 8.0.16 through 8.0.20 shipped both features but blocked their joint use, triggering this error before the handshake finishes.
The error is classified as a client-side connection failure. The server never processes SQL because the transport options are incompatible.
After MySQL 8.0.20, the asynchronous protocol was removed, so modern clients never emit 2065.
Error 2065 typically appears immediately after mysql_real_connect() or on CLI start-up.
It surfaces in MySQL Shell, mysql client, Connector/C, Connector/Python, and any driver linked against libmysqlclient 8.0.16-8.0.20 that sets both MYSQL_OPT_COMPRESS and MYSQL_OPT_PROTOCOL_ASYNC.
Cloud and container images built from those versions are most affected because default startup scripts sometimes enable compression for bandwidth savings while libraries default to async mode.
The connection never establishes, blocking application traffic. Automated retries will continue to fail, causing downtime or service degradation.
Removing the option clash restores connectivity without touching schema or data.
Using an 8.0.16-8.0.20 client that has both compression and asynchronous protocol flags active causes a pre-handshake abort. Upgrading either side removes the clash.
Mismatch between a newer server and an older client that still references the async protocol can also surface the error because the server no longer recognizes the flag.
First, decide whether compression or asynchronous protocol is more critical.
Disable the less important option via connection parameters, environment variables, or driver settings, then reconnect.
If you need compression and async I/O, upgrade to MySQL 8.0.21+ where async was removed, or downgrade to 8.0.15 where the conflict did not exist. Matching client and server versions eliminates handshake discrepancies.
CI pipelines that pin docker mysql:8.0 image unknowingly pulled 8.0.16-20 and failed. Pin mysql:8.0.15 or mysql:8.0.34 to restore builds.
Applications compiled with libmysqlclient 8.0.16 reuse binary against a 8.0.34 server and crash.
Re-compile against the newer client library or set MYSQL_OPT_COMPRESS only.
Always align client and server minor versions in staging before production rollout. Enable only the transport features you actively need.
Monitor connection error logs for code 2065 and alert early.
Automate dependency upgrades to jump beyond the 8.0.16-20 window.
Error 2055: Lost connection during handshake - often follows if the client retries with the same options.
Error 2059: Authentication plugin not loaded - appears when client and server share incompatible capability flags, requiring similar version alignment.
.
No. The failure happens inside the client library before the server processes any packets.
No. MySQL removed async support after 8.0.20. Choose compression or switch to non-async code paths.
Data is safe. The session never starts, so no transactions occur.
Galaxy alerts on connection errors in its integrated console, suggests compatible driver versions, and stores vetted connection snippets your team can reuse.