On Fri, Jun 17, 2011 at 9:28 AM, Fabio M. Di Nitto wrote:
> Lon, what's your opinion on this one?
Some other considerations of mine.
This of the current "abort" default option (as in RH EL 5 cluster
suite base) is indeed a difficulty, in case of planned maintenance, so
that a change inside the agent giving choice and flexibility would be
a great thing.
I was thinking about making myself some change and then propose but
had not the time unfortunately.
Just to note, nowadays if we have a planned operation for the Oracle
DB we go through this workflow:
- DB service is DBSRV
- clusvcadm -Z DBSRV
- Operations on DB, such as shutdown immediate, patching, ecc..
- startup of DB
- clusvcadm -U DBSRV
If the planned operation involves patching of the OS and eventually
cluster suite too, after testing on test cluster, we make sometyhing
like this (from memory supposing a monoservice cluster):
- detach from cluster and update standby node (eventually update both
os and Oracle binaries as we manage their planned maintenance
together)
- DB service is DBSRV
- clusvcadm -Z DBSRV on primary node
- shutdown immediate of db
- clusvcadm -U DBSRV ; clusvcadm -d DBSRV (*)
- shutdown of primary node
- startup of the updated node with the service DBSRV modified so that
Oracle part is not inside (so only vip, lvm, fs parts are enabled)
- verify that oracle startup with new OS and Oracle binaries is ok on the node
- shutdown immediate of db
- change cluster.conf to insert Oracle too inside DBSRV definition and
have it started/monitored from rgmanager
- update the ex-primary node too and start it to join the cluster
(*) this is risky: it would be better to be able to disable a frozen
service, eventually after asking confirmation for that
An idea could be to have inside the clusvcadm command something like
"soft stop" option:
-ss
And if inside the service there is oracledb.sh it parses this and
change its "abort" flag in "immediate"
This "soft stop" could be managed by other resources too...
Gianluca
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems