Ensuring the same completion status for transactions after recovery in a synchronous replication environment

Disclosed in some examples is a method, the method including detecting that an RDMS is recovering from a failure; sending a request for a last committed transaction on a replication component to the replication component; receiving, from the replication component, the last committed transaction which identifies a transaction that was the last committed transaction at a replication component at a time of RDMS failure; determining that a transaction log on the RDMS includes a transaction that had not yet been replicated at the time of RDMS failure which was committed on the transaction log subsequent to the last committed transaction received from the replication component; and based on that determination rolling back the transaction that had not yet been replicated at the time of RDMS failure.

BACKGROUND

A Relational Database Management System (RDMS) is a database management system that is based on the relational database model. A database management system can be a software application (which can execute on one or more hardware resources) providing the interface between user database tasks and a database or databases. The RDMS provides for storing data in a database, defining and manipulating data structures from the database, updating data in the database, deleting data in the database, inserting data in the database, retrieving data from the database, administering the database and other functions. One of the main goals of an RDMS is to ensure database Atomicity, Consistency, Integrity, and Duration—also known by the acronym ACID. ACID properties ensure that database transactions are processed reliably.

An RDMS operates on the concept of transactions. A transaction is a unit of work performed within a database management system against a database, and is treated in a coherent and reliable way independent of other transactions. A transaction typically ends with the issuance of a COMMIT instruction.

DETAILED DESCRIPTION

Disclosed herein are some examples of methods, systems, machines (e.g., RDMSs, replication components), and machine-readable mediums which are capable of enhancing data continuity in a situation in which an RDMS and a replication component which assists in replicating one or more databases on the RDMS are not in agreement on the state of one of the replicated databases after the RDMS recovers from a failure event.

FIG. 1shows a schematic of a replication database system1000according to an example embodiment. Embodiments describe an RDMS system1010featuring database replication. The RDMS1010can include one or more data stores1040that may store one or more structured relational databases (hereinafter referred to as “database” or “databases”). The RDMS1000may include or be executed on one or more computing systems. The RDMS1010can include a database manager module1030and one or more data stores1040. The database manager module1030manages data stored in the data store1040. For example, the database manager module1030can organize, track, and control data stored in the data store1040to form the one or more structured relational databases.

Database replication involves replication of transactions in an RDMS1010across one or multiple databases (e.g., on other RDMSs1060) to allow for multiple copies of the database to be stored in multiple electronic locations. The RDMS1010can include a replication agent module1050to replicate transactions to one or more other RDMS1060or other devices1070(e.g., a mobile device, smartphone, desktop, tablet computer, laptop computer, and the like) through a replication component1090. Embodiments provide distributed access to allow information (e.g., data stored in data store1040) to be better shared, and to provide backup copies of the database. Replication of transactions from the database (e.g., database in data store1040) in the RDMS1010can be achieved by the replication component1090. Replication agent module1050, database manager module1030, database task module1020may reside on one or more computing systems of the RDMS1010.

The RDMS1010replicates changes in the database, via the replication agent module1050, to the replication component1090. The replication component1090can replicate the data (e.g., changes in the database) towards other copies of the database stored in other electronic locations.

Database tasks (e.g., database task module1020), running on the RDMS1010, implement functionality and can modify the database (e.g., through Simply Query Language (SQL) instructions). These modifications are made by the RDMS1010by writing database commands to a transaction log1045for the database kept by the RDMS1010. The transaction log1045can be stored on the data store1040of the RDMS1010and can comprise a series of database commands.

The RDMS1010can include one or more user database task modules1020. The database task modules1020can be any process, thread, or program which can make changes to the databases stored in data store1040and managed by the database manager module1030. The database task module1020can provide one or more services to users (e.g., clients) using the data stored in the data store1040. The database task module1020can read from, write to, and modify data in the data store1040by issuing commands to the database manager module1030. In some example embodiments, the database task module1020can use one or more Structured Query Language (SQL) commands to access and modify data stored in the data store1040.

