Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pleshachkov et al. (USPN 20190377821A1).
As per claim 1, Pleshachkov et al. discloses a database disaster recovery system, comprising at least a first database, the first database including at least one data processing node and at least one data protection node, a data protection node of the at least one data protection node and a data processing node of the at least one data processing node being separate from each other (Figure 5 and paragraphs 0007,0093,0094 – first database – first data center; master data node – data processing node; replica data node – data protection node), wherein: a data processing node of the at least one data processing node is operable to generate, in response to a database operation, a log corresponding to the database operation, and send the log to all other data processing node and the at least one data protection node of the first database for at least one data protection node of the first database to synchronize the log, with each of the at least one data processing node and the at least one data protection node meeting distributed consistency (Figure 5 and paragraph 0007 - The master data node is configured to send, to the plurality of replica data nodes, a transaction log record that includes an update to data in the master database that has not been committed to the master database. More particularly, according to one embodiment, the master data node may be configured to maintain a master node transaction log in persistent memory, write the transaction log record from master data node volatile memory to the master node transaction log in persistent memory and send the transaction log record to the plurality of replica data nodes after writing the transaction log record to the master node transaction log. The master data node can be configured, for example, to send the transaction log record to each replica data node in a replication group. The replication group may include replica data nodes at different data centers.; paragraph 0093 - FIG. 5 is a diagrammatic representation of one embodiment of a cluster architecture 500 that includes a first data center 501 and a second data center 550. First data center 501 comprises a first cluster including configuration node 502, data node 504a, data node 504b, data node 504c, data node 504d, data node 504e, data node 504f, data node 504 and cluster clients 520 bi-directionally coupled by network 512. Second data center 550 comprises a second cluster comprising configuration node 552, data node 554a, data node 554b, data node 554c, data node 554d and cluster clients 570 bi-directionally coupled by network 562.);
the data protection node of the first database is operable to receive and store the log sent by the data processing node (Figure 5 and paragraph 0007 - The master data node is configured to send, to the plurality of replica data nodes, a transaction log record that includes an update to data in the master database that has not been committed to the master database. More particularly, according to one embodiment, the master data node may be configured to maintain a master node transaction log in persistent memory, write the transaction log record from master data node volatile memory to the master node transaction log in persistent memory and send the transaction log record to the plurality of replica data nodes after writing the transaction log record to the master node transaction log. The master data node can be configured, for example, to send the transaction log record to each replica data node in a replication group. The replication group may include replica data nodes at different data centers.); and
in response to the first database experiencing an anomaly of a first type, a data processing node of the first database having no anomaly is operable to provide a database service based on a log stored in the data protection node (paragraph 0096 - With multiple copies of the same data set on different data nodes in the cluster, the replication group provides a level of fault tolerance against the loss of a single data node. A replication group can provide increased query performance since the system can distribute the queries on the data set over different data nodes of the replication group. – type of fault is data node failure).
As per claims 2,10,17, Pleshachkov et al. discloses wherein the data protection node has a separate power supply and a separate communications apparatus from the at least one data processing node (paragraph 0093 - FIG. 5 is a diagrammatic representation of one embodiment of a cluster architecture 500 that includes a first data center 501 and a second data center 550. First data center 501 comprises a first cluster including configuration node 502, data node 504a, data node 504b, data node 504c, data node 504d, data node 504e, data node 504f, data node 504 and cluster clients 520 bi-directionally coupled by network 512. Second data center 550 comprises a second cluster comprising configuration node 552, data node 554a, data node 554b, data node 554c, data node 554d and cluster clients 570 bi-directionally coupled by network 562.- data protection node – replica data node/data node; paragraph 0094 - According to one embodiment, each data node of architecture 500 acts as a separate server that listens for and can accept incoming requests from other components of the cluster architecture. Each data node maintains a data store, such as a database or file system and a transaction log.; paragraph 0006 - One embodiment includes a database replication system that comprises a plurality of data nodes, each data node in the plurality of data nodes comprising a processor and a memory. The plurality of data nodes includes a plurality of replica data nodes and a master data node. – the data nodes has its own power supply and separate communication to communicate).
As per claim 3, Pleshachkov et al. discloses wherein the data processing node is operable to receive a log saving success message returned by the other data processing node or the data protection node, and determine, based on the log saving success message, whether the log has been synchronized on at least one data protection node with distributed consistency being met (paragraph 0067 - Each replica data node 104b, 104c, 104d, 104e,104f, 104g that receives the log proposal 302 writes the transaction log records from the log proposal 302 to that node's replica node transaction log 107b, 107c, 107d, 107e, 107f, 107g, respectively (step 206). When the transaction log records from log proposal 302 are successfully written to a replica data node's persistent transaction log, the replica data node 104b, 104c, 104d, 104e, 104f, 104g sends an acknowledgement to master data node 104a (step 208) to indicate that the replica node 104b, 104c, 104d, 104e, 104f, 104g has updated its replica node log 107b, 107c, 107d, 107e, 107f, 107g with the transaction log records from log proposal 302.).
As per claims 7,14, Pleshachkov et al. discloses wherein for each of the at least one data processing node: in response to determining that the data processing node is a candidate to be elected as a master node, the data processing node is configured to send a first master node election request to other data processing node and the at least one data protection node, and to receive a first master node election message returned by one or more of the other data processing node or the at least one data protection node (paragraph 0086 - The replica data nodes 404b, 404c, 404d, 404e and 404f further exchange the highest LSN in each replica data node's persistently stored replica node transaction log. The replica data nodes are configured to select the data node with the highest LSN as the new master data node. If the highest LSN is shared by two or more of the replica data nodes, the replica data nodes are configured to select the replica data node that created the replica ephemeral data structure 434b, 434c, 434d, 434e, 434f, 434g with the lowest sequence number as the new master data node.); and
in response to determining, based on the first master node election message, that the data processing node is a master node, the data processing node is configured to generate, in response to the received database operation, the log corresponding to the database operation, and send the log to all the other data processing node and all data protection node of the first database (paragraph 0087 - Thus, as illustrated in FIG. 4C, data node 404b becomes the master data node and creates a new master ephemeral data structure 440.; paragraph 0088 - The rLastAckLSN in data node 404b's stored transaction log becomes the new mLastAckLSN. New master data node 404b performs redo of transaction log records from the last checkpoint to mLastAckLSN in master data node 404b's persistently stored transaction log. During redo, master data node 404b sends a log proposal to replica data node 404c, 404d, 404e, 404f, 404g for commit log records. Master data node 404b undoes changes for unfinished transactions (e.g., transactions for which the persistent transaction log of data node 404b does not have a commit log record).).
As per claims 8,15, Pleshachkov et al. discloses wherein the first database further includes at least one election node, and in response to being incapable of determining a master node based on the first master node election message, the data processing node is configured to send a second master node election request to the other data processing node, the at least one data protection node, and the at least one election node, to receive a second master node election message returned by one or more of the other data processing node, the at least one data protection node, or the at least one election node, and to determine the master node based on the second master node election message (paragraph 0086 - The replica data nodes 404b, 404c, 404d, 404e and 404f further exchange the highest LSN in each replica data node's persistently stored replica node transaction log. The replica data nodes are configured to select the data node with the highest LSN as the new master data node. If the highest LSN is shared by two or more of the replica data nodes, the replica data nodes are configured to select the replica data node that created the replica ephemeral data structure 434b, 434c, 434d, 434e, 434f, 434g with the lowest sequence number as the new master data node. – this process is carried out in order to select a new master which includes if there was a problem in determining the new master).
As per claim 9, Pleshachkov et al. discloses a database disaster recovery method, applied to a data processing node in a first database, the first database including at least one data processing node and at least one data protection node, a data protection node of the at least one data protection node and a data processing node of the at least one data processing node being separate from each other (Figure 5 and paragraphs 0007,0093,0094 – first database – first data center; master data node – data processing node; replica data node – data protection node; paragraph 0006 - One embodiment includes a database replication system that comprises a plurality of data nodes, each data node in the plurality of data nodes comprising a processor and a memory. The plurality of data nodes includes a plurality of replica data nodes and a master data node.), and the method comprising:
generating, in response to a database operation, a log corresponding to the database operation; sending the log to other data processing node of the at least one data processing node and the at least one data protection node of the first database for at least one data protection node of the first database to synchronize the log, with each of the at least one data processing node and the at least one data protection node meeting distributed consistency for storage; (Figure 5 and paragraph 0007 - The master data node is configured to send, to the plurality of replica data nodes, a transaction log record that includes an update to data in the master database that has not been committed to the master database. More particularly, according to one embodiment, the master data node may be configured to maintain a master node transaction log in persistent memory, write the transaction log record from master data node volatile memory to the master node transaction log in persistent memory and send the transaction log record to the plurality of replica data nodes after writing the transaction log record to the master node transaction log. The master data node can be configured, for example, to send the transaction log record to each replica data node in a replication group. The replication group may include replica data nodes at different data centers.; paragraph 0093 - FIG. 5 is a diagrammatic representation of one embodiment of a cluster architecture 500 that includes a first data center 501 and a second data center 550. First data center 501 comprises a first cluster including configuration node 502, data node 504a, data node 504b, data node 504c, data node 504d, data node 504e, data node 504f, data node 504 and cluster clients 520 bi-directionally coupled by network 512. Second data center 550 comprises a second cluster comprising configuration node 552, data node 554a, data node 554b, data node 554c, data node 554d and cluster clients 570 bi-directionally coupled by network 562.);
and
in response to the first database experiencing an anomaly of a first type and the data processing node itself experiencing no anomaly, providing a database service based on a log stored in the data protection node (paragraph 0096 - With multiple copies of the same data set on different data nodes in the cluster, the replication group provides a level of fault tolerance against the loss of a single data node. A replication group can provide increased query performance since the system can distribute the queries on the data set over different data nodes of the replication group. – type of fault is data node failure).
As per claim 11, Pleshachkov et al. discloses wherein the sending the log for the data protection node of the first database to synchronize the log includes: sending the log to the other data processing node and the at least one data protection node of the first database for storage; receiving a log saving success message returned by one or more of the other data processing node or the at least one data protection node; and determining, based on the log saving success message, whether the log has been synchronized on the data protection node with distributed consistency being met (paragraph 0066 - master data node 104a sends a log proposal 302 containing transaction log records subsequent to the mlastAckLSN to the replica nodes (step 204). In the example of FIG. 3B, master data node 104a sends log proposal 302 containing transaction log records with LSNs 1004-1006 to the replica data nodes.; paragraph 0067 - Each replica data node 104b, 104c, 104d, 104e,104f, 104g that receives the log proposal 302 writes the transaction log records from the log proposal 302 to that node's replica node transaction log 107b, 107c, 107d, 107e, 107f, 107g, respectively (step 206). When the transaction log records from log proposal 302 are successfully written to a replica data node's persistent transaction log, the replica data node 104b, 104c, 104d, 104e, 104f, 104g sends an acknowledgement to master data node 104a (step 208) to indicate that the replica node 104b, 104c, 104d, 104e, 104f, 104g has updated its replica node log 107b, 107c, 107d, 107e, 107f, 107g with the transaction log records from log proposal 302.).
As per claim 16, Pleshachkov et al. discloses a database disaster recovery method, applied to a data protection node in a first database, the first database including at least one data processing node and at least one data protection node, a data protection node of the at least one data protection node and a data processing node of the at least one data processing node being separate from each other (Figure 5 and paragraphs 0007,0093,0094 – first database – first data center; master data node – data processing node; replica data node – data protection node), and the method comprising:
receiving and storing a log transmitted by the data processing node, the log being a log generated by the data processing node in response to a database operation and corresponding to the database operation (Figure 5 and paragraph 0007 - The master data node is configured to send, to the plurality of replica data nodes, a transaction log record that includes an update to data in the master database that has not been committed to the master database. More particularly, according to one embodiment, the master data node may be configured to maintain a master node transaction log in persistent memory, write the transaction log record from master data node volatile memory to the master node transaction log in persistent memory and send the transaction log record to the plurality of replica data nodes after writing the transaction log record to the master node transaction log. The master data node can be configured, for example, to send the transaction log record to each replica data node in a replication group. The replication group may include replica data nodes at different data centers.; paragraph 0093 - FIG. 5 is a diagrammatic representation of one embodiment of a cluster architecture 500 that includes a first data center 501 and a second data center 550. First data center 501 comprises a first cluster including configuration node 502, data node 504a, data node 504b, data node 504c, data node 504d, data node 504e, data node 504f, data node 504 and cluster clients 520 bi-directionally coupled by network 512. Second data center 550 comprises a second cluster comprising configuration node 552, data node 554a, data node 554b, data node 554c, data node 554d and cluster clients 570 bi-directionally coupled by network 562.); and
in response to the first database experiencing an anomaly of a first type, providing, by the data protection node, a log stored by the data protection node to a first data processing node not having the anomaly of the first database for the first data processing node to provide a database service based on the log provided by the data protection node (paragraph 0096 - With multiple copies of the same data set on different data nodes in the cluster, the replication group provides a level of fault tolerance against the loss of a single data node. A replication group can provide increased query performance since the system can distribute the queries on the data set over different data nodes of the replication group. – type of fault is data node failure).
As per claim 19, Pleshachkov et al. discloses further comprising: in response to the first database experiencing no anomaly, asynchronously transmitting, to a second database, a log saved by the data protection node (Figure 5 and paragraph 0007 - The master data node is configured to send, to the plurality of replica data nodes, a transaction log record that includes an update to data in the master database that has not been committed to the master database. More particularly, according to one embodiment, the master data node may be configured to maintain a master node transaction log in persistent memory, write the transaction log record from master data node volatile memory to the master node transaction log in persistent memory and send the transaction log record to the plurality of replica data nodes after writing the transaction log record to the master node transaction log. The master data node can be configured, for example, to send the transaction log record to each replica data node in a replication group. The replication group may include replica data nodes at different data centers.).
As per claim 20, Pleshachkov et al. discloses further comprising: sending a log saving success message to the data processing node, the log saving success message indicating the log has been synchronized on the data protection node with distributed consistency being met (paragraph 0067 - Each replica data node 104b, 104c, 104d, 104e,104f, 104g that receives the log proposal 302 writes the transaction log records from the log proposal 302 to that node's replica node transaction log 107b, 107c, 107d, 107e, 107f, 107g, respectively (step 206). When the transaction log records from log proposal 302 are successfully written to a replica data node's persistent transaction log, the replica data node 104b, 104c, 104d, 104e, 104f, 104g sends an acknowledgement to master data node 104a (step 208) to indicate that the replica node 104b, 104c, 104d, 104e, 104f, 104g has updated its replica node log 107b, 107c, 107d, 107e, 107f, 107g with the transaction log records from log proposal 302.).
There is no prior art rejection because either no prior art could be found or no reason to combine with prior art found.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Yolanda L Wilson whose telephone number is (571)272-3653. The examiner can normally be reached M-F (7:30 am - 4 pm).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bryce Bonzo can be reached at 571-272-3655. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Yolanda L Wilson/ Primary Examiner, Art Unit 2113
Prosecution Insights