Oracle International Corporation

Rajesh Dasari

Juan Tellez

Andrey Gusev

Ming Zhu

A software change system and method implements changes of a current active software version hosted one or more testing nodes of a cluster(s) to a different software version, while other nodes within the cluster(s) continue to employ the current active software version. To determine and resolve errors and incompatibilities introduced by the different software version, the at least one testing node is upgraded to the different software version and employed to query resources and data associated with the current active software version. Resolution data pertaining to the different software version is generated reflecting changes to the data employed by the different software version, or changes to the different software version, to resolve the errors and incompatibilities. The resolution data may be deployed to other nodes of the cluster(s) before, during, or after the nodes are upgraded on a rolling or other basis to the different software version.

Method and system for implementing software changes using rolling upgrades with reduced downtime

A method and mechanism for failing over applications in a clustered computing system is provided. In an embodiment, the methodology is implemented by a high-availability failover mechanism. Upon detecting a failure of an application that is currently designated to be executing on a particular node of the system, the mechanism may attempt to failover the application onto a different node. The mechanism keeps track of a number of nodes on which a failover of the application is attempted. Then, based on one or more factors including the number of nodes on which a failover of the application is attempted, the mechanism may cease to attempt to failover the application onto a node of the system.

Method to avoid continuous application failovers in a cluster

Techniques are provided for managing a resource in a High Availability (HA) system. The techniques involve incrementing a count when a particular type of remedial action is performed on a resource, so that the count that reflects how often the particular type of remedial action has been performed for the resource. When it is determined that the resource has been in stable operation, the count is automatically reduced. After a failure, the count is used to determine whether to attempt to perform the particular type of remedial action on the resource. Examples of remedial actions include restarting the resource, and relocating the resource to another node of a cluster. By using the count, the system insures that a faulty resource does not get constantly 'bounced'. By reducing the count when a resource has become stable, there is less likelihood that failure of otherwise stable resources will require manual intervention.

Growing community of inventors

Mountain View, CA, United States of America

Rajesh Dasari