A “Private Log Cache” (PLC)1055also known as a “User Log Cache” can be stored in memory of the RDMS1010. The PLC1055may be stored in either volatile or non-volatile memory. For example, the PLC1055may be stored in volatile memory (e.g., Random Access Memory). In some examples, each particular database task module1020may have a PLC1055associated with it which may be stored in RAM associated with the particular task module1020. The PLC1055may collect commands written by the database task module1020.

As there may be multiple database tasks (e.g., multiple instances of database task module1020) writing to the transaction log (e.g., transaction log1045) simultaneously (or near simultaneously), cause contention-based delays may occur while waiting for access to write to the transaction log. Scalability and performance of replication may be improved by having each database task first write database commands to a PLC1055. The PLC1055can be flushed by the RDMS1010to the transaction log1045and ultimately written to disk at various times and in response to various triggering events. For example, the PLC1055can be flushed if the PLC is full, if a transaction is committed as a result of a commit SQL command, or the like. Once the PLC is flushed, the database manager module1030can log the changes made to the data store1040in a transaction log which can be stored in the data store1040.

To perform replication, the RDMS1010can send changes made to the transaction log1045to the replication component1090. The replication component1090can, for example, store these changes in a transaction log of its own1105. For example, the transaction log may be stored in a simple persistent queue (SPQ) in a data store1110at the replication component1090. The SPQ can disseminate the transaction log1105to other electronic sites, such as other RDMSs1060.

While writing the PLC1055to the transaction log1045and ultimately to disk, the RDMS1010can replicate the updates to the replication component1090. For an asynchronous replication, the database task (e.g., database task module1020) can continue as soon as the transaction is written to disk. For a synchronous replication, the database task should block waiting for the RDMS1010to replicate the transaction log1045to the replication component1090and for the RDMS1010to write the transaction log1045to disk. In order to reduce the latency in this process, the flush of the transaction log1045to disk and the replication of the transaction log1045to the replication component1090can be done in parallel.

A replication agent module1050can monitor the PLC1055for transactions marked for replication. The replication agent module1050can replicate these transactions to one or more other RDMSs1060or other devices1070. For example, the replication agent module1050can send information on transactions marked for replication, as well as information on which transactions have already been written to the transaction log on disk. In addition, the replication agent module1050can determine when to notify database task module1020when a database commit transaction is completed. For example, in an asynchronous replication mode, the replication agent module1050can return success to the database task module1020once the transaction is written to the data store1040. In a synchronous replication mode, the replication agent module1050can wait for both confirmation that the transaction was written to the transaction log1045(e.g., a disk I/O (input/output) is complete) as well as confirmation from the replication component1090. The replication component1090can be accessible over a packet-based network1080(e.g., the internet, a local area network, a wide area network, or the like). In some example embodiments, the replication agent module3050can determine changes to the data store3040based upon the transaction log managed by the database manager module3030.

As a result of this design, some transactions can be replicated before they are written to disk, and other transactions can be written to disk before they are replicated. For example, the replication component1090can return a confirmation to the RDMS1010prior to a disk I/O (input/output) completion for the transaction log1045or vice versa. Accordingly, at any given moment, the following four situations are possible:1. The transactions in the transaction log1045and the transaction log1105on the replication component1090are the same.2. A transaction has not been written to either the transaction log1045or the transaction log1115on the replication component.3. A transaction has been written to the transaction log1045for example, when a disk I/O is complete, but not to the transaction log1105on the replication component.4. A transaction has been written to the transaction log1105on the replication component but not the transaction log1045.

Situations one and two represent a state of events in which both the transaction log1045on the RDMS1010and the transaction log1105on the replication component1090are the same. For situation three, the RDMS1010can notify the replication component1090about the transaction and move to situation one where both the RDMS1010and the replication component1090are in sync. Situation four can occur if the changes to the transaction log1045were sent to the replication component prior to being written to disk. This can cause a transaction, which is not yet written to the transaction log1045(situation four) of RDMS1010, to be written to the transaction log1105of replication component1090. Once the process that writes the database transactions to disk on the local RDMS1010catches up, situation four would be corrected. For situation three and four, the transaction will not be considered committed until these situations resolve themselves and move to situation 1.

