[MXS-3151] Allow to make extra_port the default, not the fallback, for monitors Created: 2020-09-02 Updated: 2021-04-27 Resolved: 2020-10-09 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Monitor |
| Affects Version/s: | 2.4.11, 2.5.2 |
| Fix Version/s: | 6.0.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Hartmut Holzgraefe | Assignee: | Esa Korhonen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Sprint: | MXS-SPRINT-116 |
| Description |
|
Right now the extra_port defined for a server will only be used when a connect attempt on the regular port fails "This allows MaxScale to connect even when max_connections has been reached on the backend server. If this parameter is defined and a connection to the normal port fails, the alternative port is used." As even when successfully connected to the regular port monitoring queries on that connection can stall while waiting in the pool-of-threads execution queue it would IMHO make more sense to have the monitor(s) use the extra port by default, to ensure that monitoring queries and switchover/failover actions are handled with priority and don't have to wait in the thread pool execution queue if the thread pool is fully loaded with query execution threads already. Monitoring queries will still suffer from CPU overload if pool-of-threads was not properly configured to prevent this, but at least they won't additionally suffer from having to wait in the thread pool queue in such cases, too. |
| Comments |
| Comment by Hartmut Holzgraefe [ 2020-09-02 ] |
|
See also slack discussion starting at: https://mariadb.slack.com/archives/C03NQJPUL/p1599050217044800 |
| Comment by Johan Wikman [ 2020-09-28 ] |
|
The sentiment is that it simply should be so that if an extra_port has been defined, then it simply should always be used by the monitor, and not only when it is not possible to connect using the normal port. |
| Comment by Esa Korhonen [ 2020-10-09 ] |
|
Defaults to using extra-port if defined. |