The supported routing methods, typical uses and use cases are listed in Table 7.1, “Routing Method Selection”.
Table 7.1. Routing Method Selection
| Routing Method | Host Selection | Auto R/W Splitting | Replica Latency | Maximum Applied Latency |
|---|---|---|---|---|
| Smartscale | By Session | Yes (by SQL statement) | Lazy | Yes |
| Direct Reads | By Content | Yes (by SQL statement) | Lazy | Yes |
| Host-based | By Hostname | No | Yes | Yes |
| Port-based | By Network Port | No | No | Yes |
| SQL-based | By SQL comment | No | No | Yes |
Both SmartScale and R/W splitting cannot be enabled at the same time. This is because they are two sides of the basic functionality. R/W splitting and SmartScale both use SQL introspection to determine whether a query should be directed to a Primary or a Replica. SmartScale combines this with an intelligent load-balancer. R/W splitting uses a simpler direct redirection.
In addition to the selection and configuration mechanisms supported, a routing method should be chosen based on your application abilities:
If the application is replication-aware, and can already direct queries to Primary or Replicas based on the operation type, use Section 7.4.13, “Host-based Routing” or Section 7.4.14, “Port-based Routing”
If the application has full control of the SQL statements submitted (i.e. not through a third-party tool, or Object-Relational Modeling library), and can already direct queries to Primary or Replicas based on the operation type, use Section 7.4.12, “SQL Routing”.
If the application uses non-auto-commit statements (for example, Hibernate), Section 7.4.13, “Host-based Routing”, or Section 7.4.12, “SQL Routing”.
If the application does not fit any of these categories, or is not replication aware use either either Section 7.4.11, “Direct Routing” or Section 7.4.10, “Smartscale Routing”.