When a proxy connection address is used to implement read/write separation, the consistency of non-transactional reads is not guaranteed. If your business requires read consistency, you can encapsulate it into transactions or use the hint syntax.
When a proxy connection address is used,
show processlist will merge the results of all nodes before returning them.
PREPARE statement, the database proxy will first send
PREPARE to all nodes. When a subsequent
EXECUTE request comes in, it will determine the execution route according to the prepared statement type. For example, if a write statement is prepared, it will send the statement to the source database during execution, and if a read statement outside transactions is prepared, it will send the statement to a read-only instance.
After a business connection arrives at the database proxy, the proxy will connect to the source instance and all configured read-only instances. The proxy itself does not have a limit on the maximum number of connections, which is mainly subject to the maximum number of connections of the backend database instance (the smallest value of this parameter of the source and read-only instances will affect the business performance).
After the database proxy is enabled, when a read-only instance is added or restarted, only new connection requests will be routed to it. You can view the performance metrics of each proxy node through the overview or performance monitoring. If you find that the numbers of connections on the nodes are unbalanced, you can distribute the connections through rebalance.