AUTOMATED INTEGRATED HIGH AVAILABILITY OF THE IN-MEMORY DATABASE CACHE AND THE BACKEND ENTERPRISE DATABASE

• US 20110071981A1
• Filed: 03/08/2010
• Published: 03/24/2011
• Est. Priority Date: 09/18/2009
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Gusev, Andrey, Lahiri, Tirthankar, Fulton, Ben, Hoch, Charles, Tellez, Juan, Motivala, Ashish, Aranha, Rohan, Ghosh, Sourav
• Granted Patent: US 8,306,951 B2
• Time in Patent Office: Days
• US Class Current: 707/634
• CPC Class Codes: G06F 11/2025 using centralised failover control functionality
• CPC Class Codes: G06F 11/2028 eliminating a faulty processor or activating a spare
• CPC Class Codes: G06F 11/2038 with a single idle spare processing component
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: G06F 2201/80 Database-specific techniques

Abstract

A cluster manager is configured to manage a plurality of copies of a mid-tier database as a mid-tier database cluster. The cluster manager may concurrently manage a backend database system. The cluster manager is configured to monitor for and react to failures of mid-tier database nodes. The cluster manager may react to a mid-tier database failure by, for example, assigning a new active node, creating a new standby node, creating new copies of the mid-tier databases, implementing new replication or backup schemes, reassigning the node'"'"'s virtual address to another node, or relocating applications that were directly linked to the mid-tier database to another host. Each node or an associated agent may configure the cluster manager to behave in this fashion during initialization, based on common cluster configuration information. Each copy of the mid-tier database may be, for example, a memory resident database. Thus, a node must reload the entire database into memory to recover a copy of the database.

Claims

1. A method comprising:

managing the availability of copies of a backend database stored in a plurality of persistent storage systems;

managing the availability of copies of a mid-tier database;

wherein the mid-tier database stores one or more elements for which changes are propagated to the backend database;

wherein the backend database comprises a subset of data that is not stored in the mid-tier database;

wherein each step of the method is performed concurrently by a cluster manager implemented by one or more computing devices.

2. The method of claim 1, wherein the copies of the mid-tier database are stored in a plurality of volatile memories.

3. The method of claim 1, wherein the backend database stores one or more elements for which changes are propagated to the mid-tier database.

4. A method comprising:

accessing configuration information describing a mid-tier database cluster;

wherein the mid-tier database cluster comprises one or more copies of a mid-tier database residing at one or more nodes of a plurality of nodes;

wherein the one or more copies include a particular copy, the particular copy residing at a particular node of the one or more nodes;

wherein at least one of the one or more nodes is configured to replicate changes to a copy of an element in the mid-tier database to a copy of the element in a backend database;

based on the configuration information, configuring a component to perform;

monitoring status information for each of the one or more copies of the mid-tier database;

in response to detecting a failure of the particular copy of the mid-tier database during said monitoring, triggering one or more designated processes at the plurality of nodes;

in response to the component triggering said one or more designated processes at the plurality of nodes, the one or more designated processes performing at least one of;

recovering a copy of the mid-tier database at one of the particular node or a spare node;

or

causing a new node to provide to a client services involving transactions in the mid-tier database, said services having been, at the time of the failure, provided by the particular node;

wherein the method is performed by one or more computing devices.

5. The method of claim 4, wherein the method is performed by the component, said component being implemented by the one or more computing devices.

6. The method of claim 4,

wherein the method is performed by a plurality of processes executing at the plurality of nodes, the plurality of nodes being implemented by the one or more computing devices;

wherein the component is a cluster manager, wherein said cluster manager is not implemented by the plurality of processes;

wherein the cluster manager also manages the availability of a cluster of database servers that provide access to copies of the backend database.

7. The method of claim 6,

wherein the cluster manager is configured to monitor the status information by periodically polling processes at the one or more nodes;

