Introduction

This Aurora MySQL error almost always means your application is connected to a read-only instance instead of the cluster writer. In Aurora, the writer instance accepts updates, while reader instances are intentionally read-only, so the fix is usually about endpoints, failover handling, or connection routing rather than changing SQL syntax.

Why Aurora Returns This Error

Aurora clusters separate write traffic from read traffic. A typical cluster has:

• one writer instance
• zero or more reader instances

If your application sends INSERT, UPDATE, DELETE, CREATE, or other write statements to a reader, MySQL rejects them with a read-only error.

A quick way to confirm the session state is:

SELECT @@read_only, @@innodb_read_only;

If those values show that the session is read-only, you are not on the writer.

Use the Correct Endpoint

Aurora provides different endpoints for different purposes:

• the cluster endpoint is normally used for write traffic
• the reader endpoint is for read scaling across replicas
• instance endpoints target specific DB instances

If the application uses the reader endpoint for all traffic, writes will fail even though the cluster itself is healthy.

A common mistake looks like this:

mydb.cluster-ro-abcdefgh.us-east-1.rds.amazonaws.com

That cluster-ro reader endpoint should not be used for writes. For write traffic, use the cluster writer endpoint instead.

Typical Application-Side Fix

Many applications should separate read and write connections explicitly.

1import mysql.connector
2
3write_conn = mysql.connector.connect(
4    host="mydb.cluster-abcdefgh.us-east-1.rds.amazonaws.com",
5    user="appuser",
6    password="secret",
7    database="appdb",
8)
9
10read_conn = mysql.connector.connect(
11    host="mydb.cluster-ro-abcdefgh.us-east-1.rds.amazonaws.com",
12    user="appuser",
13    password="secret",
14    database="appdb",
15)

In that setup:

• write queries go through write_conn
• read-only reporting or lookup queries can go through read_conn

This keeps intent clear and makes the architecture much easier to reason about during failover events.

Failover and Stale Connections

Another common source of the error is failover. During or after failover, an old connection pool may still point at an instance that is no longer the writer.

That means even code using the correct endpoint strategy can fail temporarily if:

• the pool cached stale connections
• DNS changes have not been respected yet
• the application retries the same dead connection instead of reconnecting

This is why Aurora-aware applications usually need:

• retry logic for short failover windows
• connection refresh behavior after write failures
• clear separation between transient infrastructure errors and SQL logic errors

If a failover recently happened, recycle the pool and reconnect before assuming the database configuration itself is wrong.

Special Cases to Check

A few other scenarios can also produce read-only behavior:

• you connected directly to a replica instance endpoint
• you are on a secondary cluster in an Aurora Global Database setup
• a proxy or routing layer is misclassifying write traffic as read traffic

In all of these cases, the pattern is the same: Aurora is behaving as designed, but the application is writing to a place that is not supposed to accept writes.

Operational Checks

Useful checks include:

aws rds describe-db-clusters --db-cluster-identifier mydb
aws rds describe-db-instances --filters Name=db-cluster-id,Values=mydb

And in SQL:

SHOW VARIABLES LIKE 'read_only';
SHOW VARIABLES LIKE 'innodb_read_only';
SELECT @@aurora_server_id;

These help you verify both the cluster topology and the behavior of the current session.

Common Pitfalls

• Sending writes to the reader endpoint instead of the cluster writer endpoint.
• Connecting to a specific reader instance endpoint by mistake.
• Keeping stale connections after failover and assuming they still target the writer.
• Mixing read and write traffic in one pool without clear routing rules.
• Treating the error as a SQL problem when it is really a topology or connection-target problem.

Summary

• This Aurora error usually means your session is connected to a read-only instance.
• The most common cause is using the reader endpoint for write traffic.
• Use the cluster writer endpoint for writes and the reader endpoint only for read scaling.
• After failover, refresh connection pools and reconnect if stale sessions remain.
• Check both Aurora topology and SQL session variables before changing application logic.