R/W Separation

• Transactions, write request, or read request within a period (200ms by default) after sending the identical session's write request to the master database.
• Read/write separation (or R/W separation) does not ensure the consistency of the non-transaction reads. You should encapsulate those queries requiring the consistency in service should into the transaction.

Business Requirements

• The business has a connection failure detection or timeout mechanism. Timeout value: frontend timeout value, proxy timeout value, and MySQL timeout value
• On the business side, there is a retrial mechanism

Features Not Supported for Now

• Not support the execution of DDL statements via proxy instance.
• Not support comments on routing-related features
• Not support invoking the storage process via proxy instance.
• Not support "old_password=ON"
• Do not use "select" to execute SQL with some actions for SQL will be sent to the slave for execution.
• "set autocommit" statement only supports "set autocommit=1/0", rather than "set autocommit=on/off"

Features Not Recommended

• The following commands' execution results are random. The response results gets returned according to the connected instance in execution, for example, "show processlist", "show master status", and "show slave status".
• Recommend you not to use the connection pool feature at the client because the proxy instance has the connection pool.
• Recommend you not to use "Prepare" in a long connection because a high CPU usage rate leads to performance decline.
• We do not guarantee the correctness of context-sensitive functions like "row_count" and "last_insert_id". We recommend that these functions should be replaced with the programming language's client API. For example, in C and PHP's API, the "mysql_affect_rows" function can be in place of the "row_count", and the "mysql_insert_id" function in place of the "last_insert_id".

Others

• As for "found_rows" function, "dbproxy" currently supports "SELECT SQL_CALC_FOUND_ROWS … from …" by adding "SQL_CALC_FOUND_ROWS", and only after the "found_rows" follows closely to "SELECT SQL_CALC_FOUND_ROWS … from …", can it be sent effectively.
• The field name/field value may be identified as "for update/lock in share mode" keywords and then sent to the master database.
• Field name /field value with a semicolon will be deemed as "multiquery", and then sent to the master database for processing.
• For update/lock in share mode, you must strictly match the keywords, and the extra space might lead to invalid action. Thus, the system sends the current field name/field value to the slave.