DBCP : Hikari
Java, Spring boot framework 1.5
org.mariadb.jdbc:mariadb-java-client:2.3
Connection String : jdbc:mariadb:aurora://**

Using 'aurora' keyword in connection string does exactly that, and this is the expected result.
Connector will use master/reader according to current connection read-only setting.
Example:

connection = DriverManager.getConnection("jdbc:mariadb:aurora://someUrl/test");

stmt = connection.createStatement();

stmt.execute("SELECT 1"); // will execute query on master

connection.setReadOnly(true);

stmt.execute("SELECT 1"); // will execute query on slave

ORM like hibernate for example will set connection.setReadOnly automatically.

If needing to use only and always the master connection, then changing the connection string (removing "aurora" keyword) will be more appropriate, because then this is "standard" connection (aurora configuration will have 2 underlying socket connection to permit distribution to writer/reader)

Thanks for your kind comment.

When we test connection string with 'aurora' keyword, sometimes select query is executed on slave even we didn't set setReadonly to True. (During load test, Initially all queries are executed on Master only but select query distributed to slave when load increased.)

So current design is using slave when only setReadOnly to True and no other scenarios, right?

>So current design is using slave when only setReadOnly to True and no other scenarios, right?
To be more complete: when creating a connection with 'aurora' prefix, there will be 2 underlying connections. One to master, second to slave.

There are 3 cases to have a query running on the slave :

• When this connection is created, a few queries are executed, like "SELECT @@max_allowed_packet,@@system_time_zone,@@time_zone,@@auto_increment_increment"). those are only when initiating the connection.
• When master connections fail, and reader connection is still active, it can be asked current master (aurora recovery can automatically promote a new master and DNS takes some time to point to the new master, but slave know immediately)
• Or as indicated using setReadonly(true).

So for 'client' query, it's only by using setReadonly(true).

@Diego Dupin

Thanks for your kind explanation about current design.
We've checked all 3 cases but not matched. We faced 'client' query was distributed to slave node while setReadonly flag was False.

To identify this issue, could you please guide us which log should be gathered or any points to check?

Closing, since 4 years without feedback and no reproduction