Risk Free?

Since the primary purpose of the cluster is for high availability with regards to hardware failures, uncommitted transactions would be rolled back; so I would do the following for a "planned" reboot of a cluster node.

1. Have the applications come off-line, or restricted. I would even set the database to restricted_user so "user" connections would not be made. Doing this would prevent "uncommited" transactions from being rolled back.

1a. Back up the transaction log, so a "checkpoint" occurs. If I have to kill users, I would perform this backup first, so the work would be commited.

2. I would move the cluster group over to the opposite node of the one that is going to be rebooted.

3. Once the group came back "online", I would reboot the passive node.

4. If I needed to reboot the "active" node, I would wait for the previously rebooted node to come "online", then move the active groups over to the other node.

5. Once the groups came back "online", I would then reboot the passive node.

6. After this node came back "online", I would then move the group to the desired node.

7. Unrestrict the databases and have the applications become available.

steve