Re: [Linux-HA] [Linux-cluster] resource agents 3.9.1 final release

2011-06-17 Thread Gianluca Cecchi
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


Re: [Linux-HA] [Linux-cluster] resource agents 3.9.1 final release

2011-06-17 Thread Fabio M. Di Nitto
Lon, what's your opinion on this one?

On 06/16/2011 04:44 PM, Gianluca Cecchi wrote:
> On Thu, Jun 16, 2011 at 3:13 PM, Fabio M. Di Nitto  wrote:
> 
>> Highlights for the rgmanager resource agents set:
>>
>> - oracledb: use shutdown immediate
> 
> hello,
> from oracledb.sh.in I can see this actually is not a configurable
> parameter, so that I cannot choose between "immediate" and "abort",
> and I think it is not the best change.
> 
> 
> faction "Stopping Oracle Database:" stop_db immediate
> if [ $? -ne 0 ]; then
> faction "Stopping Oracle Database (hard):" stop_db
> abort || return 1
> fi
> 
> 
> There are situations where an occurring problem could let a DB stuck
> on shutdown immediate, preventing completion of the command itself so
> you will never arrive to the error code condition to try the abort
> option...
> And also:
> "
> SHUTDOWN IMMEDIATE
> No new connections are allowed, nor are new transactions allowed to be
> started, after the statement is issued.
> Any uncommitted transactions are rolled back. (If long uncommitted
> transactions exist, this method of shutdown might not complete
> quickly, despite its name.)
> Oracle does not wait for users currently connected to the database to
> disconnect. Oracle implicitly rolls back active transactions and
> disconnects all connected users.
> "
> 
> it is true that in case of shutdown abort you have anyway to rollback
> too, during the following crash recovery of startup phase, but I'd
> prefer to do this on the node where I'm going to land to and not on
> the node that I'm leaving (possibly because of a problem).
> In my opinion the only situation where "immediate" is better is for
> planned maintenance.
> 
> Just my opininon.
> Keep on with the good job
> Gianluca
> 
> --
> Linux-cluster mailing list
> linux-clus...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster

___
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