On Fri, Jun 17, 2011 at 9:28 AM, Fabio M. Di Nitto <fdinitto@xxxxxxxxxx> 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 <service> 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-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