As can be appreciated from the above discussion, situations where the RDMS1010and the replication component1090are not in sync are usually temporary and are likely to be quickly resolved. However, if the RDMS1010were to become unavailable prior to the resolution of one of those situations, the RDMS1010and the replication component1090can become out of sync at the time the RDMS1010went out of service. If the RDMS1010is down for a short time period, specialized messaging protocols can ensure that the RDMS1010and the replication component resynchronize. If the primary (active RDMS (e.g., RDMS1010) is down for a longer period of time, operations can be switched to a standby RDMS (e.g., RDMS1060). The database in RDMS1010may be replicated to the standby RDMS1060, and the standby RDMS1060can then replace RDMS1010as the primary (active) RDMS. When the RDMS that was previously the primary RDMS (e.g., RDMS1010) comes back in service, in some examples this RDMS will come back as a standby RDMS. In order to be a standby RDMS, in some examples, the standby resynchronizes with the replication component. The standby RDMS (which was the active RDMS before failure, such as RDMS1010) will not be aware of transactions that it sent to the replication component1090that were not also stored to the transaction log1045on disk prior to failing because the changes to the database had not been moved out of volatile memory to disk and were therefore lost. The replication component1090and the newly active RDMS will not be aware of any transactions that were stored to disk of the current standby RDMS (which was the active RDMS before failure, such as RDMS1010), but that were not sent to the replication component1090. In the time it takes for the failed RDMS (e.g., RDMS1010) to come back in service and to assume the standby role, additional transactions could have been processed by the newly active RDMS (e.g., RDMS1060).

For example, assuming data is being replicated from RDMS1010which is the active RDMS, to RDMS1060, which is a standby RDMS, if RDMS1010and RDMS1060are in sync, and RDMS1010goes down and then comes back up, RDMS1010switches to standby and RDMS1060switches to active. Transactions can then replicate (using the replication component1090) from RDMS1060to RDMS1010. If, however, at the time that RDMS1010fails, a transaction X was stored on disk in the local transaction log1045, but was not replicated in the transaction log1105of the replication component (situation 3), then RDMS1060will not know about the transaction. When RDMS1010restarts it will have the extra transaction X and the replication database system1000should not replicate from RDMS1060to RDMS1010. Similarly, if at the time that RDMS1010fails, the transaction X was stored in the transaction log1105(e.g., the SPQ) of the replication component but transaction X was not written to the RDMS1010disk (situation 4), then the replication database system should not replicate RDMS1060to RDMS1010.

The example embodiments disclosed herein can address situations three and four described above so that they can be handled appropriately to preserve the ACID properties of the RDMS'1010and1060. In some example embodiments to address situation three, when the RDMS (e.g., RDMS1010) that failed comes back online (as a standby RDMS), the RDMS1010can exchange information with the replication component1090to determine the last committed transaction that had reached the replication component1090at the time of failure. Any transactions written in the transaction log1045(e.g., to disk) on RDMS1010, but not at the replication component1090at the time of failure of RDMS1010, are rolled back at that RDMS. In some examples, the transactions are rolled back by inserting one or more log records which reverse the work of the transaction. In some example embodiments, to address situation four, the replication component1090also queries the RDMS1010to determine the last committed transaction in the transaction log1045of the RDMS1010. The replication component1090can replicate to the RDMS1010any transactions that had reached the replication component1090but were not stored to disk in the transaction log1045of the RDMS1010at the time of failure of the RDMS1010. These transactions are reapplied to the database on the RDMS1010. Once both the RDMS1010and the replication component1090are in sync as of the time of failure of the RDMS1010, any new transactions committed by a second, newly active, RDMS1060(which may have switched from being a standby at the time of failure of the primary), which were processed after the failure of the RDMS1010, can be replicated to the RDMS1060from the replication component1090.

Replication operations can utilize the replication component1090to assist in replicating data from the data store1040to the other RDMSs1060, the devices1070, and the like. The RDMS1060and the device1070can be connected to the replication component1090through the network1085. The network1085can be, or include, portions of the network1080. The replication component1090can include a replication module1100and a data store1110. The replication module1100can communicate with the replication agent module1050from the RDMS1010and other replication agent modules on the devices1070and the RDMS1060. The replication module1100can receive subscription requests from devices that wish to receive updates to the data and when updates are reported by a replication agent (e.g., the replication agent module1050), the replication module1100can update the data in its local data store1110and can send updates to subscribed devices based upon device subscriptions. The replication module1100can respond to a device which updates the database with a confirmation upon receipt of an indication describing the change. In other examples, the confirmation may be sent upon storage of the update. Replication component1090can be or include one or more computing systems which may execute the replication module1100and communicate with or provide data store1110.

The replication agent module1050can also receive information on updates to data stored in other data stores associated with other RDMSs, such as the RDMS1060, the devices1070and the like. The replication agent module1050can subscribe to receive updates to data on the data store1040with the replication component1090so as to receive updates from other devices which can update the data. The replication agent module1050can notify the database task module1020, the database manager module1030or other processes on the RDMS1010of any received changes. The replication agent module1050can then commit received changes to the data store1040either directly or through the database manager module1030or the database task module1020.

The replication agent module1050can assist in resynchronizing with the replication component1090after failure of an RDMS and during the subsequent recovery. For example, the replication agent module1050can query the replication module1100of the replication component1090to determine the last committed transaction on the replication component1090. The replication agent module1050can then rollback any transactions committed at the RDMS1010but not at the replication component1090. The replication agent module1050can do this by working with the database manager module1030to change COMMIT instructions for transactions committed after the last committed transaction on the replication component1090in the transaction log to NO-OP instructions, utilizing clear transactions for database commands and ABORT commands for transactions that remained open after the last confirmed transaction. The replication agent module1050can also work with replication module1100respond to inquiries from the replication module1100to provide a last committed transaction for the transaction log. The replication module1100can utilize the last committed transaction to determine which transactions were replicated to the replication component1090but were not written to the transaction log1045of the RDMS1010. The replication component1090can send these transactions to the replication agent module1050. The replication agent module1050can work with the database manager module1030to apply these transactions to the transaction log. The replication agent module1050can also register with the replication component1090to replicate the database of RDMS 21060upon returning from failure as a standby RDMS1010.

The RDMS1010can include additional modules not shown which manage the database, execute SQL statements, manage the database task module1020, and the like. Further, in some example embodiments, one or more modules may be combined.

FIG. 2shows a flowchart of a method2000, in accordance with an example embodiment, performed by an RDMS (e.g., RDMS1010inFIG. 1) to resynchronize the RDMS with a replication component (e.g., replication component1090inFIG. 1). The method2000can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. At operation2010, the RDMS goes in-service (INS) after previously being out of service. The RDMS then, as shown at operation2020, can request the last committed transaction at the time of failure from the replication component for the database managed by the RDMS.

At operation2030, the RDMS can receive the response from the replication component which includes the last committed transaction for the database at the time of failure of the RDMS. At decision2040, the RDMS can determine whether the RDMS has a later committed transaction. The RDMS can compare the last committed transaction in its transaction log with the last committed transaction at the time of RDMS failure received from the replication component. If the last committed transaction in the local transaction log and the last committed transaction in the replication component are the same (decision2040), then startup of the RDMS continues at operation2060. If the RDMS has a later transaction than the replication component (decision2040), the RDMS can rollback these later transactions, as shown at operation2050, and continue startup at operation2060. For example, if the RDMS transaction log has transaction 1, 2, 3 and 4 committed, and if the last committed transaction at the time of failure of the RDMS at the replication component is transaction 4, then the databases were in sync at the time the RDMS failed. If instead, the last committed transaction at the time of failure of the RDMS at the replication component is transaction 2, then the RDMS rolls back transactions 3 and 4 from the database.

As an example rollback operation, assume that at the time of the RDMS failure, the database on the RDMS site had four transactions: T1 is the last committed transaction in the replication component at the time of RDMS failure; T2 was committed after T1, but had not yet been replicated to the replication component at the time of the failure; T3NR is a transaction which is not replicated; and T4 is a transaction that is not committed at the time of the RDMS failure; and the transaction log of the RDMS contained the following example entries upon restart:Begin transaction T1Insert (T1)Begin Transaction T2Insert (T2)*Commit (T1)<=Last Com. Trans. at the External Rep. Comp.Commit (T2)Begin Transaction T3NRBegin Transaction T4Insert (T4)Insert (T3NR)Commit (T3NR)

First, the commit record of transaction T2 (and any commit after the last committed transaction at the external replication component) can be changed to a NO-OP. Thus the transaction log can be changed (e.g., by the database manager module1030, the replication agent module1050, or the like) at operation2050to:Begin transaction T1Insert (T1)Begin Transaction T2Insert (T2)*Commit (T1)<=Last Com. Trans. at the External Rep. Comp.NOOP (T2)Begin Transaction T3NRBegin Transaction T4Insert (T4)Insert (T3NR)Commit (T3NR)

As transaction T3NR is a transaction that is not replicated, the RDMS does not have to update the replication component about the T3NR transaction, thus this transaction may be left as-is. The commands of the transaction T4 (and any other open transactions as of the time of RDMS failure) should be rolled back, for example, at operation2050. For T2, even though T2 is committed in the transaction log at the time of the failure, since its COMMIT record was changed to a NOOP record, this transaction will be treated by the RDMS as an open transaction as well. Commands in these transactions may be cleared with a CLR command. Finally, an ABORT log record is written to the transaction log to indicate the end status of these transactions. For example:Begin transaction T1Insert (T1)Begin Transaction T2Insert (T2)*Commit (T1)<=Last Com. Trans. at the External Rep. Comp.NOOP (T2)Begin Transaction T3NRBegin Transaction T4Insert (T4)Insert (T3NR)Commit (T3NR)CLR(INS t4)ABORT (T4)CLR(INS T2)ABORT(T2)

Returning toFIG. 2, once the appropriate transactions have been rolled back at operation2050, the method2000proceeds to operation2060to continue the startup procedures of the RDMS.

In some example embodiments, the RDMS can manage multiple databases. Accordingly, the RDMS can perform the method2000for each of the different databases that are managed by the RDMS. In some example embodiments, different databases that are managed by the same RDMS can replicate to different replication components. In these examples, the RDMS can contact the replication component corresponding to the particular database the RDMS is trying to synchronize (e.g., see operation2020) in order to determine the last committed transaction for each database.

Once the RDMS has completed the recovery for every user database by rolling back the committed transactions that were not replicated in the replication component, and the open transactions at the time of failure (e.g., see situation three), the RDMS can begin operating in the standby role. Before the replication direction is switched from the old standby (newly primary RDMS) to the new standby (old primary RDMS), the replication component can perform operations to ensure that any transactions replicated to the replication component, but not written to the transaction log of the old primary RDMS (e.g., see situation four), are written back to the RDMS.

FIG. 3shows a flowchart of a method3000, in accordance with an example embodiment, performed by a replication component (e.g., replication component1090inFIG. 1) to resynchronize the replication component with an RDMS (e.g., RDMS1010inFIG. 1). The method3000can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. At operation3005, the replication component can detect that the RDMS has come back in service after being out of service long enough to trigger a switchover of a standby RDMS to be an active RDMS (and the subsequent recovery of the previously active RDMS puts that RDMS in a standby mode). In some example embodiments, the replication component can be notified of this by a disaster recovery (DR) component on the RDMS.

If the RDMS comes back in service prior to a switchover of the standby RDMS to being an active RDMS, the remaining steps ofFIG. 3may not be performed. In these examples the external replication component will not replicate any unconfirmed commands back to the RDMS. In these examples, when the RDMS comes back online, the replication component will skip all unconfirmed commands as it expects the RDMS to resend those commands if there were committed but not yet confirmed to replication component. The external replication component will not replicate unconfirmed commands and therefore, there will be no unconfirmed commands being applied back to an active RDMS.

If the RDMS was down long enough to trigger a switchover, and subsequence to the external replication component being notified of this at operation3005, as shown at operation3010, the replication component can contact the RDMS to obtain the last committed transaction on the RDMS' transaction log. The replication component can receive the last committed transaction on the RDMS′ transaction log from the RDMS (see operation3020). The value received from the RDMS at operation3020can be the same value as that returned by the replication component at operation2030inFIG. 2or can be a different value. The value returned would be the same if the RDMS and the replication component were in sync at the time of failure, or if the RDMS had more transactions committed than the replication component at the time of failure. In this latter case, the RDMS would have previously rolled back any additional transactions (e.g., using the method2000ofFIG. 2) such that the latest transaction would have been the latest committed transaction at the replication component at the time of RDMS failure. In other examples, if the replication component has more transactions than the RDMS, the value returned can be less than the last committed transaction at the replication component.

In some example embodiments, transactions received from the RDMS on the replication component can be considered by the replication component as confirmed or unconfirmed. When an RDMS is replicating with a replication component, the changes to the transaction log can be sent in replication packages. Each replication package can contain one or more commands. Each command contains a monotonically increasing unique command identifier. The replication package can also contain an identifier of the last committed transaction that was written to the disk of the RDMS. As already noted, the tasks on the RDMS that are writing to the transaction log and the tasks on the RDMS that are sending the replication packages to the replication component can run in parallel. Thus, it can be the case that the last transaction identifier written to disk is less than the last transaction identifier in the replication package. The replication component can consider transactions with a unique command identifier that is greater than the identifier of the last command written to disk as “unconfirmed” transactions. In an example embodiment, the replication component does not replicate transactions to other RDMSs that are not confirmed. If an RDMS goes down (and does not immediately come back up) or is otherwise unavailable, and if the replication database system switches the standby RDMS to the active RDMS all unconfirmed transactions in the replication component can be assumed to be committed.

At operation3020, the replication component can receive the last committed transaction at the RDMS. Thereafter, at operation3030, the last committed transaction of the RDMS is compared to any unconfirmed transactions at the time of RDMS failure on the replication component. If any of the unconfirmed transactions are not committed on the RDMS, then these transactions are sent to the RDMS (as the replication component assumed that those transactions were committed when the RDMS failed). For each unconfirmed transaction that is sent to the RDMS, information on the transaction (e.g., the commands) can be sent to the RDMS (see operation3040). If there are no new unconfirmed transactions at operation3030, then the RDMS may continue startup procedures at operation3060.

Once the RDMS receives these transactions, the RDMS and the replication component should then be synchronized as of the time when the RDMS went out of service. Thereafter, at operation3050, any transactions that occurred on the new active RDMS (old standby RDMS) while the RDMS was down, can be replicated to the standby RDMS (old active RDMS) to bring the standby RDMS (old active RDMS) into complete synchronization.

Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and can be configured or arranged in a certain manner. In an example, circuits can be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors can be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

Machine (e.g., computer system)4000can include a hardware processor4002(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory4004and a static memory4006, some or all of which can communicate with each other via an interlink (e.g., bus)4008. The machine4000can further include a video display4010, an alphanumeric input device4012(e.g., a keyboard), and a user interface (UI) navigation device4014(e.g., a mouse). In an example, the video display4010, alphanumeric input device4012and UI navigation device4014can be a touch screen display. The machine4000can additionally include a storage device (e.g., drive unit)4016, a signal generation device4018(e.g., a speaker), a network interface device4020, and one or more sensors4021, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine4000can include an output controller4028, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage device4016can include a machine readable medium4022on which is stored one or more sets of data structures or instructions4024(e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions4024can also reside, completely or at least partially, within the main memory4004, within the static memory4006, or within the hardware processor4002during execution thereof by the machine4000. In an example, one or any combination of the hardware processor4002, the main memory4004, the static memory4006, or the storage device4016can constitute machine readable media.

While the machine readable medium4022is illustrated as a single medium, the term “machine readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions4024.

The term “machine readable medium” can include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine4000and that cause the machine4000to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of machine readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); Solid State Drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, machine readable media can include non-transitory machine readable media. In some examples, machine readable media can include machine readable media that is not a transitory propagating signal.