Which algorithm is recommended for database connections?
Short answer
Least Connection. Database connections are long-lived and their durations vary; the connection pools of applications keep connections open for hours. Round Robin distributes these connections in turn and does not take the load into account; Least Connection, on the other hand, gives the new connection to the server with the fewest connections at that moment. If server capacities differ, Weight is entered for the Backend Services. On an L7 TCP vService, the Tunnel(Websocket) Timeout (default 120 seconds) and Server Timeout (default 90 seconds) in the Timeouts profile are kept longer than the idle time of the connection pool.
Recommended Configuration
| Setting | Recommendation |
|---|---|
| vService type | L7 TCP (if TLS termination or routing by SNI is not required, Network can also be used) |
| LB Algorithm | Least Connection (on Network, Least-Connection or Weighted Least-Connection) |
| Weight | Proportional to capacity if server capacities differ |
| Persistence | Not required; each connection is bound to a server and stays on that server until it closes |
| Timeout | Tunnel(Websocket) Timeout and Server Timeout longer than the idle time of the connection pool |
| Health check | Oracle for Oracle; TCP for other databases (with TCP Scenario steps if needed) |
Why Is Timeout Critical?
If no Timeouts profile is selected on an L7 TCP vService, the defaults apply: Tunnel(Websocket) timeout 120 seconds, Server timeout and Client timeout 90 seconds. Database connections that wait idle in the connection pool for longer than this are closed, and "connection lost" errors are seen in the application. These durations are increased with a profile created on the Load Balancer → Profiles → Timeouts screen, and the profile is selected in the Details → Timeout box of the vService.
Health Check
- TR7 has no health check type specific to MySQL, PostgreSQL or MSSQL.
- For Oracle, there is the Oracle type, which can run an SQL query.
- For other databases, a port check is performed with the TCP type; if send/expect steps are required, the TCP Scenario field of the same type is used.
Common Misconceptions
- "Round Robin also distributes evenly for databases." Long-lived connections accumulate on some servers.
- "TR7 separates read and write queries." Distribution is at the connection level; the read/write separation is done by the application (L7 TCP · Use Cases).
- "The default timeouts are sufficient." Idle pool connections are closed at the default durations.
- "With the Source algorithm, each application server goes to the same database." Source does not exist on L7 TCP; if persistence by client IP is required, Persistence → Hash is used.
How it is done in the documentation
