ClusterLabs / ClusterLabs/resource-agents
oracle monitor time outs if caging is used on instance
- Dominant language
- Shell
- Stars
- 519
- Forks
- 608
- Avg merge
- 6d 1h
- Merged PRs (30d)
- 7
Description
Hello,
recently we moved one of our busy databases that uses caging to be able to run on shared host to work with pacemaker and almost immediately we
began seeing monitor timeouts that cause pacemaker to restart the database
After tracing the behavior we saw that oracle_monitor() tries to connect with monuser/monpassword and
fails when the caging doesn't allow new connections to be made.
Because of the behavior what actually happens is that sqlplus simply waits for the server to respond
and it just timeouts after period defined in monitor operation
In pacemaker oracle agent first tries to connect with monuser/monpassword and only when it fails the agent will try to connect as sysdba. This behavior causes the monitor operation to timeout when database is under heavy load and caging doesn't allow non privileged users to connect
We never had such issue with veritas cluster, so I checked what's the difference and found out that veritas cluster uses sysdba to monitor the database connectivity (unless otherwise specified)
I'd like to request such a configuration to be available (with either new option, or by changing default behavior if monuser/monpassword aren't supplied during resource configuration)
For now I just removed following part of the instance_live():
local status=`monsql_one dbstat`
[ "$status" = OPEN ] && return 0
ocf_log warn "Unable to login as \"$MONUSR\", using \"sysdba\" user instead"
and now the monitor works fine.
Please consider the issue and correct if possible
Thank you
Stas
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating oracle_monitor() and instance_live(), especially the monsql_one dbstat check and the fallback to sysdba. Review how monitor credentials and operation timeouts are configured; done means monitoring remains reliable for caged instances while preserving the requested credential behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100