High availability via data services
Application-level replication, the synchronization of data updates within a cluster of application servers, may be provided by having application servers themselves synchronize all updates to multiple redundant databases, precluding the need for database-level replication. This may be accomplished by first sending a set of database modifications requested by the transaction to a first database. Then a message may be placed in one or more message queues, the message indicating the objects inserted, updated, or deleted in the transaction. Then a commit command may be sent to the first database. The set of database modifications and a commit command may then be sent to a second database. This allows for transparent synchronization of the databases and quick recovery from a database failure, while imposing little performance or network overhead.
1. A method for a reduced failover time comprising:
detecting, using one or more processors, that a first recovery server is back online after a failure of the first recovery server;
subsequent to detecting that the first recovery server is back online after the failure of the first recovery server, reading a transaction ID out of one or more queued messages in a persistent message queue corresponding to the first recovery server, the persistent message queue including one or more messages associated with one or more modifications to a first database requested by one or more application servers during the failure of the first recovery server, wherein the first database is one of a plurality of peer databases that replicate the one or more modifications;
deleting messages in the persistent message queue having a transaction ID matching a transaction ID in a transaction ID table in the first database; and
responsive to eliminating the messages in the message queue having matching transaction IDs in a transaction ID table, resuming normal operation of the first recovery server.
2. The method of claim 1 , wherein the persistent message queue stores a message for processing by the first recovery server responsive to the message having a second transaction ID not matching an ID in the transaction ID table in the first database.
3. The method of claim 1 , further comprising:
responsive to a second message in the persistent message queue having a second transaction ID not matching an ID in the transaction ID table in the first database, saving the second message for processing by the first recovery server.
4. The method of claim 1 , further comprising:
transmitting, at periodic time intervals, a heartbeat message from the first recovery server to a second recovery server.
5. The method of claim 1 , wherein the transaction ID table includes a first column and a second column, the first column including one or more transaction IDs and a second column including a timestamp recording a row's creation time.
6. The method of claim 1 , wherein one or more tables of the first database contain an optimistic control attribute used to detect and resolve conflicts resulting from race conditions.
7. The method of claim 1 , wherein the transaction ID table is managed by a cache and invisible to application logic.
8. The method of claim 1 , wherein a record associated with a modification and including the transaction ID is inserted into the transaction ID table in the first database before a commit command is sent to the first database.
9. The method of claim 1 , wherein a record associated with a modification and including the transaction ID is inserted into the transaction ID table in the first database subsequent to a commit command being sent to a second database.
10. The method of claim 1 , wherein the first database and the second database process requests from an application server cluster.
11. A system for a reduced failover time comprising:
one or more processors; and
a memory storing instructions that, when executed by the one or more processors, cause the system to:
detect that a first recovery server is back online after a failure of the first recovery server;
subsequent to detecting that the first recovery server is back online after the failure of the first recovery server, read a transaction ID out of one or more queued messages in a persistent message queue corresponding to the
first recovery server, the persistent message queue including one or more messages associated with one or more modifications to a first database requested by one or more application servers during the failure of the first recovery server;
delete a first message in the persistent message queue having a transaction ID matching a transaction ID in a transaction ID table in a first database; and
responsive to eliminating the messages in the message queue having matching transaction IDs in a transaction ID table, resume normal operation of the first recovery server.
12. The system of claim 11 , wherein:
the persistent message queue stores a message for processing by the first recovery server responsive to the message having a second transaction ID not matching an ID in the transaction ID table in the first database.
13. The system of claim 11 , further comprising instructions that, when executed by the one or more processors, cause the system to:
responsive to a second message in the persistent message queue having a second transaction ID not matching an ID in the transaction ID table in the first database, saving the second message for processing by the first recovery server.
14. The system of claim 11 , further comprising instructions that, when executed by the one or more processors, cause the system to:
transmit, at periodic time intervals, a heartbeat message from the first recovery server to a second recovery server.
15. The system of claim 11 , wherein the transaction ID table includes a first column and a second column, the first column including one or more transaction IDs and a second column including a timestamp recording a row's creation time.
16. The system of claim 11 , wherein one or more tables of the first database contain an optimistic control attribute used to detect and resolve conflicts resulting from race conditions.
17. The system of claim 11 , wherein the transaction ID table is managed by a cache and invisible to application logic.
18. The system of claim 11 , wherein a record associated with a modification and including the transaction ID is inserted into the transaction ID table in the first database before a commit command is sent to the first database.
19. The system of claim 11 , wherein a record associated with a modification and including the transaction ID is inserted into the transaction ID table in the first database subsequent to a commit command being sent to a second database.
20. The system of claim 11 , wherein the first database and the second database process requests from an application server cluster.