Last Modified: Jul 02, 2020
See more info
Known Affected Versions:
13.1.0, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 13.1.1, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 13.1.3, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 15.0.0, 15.0.1, 22.214.171.124, 126.96.36.199, 188.8.131.52, 15.1.0, 184.108.40.206, 220.127.116.11, 18.104.22.168
Opened: Nov 18, 2019
When multiple database servers are monitored by LTM database (MSSQL, MySQL, PostgreSQL, Oracle) monitors and one database server goes down (such by stopping the database server process), a deadlock may occur in the LTM database monitor daemon (DBDaemon) which causes an interruption in monitoring of other database servers. When this occurs, one database server going down may cause all monitored database servers to be marked Down for several minutes until the blocking operation times out and normal monitoring can resume.
Monitoring of database servers may be interrupted for up to several minutes, causing monitored database servers to be marked Down. This may persist for several minutes until the blocking operation times out, the backlog of blocked DB monitor threads are processed to completion, and normal DB monitoring resumes.
This may occur when: 1. Running a version of BIG-IP or an Engineering Hotfix which contains fixes for bugs ID769309 and ID775901. 2. Stopping a monitored database server process (such as by halting the database service).
You can prevent this issue from occurring by using a different LTM monitor type (such as a TCP monitor or external monitor) to monitor the database servers.