wherein the method further comprises a particular process at the particular node pushing a notification to the cluster manager that the particular database is failing;

wherein said notification is not responsive to a poll by the cluster manager;

wherein said notification results in the cluster manager detecting the failure of the particular copy.

8. The method of claim 4,

wherein each of the copies of the mid-tier database is stored in a volatile memory of its corresponding node;

wherein the backend database is stored in one or more persistent storage systems;

wherein said failure is or implies an at least temporary removal of the particular copy of the mid-tier database from the volatile memory of the particular node.

9. The method of claim 4,

wherein the one or more copies of the mid-tier database include a first copy at a first node and a second copy at a second node;

wherein the first copy is indicated to be an active copy, in that it is the only copy of the one or more copies configured to permit write operations by linked applications;

wherein the second copy is indicated to be a standby copy;

wherein changes at the active copy are replicated to the standby copy.

10. The method of claim 9,

wherein the particular copy is the first copy;

wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes performing;

indicating the second copy to be the active copy;

recovering the first copy of the mid-tier database at said one of the particular node or the spare node;

indicating newly recovered copy to be the standby copy.

11. The method of claim 9,

wherein the particular copy is the second copy;

wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes recovering the second copy of the mid-tier database at said one of the particular node or the spare node;

indicating the newly recovered copy to be the standby copy.

12. The method of claim 9,

wherein, the component is configured to trigger the one or more designated process in response to a concurrent failure of both the active copy and the standby copy;

wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes recovering a new active copy and a new standby copy based on recovery information stored in at least one of a shared storage or the backend database.

13. The method of claim 9,

wherein the particular copy is the active copy;

wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes performing;

causing the second node to provide to the client said services involving transactions in the mid-tier database.

14. The method of claim 13, wherein causing the second node to provide to the client said services involving transactions in the mid-tier database comprises remapping a virtual address from the particular node to the second node.

15. The method of claim 9,

wherein the one or more copies of the mid-tier database further comprise one or more read-only subscriber copies to which changes to the active copy or the standby copy are replicated;

wherein the particular copy is a subscriber copy at a subscriber node;

wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes recovering the subscriber copy of the mid-tier database at said one of the particular node or the spare node;

indicating the newly recovered copy to be the subscriber copy.

16. The method of claim 4, wherein the method further comprises, in response to the component triggering the one or more designated processes, the one or more designated processes performing:

causing the new node to provide to the client said services involving transactions in the mid-tier database;

wherein said services were provided by a first instance of an application at the particular node at the time of the failure, the first instance having depended on the particular copy of the mid-tier database;

wherein causing the new node to provide to the client said services comprises at least;

starting a second instance of the application at the second node, wherein the second instance depends upon a second copy of the mid-tier database stored at the second node.

17. A method comprising:

at a first node, storing a first copy of a database;

at the first node, executing a first instance of an application;

wherein the first instance of the application provides, to a client, services that involve transactions with the first database;

wherein the first instance of the application depends upon the first copy of the database to provide said data;

in response to a failure of the first copy of the database, causing the client to be redirected to a second instance of the application for provision of services that involve transactions with the first database;

wherein the second instance of the application executes at a second node;

wherein the second instance of the application depends upon a second copy of the first database stored at the second node.

18. The method of claim 17, wherein causing the client to be redirected to the second instance comprises starting the second instance of the application at the second node.

19. The method of claim 17,

wherein each copy of the database is stored in a volatile memory of its corresponding node;

wherein said failure is or implies an at least temporary removal of the first copy from the volatile memory of the first node.

20. The method of claim 17, further comprising causing the client to be redirected to the second instance without requiring the client to be aware of the redirection, wherein causing the client to be redirected to the second instance comprises remapping a virtual address from the first node to the second node.

21. The method of claim 17,

wherein the first database is implemented based, at least in part, on software provided by a provider;

wherein the application is a third-party application that is not provided by the provider.