server-selection

This attribute determines how Radiator selects a MySQL server when multiple server blocks are configured. Possible values are:

• fallback: Servers are tried in priority order. The highest-priority available server receives every request. Lower-priority servers are used only when higher-priority servers are unavailable or degraded. This is the recommended strategy for primary/replica setups.
• round-robin: Requests are distributed across all available servers in rotation. If a server fails, the next available server in the rotation is used.
• no-fallback: Only the highest-priority available server is tried for each request. If the query fails on that server, the request fails without retrying on other servers. Use this when strict server isolation is required.
• least-connections: Each request is routed to the available server with the fewest in-use connections. If that server also fails, the next least-loaded server is tried. When servers are tied (e.g. all pools idle), servers with a lower priority value are preferred; within the same priority, alphabetical name order is used as a tiebreaker — the same as fallback. Because saturated pools are skipped immediately for MySQL, this strategy is useful for balancing load under high concurrency.

Default: fallback

Example configuration:

mysql "MYSQL_HA" {
    server-selection fallback;

    server "primary" {
        host "mysql-primary.example.com";
        port 3306;
        database "radiator";
        username "radiator";
        password "secret";
        priority 0;
    }

    server "replica" {
        host "mysql-replica.example.com";
        port 3306;
        database "radiator";
        username "radiator";
        password "secret";
        priority 1;
    }

    query "FIND_USER" {
        statement "SELECT username, password_hash FROM users WHERE username = ?";
        bindings { aaa.identity; }
        mapping { user.password = password_hash; }
    }
}

See Backend Load Balancing for more details and examples.