MetricSign
Start free
High severityauthentication

MySQL Error:
1251

What does this error mean?

MySQL 8.0 changed its default authentication plugin from mysql_native_password to caching_sha2_password. When a client driver — JDBC, Python's mysql-connector, ODBC, or a managed service like Azure Data Factory — attempts to connect using the older protocol, the server rejects the handshake with error 1251: 'Client does not support authentication protocol requested by server.' The connection never completes, so any query, copy activity, or dbt run that depends on it fails immediately. You will typically see this after upgrading MySQL from 5.7 to 8.0, after creating a new user without specifying an auth plugin, or after migrating a database to a managed MySQL 8.x instance where the server default was not changed.

Common causes

  • 1MySQL 8.0+ defaults to caching_sha2_password, but the client driver only supports mysql_native_password — common with mysql-connector-python < 8.0.11 and JDBC driver < 8.0.13
  • 2Azure Data Factory's built-in MySQL connector uses an older ODBC driver that does not negotiate caching_sha2_password during the TLS handshake
  • 3A new MySQL user was created without specifying `IDENTIFIED WITH mysql_native_password`, so it inherited the server default (caching_sha2_password)
  • 4The MySQL server was upgraded from 5.7 to 8.0, but my.cnf was not updated to set `default_authentication_plugin=mysql_native_password` for backward compatibility
  • 5Power BI Gateway or dbt uses a connection string that lacks `--default-auth=mysql_native_password`, and the server-side plugin is caching_sha2_password
  • 6Docker images or cloud-init scripts provision MySQL 8.0 with default settings; the ETL service account inherits caching_sha2_password without anyone noticing until the first pipeline run

How to fix it

  1. 1Step 1: Confirm the current auth plugin for the affected user: `SELECT user, host, plugin FROM mysql.user WHERE user = 'etl_user';` — if plugin shows `caching_sha2_password`, that is the cause.
  2. 2Step 2 (quick fix): Switch the user to the legacy plugin: `ALTER USER 'etl_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES;` — this unblocks the connection immediately.
  3. 3Step 3 (server-wide fallback): If multiple users are affected, add `default_authentication_plugin=mysql_native_password` under `[mysqld]` in `/etc/mysql/my.cnf` (or `/etc/my.cnf`), then restart MySQL: `sudo systemctl restart mysql`.
  4. 4Step 4 (preferred long-term fix): Upgrade the client driver to a version that supports caching_sha2_password — e.g. mysql-connector-python >= 8.0.11, JDBC Connector/J >= 8.0.13, or PyMySQL >= 0.10.0. In dbt, update `dbt-mysql` to the latest version.
  5. 5Step 5 (ADF-specific): In the Azure portal, open your ADF Linked Service for MySQL → Connection string → add `SslMode=Required` and verify the driver version. If ADF still rejects the connection, apply Step 2 on the server side as a workaround.
  6. 6Step 6 (Power BI): In Power BI Gateway → Data Source Settings → update the MySQL connector and re-enter credentials. Test the connection before scheduling the next refresh.
  7. 7Step 7: Verify the fix by running a test query from the same client: `mysql -u etl_user -p -h your_host -e 'SELECT 1;'` — a successful `1` confirms the auth handshake works.

Example log output

ERROR 1251 (08004): Client does not support authentication protocol requested by server; consider upgrading MySQL client
2026-05-11 08:14:22 [ERROR] ADF activity 'Copy_MySQL_Orders' failed: ErrorCode=UserErrorFailedToConnectToMySql, Message='Client does not support authentication protocol requested by server; consider upgrading MySQL client'
2026-05-11 08:14:23 [ERROR] dbt source mysql_orders: mysql.connector.errors.InterfaceError: 1251 (08004): Client does not support authentication protocol

Frequently asked questions

Is it safe to use mysql_native_password in MySQL 8.0?

It works and is widely used, but it is less secure than caching_sha2_password because it uses SHA-1 hashing. Treat it as a short-term workaround: switch the user now to unblock your pipeline, then plan a driver upgrade and switch back to caching_sha2_password within your next maintenance window.

Why did error 1251 appear after upgrading MySQL from 5.7 to 8.0?

MySQL 8.0 changed the default authentication plugin from mysql_native_password to caching_sha2_password. Existing users created before the upgrade keep their old plugin, but any new user — or any user whose password is reset after the upgrade — gets caching_sha2_password unless you explicitly specify otherwise.

Will retrying the pipeline fix error 1251?

No. Error 1251 is a protocol-level rejection during the authentication handshake. Retries will fail with the same error every time. You need to either change the user's auth plugin on the server or upgrade the client driver.

How do I check which auth plugin a MySQL user is using?

Connect as an admin and run: `SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';` — the `plugin` column shows `mysql_native_password` or `caching_sha2_password`.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html

Other authentication errors