ClusterLabs / ClusterLabs/resource-agents

oracle monitor time outs if caging is used on instance

Open
#1,174 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.