Database replication with host version upgrade

Abstract

Various examples are directed to systems and methods for operating a database management system. A first version of a first host may run at a first container of a cloud environment. The second version of the second host may run at a second container of the cloud environment. The first host may be configured to execute a source role, and the second host may be configured to execute a replica role corresponding to the source role. A network layer running in a cloud environment may receive a request directed to a second host. The network layer may determine that the request is consistent with allowed request data describing the allowed request, and may send the request to a second host.

Description

Background Art

[0001] When operating a database management system, it is desirable to include a backup mechanism to make the database management system more robust to failures. For example, when a primary system fails, a backup system can be used to restore and / or replace the primary system. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present disclosure is illustrated by way of example and not limitation in the following figures.

[0003] Figure 1 is a diagram illustrating one example of an environment including a cloud-implemented database management system.

[0004] Figure 2 It shows that it can be Figure 1 A flowchart of an example of a process flow that runs in an environment to upgrade a pair of hosts to a target version.

[0005] Figure 3 It shows that it can be Figure 1 A flowchart of another example of a process flow that is executed in an environment to upgrade a pair of hosts to a target version.

[0006] Figure 4 It shows that Figure 1 Flow diagram of another example of a process flow 400 executed in an environment to upgrade a pair of hosts to a target version.

[0007] Figure 5 It shows that it can be Figure 1 A flowchart of an example of a process flow that operates in an environment to handle communications associated with hosts running different versions.

[0008] Figure 6 It shows that it can be Figure 1 A flowchart of an example of a process flow executed in an environment to change an operating parameter of a host.

[0009] Figure 7 It shows that it can be Figure 1 A flowchart of another example of a process flow executed in an environment to change an operating parameter of a host.

[0010] Figure 8 is a diagram showing one example of an environment including a primary database management system and a secondary database management system.

[0011] Fig. 9 It is displayed in Figure 8 A flowchart of an example of a process flow running in an auxiliary database management system.

[0012] Fig.10 It shows that Figure 8 A flowchart of an example of a process flow that a coordinator component runs to respond to a takeover request.

[0013] Fig.11 is a diagram illustrating an example of an in-memory database management system that can be used to implement, for example, table permission management as described herein.

[0014] Fig.12 It is shown Fig.11 Diagram of an example of an index server of an in-memory database management system.

[0015] Fig.13 It is shown Fig.12 A diagram of an example of request processing and operation control of a database management system.

[0016] Fig.14 is a block diagram illustrating one example of an architecture for a computing device.

[0017] Fig.15 is a block diagram of a machine in the example form of a computer system within which instructions may be executed to cause the machine to perform any one or more of the methodologies discussed herein. DETAILED DESCRIPTION

[0018] Replication is an example backup mechanism for a database management system. According to replication, a replica database management system is maintained along with a source database management system. In the event of a failure of the source database management system, the replica database management system assumes the role of the source database management system. For example, requests that were previously directed to the source database management system can be directed to the previous replica database management system that now performs the role of the source database management system. In this way, recovery time, sometimes referred to as the recovery time objective (RTO), can be reduced. Because the replica database management system is maintained and updated with the source database management system, lost data can also be minimized. For example, the recovery point objective (RPO) may be close in time to the point in time when the source database management system fails.

[0019] In some examples, replication is implemented in a multi-host database management system. The multi-host database management system includes multiple hosts that behave as a single unit. For example, a client utilizing the database management system can direct requests to the database management system without specifying a particular host. The database management system can assign incoming requests to the appropriate host to run. Furthermore, in some examples, the multi-host database management system can be identified by a single system identifier (SID). In some examples, the multi-host database management system is arranged for a system administrator to perform various operations on the database management system as a whole, such as shutdown and startup.

[0020] Replication in a multi-master database management system can be handled on a host-by-host basis. For example, a host can perform a source role or a replica role associated with a source role. A host that performs a source role can respond to requests distributed by the database management system. A host that performs a replica role can remain with the source to remain consistent with the source. If a host that performs the source role fails, a takeover can occur and the host that previously performed the replica role will assume the source role. Consider an example including a first host that is configured to perform a source role and a second host that is configured to perform a replica role of the source role. The first host and the second host can remain consistent. If a failure involving the first host occurs, a takeover can be performed. Based on the takeover, the second host can be configured to perform the source role.

[0021] One potential disadvantage of master replication is that, while replica masters are always maintained, they may only be used when the corresponding source master fails. Some replication schemes address this and other issues through active-active arrangements. In an active-active arrangement, a replica master is configured to respond to read requests from clients. The database management system directs some read requests from clients to the replica master instead of the corresponding source master. In this way, the availability of the database management system can be improved and responses to client requests can be returned more quickly. In some examples, the database management system is arranged to direct resource-intensive read requests (e.g., online transaction processing (OLTP) and / or online analytical processing (OLAP) requests) to the master performing the replica role.

[0022] One challenge associated with replication scenarios involves maintaining master machines. For example, it is often necessary to upgrade a master from one version to another. However, to maintain replication, it is best to avoid shutting down both the master performing the source role and the master performing its corresponding replica role at the same time to avoid system downtime.

[0023] Some examples described herein address these and other challenges by continuously upgrading the host that performs the source role and the host that performs the corresponding replica role. While this arrangement can avoid system downtime, it can also result in a situation where the host that performs the source role and the host that performs the replica role are running different versions. When the host that performs the source role and the host that performs the replica role are running different versions, communication problems between the hosts can result. For example, communication problems can occur in an active-active arrangement. In an active-active arrangement, a host that performs a replica role can read data from a host that performs its corresponding source role. If the version differences between the source role and the replica role include differences in the database schema, read requests issued by the host that performs the replica role may not be read by the host that performs the source role. This can result in a variety of problems, including, for example, data corruption and system crashes.

[0024] Various examples address these and other challenges by leveraging a network layer in a database management system. The network layer can be configured to apply an allow list to directed hosts and / or requests between hosts, such as between hosts performing different roles. When a host performing a source role and a host performing a corresponding replica role are running different versions, an allow list can describe a set of requests that are permitted to be issued by or to a host performing a replica role. For example, an allow list can indicate requests related to replication, but requests related to an active-active arrangement can be ignored. For example, requests related to an active-active arrangement can be directed to a source role host instead of a replica role host.

[0025] Figure 1 1 is a diagram illustrating one example of an environment 100 including a cloud-implemented database management system 102. The environment 100 also includes one or more clients 104, 106, 108. Although three example clients 104, 106, 108 are shown, it should be understood that the environment 100 may include more or fewer clients. The clients 104, 106, 108 may be client applications configured to query the database management system 102. For example, the clients 104, 106, 108 may be or include SAP SE, available from, for example, Waldorf, Germany. Analytical computing system for analytical cloud applications; also available from SAP SE of Waldorf, Germany, such as SAP and project management resources provided by project management software solutions, such as SAP Portfolio Project Management (PaPM), also available from SAP SE of Waldorf, Germany.

[0026] The database management system 102 can be run in a cloud environment, such as a public cloud environment or a private cloud environment. In a private cloud environment, an enterprise implementing the database management system 102 can provide applications, storage, etc. to implement the database management system 102. The executable files and / or other software for implementing the database management system 102 in the private cloud environment can be provided by a software provider, for example.

[0027] In a public cloud environment, the database management system 102 may be provided as one of a plurality of leases implemented by a hyperscale customizer or other cloud service provider. The cloud service provider may provide one or more executable files or other components to implement the database management system 102 in the public cloud environment. An enterprise using the database management system 102 may hold one or more leases allowing clients 104, 106, 108 associated with the enterprise to access one or more instances of the database management system 102 in the public cloud environment.

[0028] In various examples, the database management system 102 is implemented in a cloud environment according to a microservices architecture. In a microservices architecture, different parts of the database management system 102 are implemented by a set of loosely coupled microservices running in a cloud environment. Each microservice may include a single executable file running in a container implemented by the cloud environment. In a microservices architecture, each microservice is programmed to perform a defined task or a small set of tasks and interact with other microservices in a defined manner (e.g., according to an application programming interface (API)). In some examples, each host 116, 118, 120, 122, 124, 126 operates as a separate, independent microservice running in its own container or set of containers.

[0029] Container orchestration service 110 can manage the operation of various containers that implement database management system components. In some examples, container orchestration service 110 can be or include Container Orchestration System. In various examples, container orchestration service 110 can start, restart, and / or modify containers that run various components of database management system 102.

[0030] The hosts 116, 118, 120, 122, 124, 126 include hosts 116, 120, and 124 that perform source roles and hosts 118, 122, and 126 that perform replica roles corresponding to the respective source roles. Figure 1 In the example of FIG. 1 , host 116 is performing a first source role. Host 118 is performing a first replica role corresponding to the first source role. Host 120 is performing a second source role, and host 122 is performing a second replica role corresponding to the second source role. Host 124 is performing a third source role, and host 126 is performing a third replica role corresponding to the third source role. It should be understood that although Figure 1 Six hosts 116, 118, 120, 122, 124, 126 are shown in FIG, but the database management system 102 may have more or fewer hosts. Figure 1 Examples include a master performing a replica role for each corresponding source role, but some implementations may not include a master performing a replica role for each corresponding source role.

[0031] Each host 116, 118, 120, 122, 124, 126 can run a corresponding container or set of containers. In some examples, container orchestration service 110 can manage the operation of hosts 116, 118, 120, 122, 124, 126. For example, if a host crashes, container orchestration service 110 can restart a new container for the crashed host. In some examples, a crashed host can be restarted from a container image, such as provided by Docker. image.

[0032] In some examples, the database management system 102 can also manage roles performed by multiple hosts 116, 118, 120, 122, 124, 126. For example, the network layer 112 can be configured to direct requests from clients 104, 106, 108 to and between respective hosts 116, 118, 120, 122, 124, 126. For example, the database management system 102 can configure a given host 116, 118, 120, 122, 124, 126 to perform a source role or a replica role. A host 116, 118, 120, 122, 124, 126 configured to perform a source role can receive read and write requests from clients 104, 106, 108. A host configured to perform a replica role may not receive requests from clients 104, 106, 108. In some examples, as described herein, a host configured to perform a replica role may receive some read requests from clients 104, 106, 108, for example, according to an active-active arrangement.

[0033] The database management system 102 can be configured to perform replication between a host performing a source role and a host performing a corresponding replica role. For example, each host 116, 118, 120, 122, 124, 126 can have an associated persistence 128, 130, 132, 134, 136, 138. The persistence 128, 130, 132, 134, 136, 138 can include data storage resources of the cloud environment allocated to the corresponding host 116, 118, 120, 122, 124, 126 for use.

[0034] In some examples, database management system 102 may be an in-memory database management system. For example, hosts 116, 118, 120, 122, 124, 126 may store data constituting a database in random access memory associated with a corresponding container. Requests issued to the host may be executed against the in-memory data.

[0035] The persistence 128, 130, 132, 134, 136, 138 associated with the respective hosts 116, 118, 120, 122, 124 may include respective data volumes and log volumes. The data volumes associated with the hosts may include snapshot data describing the data stored in memory by the hosts. For example, the data volumes of the hosts may be periodically created from the data in memory of the hosts. The snapshot data stored in the respective data volumes may have an associated snapshot time. The snapshot time of the data volume indicates the time when the snapshot data stored in the data volume was last reconciled with the data in memory stored by the hosts. The log volumes (also referred to as redo log buffers) associated with the hosts store redo logs. The redo logs describe the write operations performed on the respective hosts. The redo logs may be replayed to recreate the write operations described by the redo logs.

[0036] In general, the log volumes and data volumes associated with a host can be used to recreate the state of the host. For example, snapshot data in a data volume can be loaded into the random access memory of the host. Subsequently, redo logs created after the snapshot time can be replayed on the host. This can recreate the state of the host up to the time of the most recent redo log. It will be appreciated that in some examples, recreating a host from its associated data volumes and log volumes can be a time-consuming operation. For example, loading a snapshot of data from a data volume into the random access memory of the host can take a considerable amount of time, thereby extending the RTO of the system. Utilizing the replica role host described herein can reduce the RTO. For example, the replica role host may begin to perform a takeover of the source role in much less time than it would take to recreate the original source role host from its data volumes and log volumes.

[0037] The database management system 102 can manage replication between the host 116, 120, 124 performing the source role and the host 118, 122, 126 performing the corresponding replica role. In some examples, the replication can be synchronous. For example, when a write request is run on the host 116, 120, 124 performing the source role, the database management system 102 can write the redo log to the log volume associated with the host 116, 120, 124. The database management system 102 can also write the redo log to the log volume associated with the host 118, 122, 126 performing the replica role corresponding to the source role. The host 118, 122, 126 performing the replica role can also replay the redo log. In this way, the state of the host 118, 122, 126 performing the replica role can be consistent with the state of the host 116, 120, 124 performing the source role. In some examples, a host 118, 122, 126 performing the source role may not submit a write request until it receives an indication that the redo log for the write request has been replayed on the corresponding host 118, 122, 126 performing the replica role.

[0038] In some examples, the database management system 102 can implement an active-active arrangement in which some read requests from clients 104, 106, 108 are directed to hosts 118, 122, 126 configured to perform a replica role. Thus, in addition to replaying redo logs received from hosts 116, 120, 124 performing a source role, hosts 118, 122, 126 performing a replica role can also respond to read requests from clients 104, 106, 108, for example, as distributed by the network layer 112 or other suitable components of the database management system 102.

[0039] exist Figure 1 In an example of , the network layer 112 is configured to implement an allow list 114. The allow list 114 can describe requests that are permitted to be issued by or directed to a host that performs a replica role when the host is running a different version from its corresponding source role host. For example, the allow list 114 can indicate that replication requests associated with replication are permitted. A replication request can be a request associated with maintaining a host that performs a replica role in a state consistent with a corresponding host that performs a corresponding source role. Examples include requesting that a host that performs a replication replica role replay a redo log generated by a corresponding host that performs a source role. Allowed requests can also include requests that do not imply differences between corresponding host versions.

[0040] The allow list may indicate that other kinds of requests are not permitted. In some examples, requests of types not described in the allow list are not permitted. Examples of requests that are not permitted to a host performing a replica role include read requests from clients associated with an active-active arrangement, and requests run by a host implementing a replica role, and depend on the version of the host and / or database management system.

[0041] In some examples, the database management system 102 may support monitoring views, such as the M DISKS views available for the HANA system of SAP SE of Walldorf, Germany. The structure of the monitoring views may change with different versions of the database management system 102. In this case, if the source role host and the replica role host are different versions, the source role host may receive data with an unknown structure from the replica role host. When the host executing the replica role is of a different version than the host executing the source role, such interaction may not be permitted.

[0042] Figure 2 is a flow chart showing one example of a process flow 200 that can be executed in environment 100 to upgrade a pair of hosts to a target version. Process flow 200 is described herein for a first host and a second host. The first host initially runs a source role, similar to Figure 1Hosts 116, 120, 124. Similar to Figure 1 Of the hosts 118, 122, 126, the second host initially runs a replica role corresponding to the source role.

[0043] At operation 202, database management system 102 may receive an upgrade instruction. The upgrade instruction may include a description of the upgrade to be performed. In some examples, the upgrade instruction may also indicate one or more hosts to be upgraded. For example, the upgrade instruction may include a description of a source role and instructions for hosts to perform the upgrade of the source role and corresponding replica roles. The upgrade instruction may also indicate a target version to which the upgrade is targeted.

[0044] The upgrade may include modifying at least one of the hosts 116, 118, 120, 122, 124, 126 from a current version to a target version. In some examples, the target version may reflect a new version of software implementing the host and / or a new version of the database management system 102. Process flow 200 describes upgrading a pair of hosts implementing a source role and a corresponding replica role. However, it should be understood that similar operations may be performed to upgrade more than one set of hosts, such as at all hosts 116, 118, 120, 122, 124, 126 or at a subset of hosts 116, 118, 120, 122, 124, 126.

[0045] At operation 204, the database management system 102 may shut down the second host. As described herein, the second host initially runs a replica role associated with the corresponding source role. At operation 206, the database management system 102 may upgrade the second host to the target version. This may include, for example, modifying the container image of the second host to include and / or reference code that implements the target version. Upgrading the second host may also include, for example, restarting the second host by restarting the second host from the upgraded container image. After restarting, the second host may begin to synchronize with the first host running the corresponding source role. For example, the second host may load a data snapshot from its data volume into a random access memory and / or replay a redo log from its log volume. In this way, the restarted second host can make itself consistent with the first host executing the corresponding source role.

[0046] At operation 208, the database management system 102 can determine whether the second host is synchronized with the first host. When the second host has successfully loaded the snapshot data and / or played back the relevant redo logs, synchronization can occur so that the second host is consistent with the first host. If the second host is not yet consistent with the first host, the database management system 102 can wait and then determine again whether the second host has become consistent with the first host. When the second host is consistent with the first host, the database management system 102 can proceed to operation 210.

[0047] At operation 210, the database management system 102 can execute a takeover, wherein the second host, now operating the target version, begins to perform the source role originally performed by the first host. For example, requests previously directed to the first host can now be directed to the second host. At operation 212, the database management system 102 can shut down the first host. At operation 214, the database management system 102 can upgrade the first host to the target version, for example, in the manner described herein with respect to operation 206.

[0048] At operation 216, database management system 102 can restart the first host. In some examples, the first host is restarted and configured to perform the replica role previously performed by the second host. Therefore, the first host can begin synchronizing with the second host that is now running the source role.

[0049] Figure 3 is a flow chart showing another example of a process flow 300 that can be executed in the environment 100 to upgrade a pair of hosts to a target version. The process flow 300 is described here for a first host and a second host. The first host initially runs a source role, similar to Figure 1 Hosts 116, 120, 124. Similar to Figure 1 Of the hosts 118, 122, 126, the second host initially runs a replica role corresponding to the source role.

[0050] At operation 302, database management system 102 may receive an upgrade instruction. The upgrade instruction may include a description of the upgrade to be performed. In some examples, the upgrade instruction may also indicate one or more hosts to be upgraded. For example, the upgrade instruction may include a description of a source role and instructions for hosts to perform the upgrade of the source role and corresponding replica roles. The upgrade instruction may also indicate a target version to which the upgrade is targeted.

[0051] In operation 304, the database management system 102 can start the third host according to the target version. For example, the database management system 102 can start the third host from a container image configured according to the target version. In operation 306, the database management system 102 can configure the third host to perform the source role being performed by the first host. The third host can begin to synchronize with the first host, for example, by loading a data snapshot reflecting the state of the first host and replaying any replay logs. In operation 308, the database management system 102 can determine whether the third host is synchronized with the first host. If the third host has not yet synchronized with the first host, the database management system 102 can continue to monitor the third host.

[0052] When the third host is synchronized with the first host, database management system 102 can shut down the first host in operation 310. When the first host is shut down, the second host can continue to perform the replica role corresponding to the source role, now performed by the third host. In this way, replication can be maintained.

[0053] For example, as described herein, at operation 312, the database management system 102 can upgrade the first host to the target version. At operation 314, the database management system 102 can restart the first host, which is now running the target version. At operation 316, the database management system 102 can configure the roles of the first host and the third host, both of which are now running the target version. In some examples, the database management system 102 configures the first host to perform a replica role associated with a source role. In other examples, the database management system 102 configures the first host to perform the source role and reconfigures the third host to perform the corresponding replica role.

[0054] Database management system 102 may shut down the second host at operation 318. In some examples, the second host may not be shut down until the first host is synchronized with the third host and configured to perform the source role or the corresponding replica role.

[0055] Figure 4 is a flowchart illustrating another example of a process flow 400 that can be executed in environment 100 to upgrade a pair of hosts to a target version. The process flow 400 is described herein for a first host and a second host. The first host initially runs a source role, similar to Figure 1 Hosts 116, 120, 124. Similar to Figure 1 Of the hosts 118, 122, 126, the second host initially runs a replica role corresponding to the source role.

[0056] At operation 402, database management system 102 may receive an upgrade instruction. The upgrade instruction may include a description of the upgrade to be performed. In some examples, the upgrade instruction may also indicate one or more hosts to be upgraded. For example, the upgrade instruction may include a description of a source role and instructions for hosts to perform the upgrade of the source role and corresponding replica roles. The upgrade instruction may also indicate a target version to which the upgrade is targeted.

[0057] In operation 404, the database management system 102 can start the third host according to the target version. For example, the database management system 102 can start the third host from a container image configured according to the target version. In operation 406, the database management system 102 can configure the third host to perform the replica role being performed by the second host. The third host can begin to synchronize with the first host, for example, by loading a data snapshot reflecting the state of the first host and replaying any replay logs. In operation 408, the database management system 102 can determine whether the third host is synchronized with the first host. If the third host has not yet synchronized with the first host, the database management system 102 can continue to monitor the third host.

[0058] When the third host is synchronized with the first host, database management system 102 can shut down the second host in operation 410. When the second host is shut down, the third host can perform a replica role corresponding to the source role performed by the first host. In this way, replication can be maintained.

[0059] For example, as described herein, at operation 412, the database management system 102 can upgrade the second host to the target version. At operation 414, the database management system 102 can restart the second host, which is now running the target version. At operation 416, the database management system 102 can configure the roles of the second host and the third host, both of which are now running the target version. For example, after the restart and after the second host is synchronized with the first host, the database management system 102 can configure the second host or the third host to perform the source role, while the other of the second or third hosts continues to perform the replica role. At operation 418, the database management system 102 can shut down the first host.

[0060] Process flows 200, 300, and 400 include periods when a host executing a source role and a host executing a corresponding replica role are different versions. In various examples, network layer 112 can be configured to apply allow list 114 to communications to and between hosts 116, 118, 120, 122, 124, 126. Network layer 112 can apply allow list 114 to communications to and / or from hosts executing different versions of corresponding source and replica roles.

[0061] Figure 51 is a flow chart illustrating an example of a process flow 500 that can be executed by the network layer 112 in the environment 100, which can handle communications related to hosts running different versions. At operation 502, the network layer 112 can receive a request directed to a host running a replica role. The request can be directed to a host running a different version than the host executing the corresponding source role. At operation 504, the network layer 112 can determine whether it is allowed to direct the request to the replica role host. If it is allowed to direct the request to the replica role host, the network layer 112 can direct the request to the replica role host at operation 508. If it is not allowed to direct the request to the replica role host, the network layer 112 can direct the request to the source role host at operation 506.

[0062] Another challenge in a cloud-implemented multi-host database management system arises when it is necessary to change the operating parameters of the host. Management of the database management system 102 may involve changing host operating parameters, such as storage capacity, the level of central processing unit (CPU) resources allocated to the host, the level of memory resources allocated to the host, etc. However, making such changes to operating parameters typically involves restarting the host. For example, depending on the container architecture, changing the operating parameters of the host may involve shutting down the currently running host and restarting the host in a different container with different resources allocated.

[0063] However, when a host is shut down, it may cause downtime for the database management system and / or interrupt replication. For example, if a host performing a source role fails, and a host performing a corresponding replica role is shut down due to a change in operating parameters, recovery may involve starting a new host and fully synchronizing the new host with the data snapshot and redo logs of the failed host. This may undesirably increase the RTO of the database management system 102.

[0064] Various examples address these and other issues by continuously changing the configuration parameters of hosts. Consider an example where a first host is running a source role and a second host is running a replica role of the source role. The second host can be shut down and modified according to a new set of operating parameters. The second host can then be restarted. After restarting, the second host can be configured to perform the source role. The first host can be shut down and modified according to a new set of operating parameters. The first host can then be restarted and configured to perform a replica role of the source role. Alternatively, the first host can be configured to perform the source role and the second host can be reconfigured to perform either the replica role or the source role.

[0065] In another example, a third host can be started according to a new set of configuration parameters. The third host can be configured to perform the source role or the corresponding replica role. Then, the first or second host can be shut down and restarted using the updated configuration parameters. The restarted host can be configured to perform the source role or the corresponding replica role. When the restarted host is synchronized, the remaining hosts can be shut down.

[0066] Figure 6 is a flow chart illustrating one example of a process flow 600 that may be executed in environment 100 to change an operating parameter of a host. Process flow 600 is described herein for a first host and a second host. The first host initially runs a source role, similar to Figure 1 The second host initially runs the replica role corresponding to the source role, similar to Figure 1 Hosts 118, 122, 126 in.

[0067] At operation 602, the database management system 102 receives an operating parameter change instruction. The operating parameter change instruction may indicate a change to an operating parameter of one or more hosts. For example, the operating parameter change instruction may indicate a target operating parameter set.

[0068] At operation 604, the database management system 102 may start the third host according to the target set of operating parameters. For example, the database management system 102 may start the third host in a container configured according to the target set of operating parameters. At operation 606, the database management system 102 may configure the third host to perform the source role that the first host is performing. The third host may begin synchronizing with the first host, for example, by loading a data snapshot reflecting the state of the first host and replaying any replay logs. At operation 608, the database management system 102 may determine whether the third host is synchronized with the first host. If the third host has not yet synchronized with the first host, the database management system 102 may continue to monitor the third host.

[0069] When the third host is synchronized with the first host, the database management system 102 can shut down the first host at operation 610. When the first host is shut down, the second host can continue to perform the replica role corresponding to the source role now performed by the third host. In this way, replication can be maintained.

[0070] At operation 612, the database management system 102 may modify the first host to the target set of operating parameters. For example, the database management system 102 may modify the parameters of the container image describing the container in which the first host will run. At operation 614, the database management system 102 may restart the first host, which may now run according to the target set of operating parameters. At operation 616, the database management system 102 may configure the roles of the first host and the third host, which may now both run according to the target set of operating parameters. In some examples, the database management system 102 is configured as the first host to perform a replica role associated with a source role. In other examples, the database management system 102 configures the first host to perform the source role and reconfigures the third host to perform the corresponding replica role.

[0071] At operation 618, database management system 102 can shut down the second host. In some examples, the second host can not be shut down until the first host is synchronized with the third host and configured to perform the source role or the corresponding replica role.

[0072] Figure 7 is a flow chart illustrating another example of a process flow 700 that can be executed in environment 100 to change an operating parameter of a host. Process flow 700 is described herein for a first host and a second host. The first host initially runs a source role, similar to Figure 1 The second host initially runs the replica role corresponding to the source role, similar to Figure 1 Hosts 118, 122, 126 in.

[0073] At operation 702, database management system 102 may receive an operating parameter change instruction. The operating parameter change instruction may indicate a change to an operating parameter of one or more hosts. For example, the operating parameter change instruction may indicate a target operating parameter set.

[0074] At operation 704, the database management system 102 may start the third host according to the target set of operating parameters. For example, the database management system 102 may start the third host in a container configured according to the target set of operating parameters. At operation 706, the database management system 102 may configure the third host to perform the replica role that the second host is performing. The third host may begin synchronizing with the first host, for example, by loading a data snapshot that reflects the state of the first host and replaying any replay logs. At operation 708, the database management system 102 may determine whether the third host is synchronized with the first host. If the third host has not yet synchronized with the first host, the database management system 102 may continue to monitor the third host.

[0075] When the third host is synchronized with the first host, the database management system 102 can shut down the second host at operation 710. During the shutdown of the second host, the third host can perform a replica role corresponding to the source role performed by the first host. In this way, replication can be maintained.

[0076] At operation 712, database management system 102 can modify the second host to the target set of operating parameters. For example, database management system 102 can modify the parameters of the container image describing the container in which the second host will run. At operation 614, database management system 102 can restart the second host, which can now run according to the target set of operating parameters.

[0077] At operation 714, the database management system 102 can restart the second host, which is now running the target version. At operation 716, the database management system 102 can configure the roles of the second host and the third host, both of which are now operating according to the target set of operating parameters. For example, after the restart and after the second host is synchronized with the first host, the database management system 102 can configure the second host or the third host to perform the source role, while the other of the second or third hosts continues to perform the replica role. At operation 718, the database management system 102 can shut down the first host.

[0078] In some examples, a database management system, such as database management system 102, can utilize host replication, as described herein, to mitigate the failure of a single host. While this arrangement may be effective for mitigating the failure of a single host or multiple hosts, it may be less effective for a wider range of failures. For example, some or all of database management system 102 may be implemented by computer hardware at a single data center managed by a supercomputer or other cloud provider. If a data center fails, all hosts implemented in that data center may be down.

[0079] Various examples address these and other issues by running a secondary database management system at a remote data center. For example, a primary database management system similar to database management system 102 may be implemented at a data center in one geographic location. The secondary database management system may be implemented at a second geographic location that is different from the first geographic location. Thus, if a first data center running all or part of the primary database management system experiences a failure, clients may continue to use the database management system by accessing the secondary database management system.

[0080] However, in various examples, it may not be practical to perform synchronous replication on a secondary database management system that is remote from the primary database management system. For example, the primary database management system may send redo logs to the secondary database management system, where the redo logs indicate write requests that have been executed. However, according to the synchronous replication arrangement, the primary database management system will wait to commit the request until an indication is received that the secondary database management system has replayed the redo logs. However, when the primary database management system and the secondary database management system are implemented in different geographical locations, the communication delays associated with waiting for the secondary database management system to confirm that it has replayed the redo logs may produce an unacceptable lag in the performance of the primary database management system.

[0081] In various examples, these and other challenges are addressed by implementing asynchronous replication at the secondary database management system. For example, when the primary database management system receives a write request, it may provide the secondary database management system with redo logs reflecting the write request, but may not wait for the secondary database management system to confirm the playback of the redo logs before committing the write request. In an asynchronous replication arrangement, there is no guarantee that the redo logs sent by the primary database management system will be received by the secondary database management system in the same order in which they were sent.

[0082] The asynchronous configuration between the primary and secondary database management systems can provide robustness in the event of a large-scale failure of the primary database management system. In the event of a failure of the primary database management system, the secondary database management system can assume the role of the primary database management system. For example, client requests can be directed to the secondary database management system instead of the primary database management system.

[0083] Because replication at the secondary database management system is asynchronous, some examples of secondary database management systems may not implement master replication. Therefore, at the time of takeover, the secondary database management system can operate without a replication master. Therefore, if the secondary database management system experiences a master failure, the RTO (and sometimes RPO) may be unacceptable to some enterprises. Therefore, the secondary database management system can be configured to start a master to run the replica role or each of its source roles at the time of takeover. In these arrangements, there may be a time delay between initiating the takeover and starting, synchronizing, and configuring the corresponding new master to perform the replica role. Therefore, the secondary database management system can operate without master replication until the replica role master is ready, or the RTO of the initial takeover can be extended while the replica role master is ready.

[0084] Various examples address these and other challenges by running a replica role master at a secondary database management system that is an asynchronous replica of a primary database management system. The secondary database management system can run a coordinator component. The coordinator component can coordinate the playback of redo logs across the various source role and replica role masters of the secondary database management system. At takeover, the coordinator component can select the source role whose master has the earliest last valid commit. The coordinator component can restore the secondary database management system to the time of the earliest last valid commit before the takeover. In this way, the secondary database system can implement multiple masters that perform replica roles while also running the takeover in a state consistent with the primary database management system.

[0085] Figure 8 804. Figure 1 The primary database management system 802 includes hosts 808, 810, and 812. As described herein, the hosts 808, 810, 812 are configured to perform source roles. Figure 8 Although not specifically shown, the master database management system 802 may also include one or more other hosts configured to perform a replica role relative to the source role. Figure 8 Three hosts 808, 810, and 812 are shown, but it should be understood that the primary database management system 802 may include more or fewer hosts than shown.

[0086] The auxiliary database management system 804 includes hosts 816, 818, 820, and 822. In this example, hosts 816 and 820 are configured to perform respective source roles. Hosts 818 and 822 are configured to perform replica roles corresponding to respective source roles. For example, host 818 is configured to perform a replica role corresponding to the source role being performed by host 816. Similarly, host 822 is configured to perform a replica role corresponding to the source role being performed by host 820. In addition, although Figure 8 8 shows hosts performing two source roles, but it should be understood that the auxiliary database management system 804a includes more or fewer hosts than shown, and these hosts can perform more or fewer source roles than shown.

[0087] The primary database management system 802 can generate redo logs 824. Each redo log 824 corresponds to a write request executed at one of the hosts 808, 810, 812. In some examples, the redo logs 824 are used in the primary database management system 802 to perform synchronous replication of the corresponding hosts 808, 810, 812. The redo logs 824 can also be sent to the secondary database management system 804 asynchronously over the network 801. For example, the corresponding host 808, 810, 812 of the primary database management system can generate and send the redo logs 824, but may not wait for confirmation from the secondary database management system 804 before submitting the corresponding write request. The network 801 can be or include any suitable type of network or combination of networks, including one or more local area networks (LANs), one or more wide area networks (WANs), etc.

[0088] Figure 8 The redo logs 824 are shown arranged in chronological order and are labeled RL1, RL2, ... RLN. However, because the redo logs 824 are transmitted asynchronously, there is no guarantee that they will arrive at the secondary database management system 804 in the same order as they were sent by the primary database management system 802. Therefore, if the respective hosts 816, 820 implementing the source role replay the redo logs 824 in the order in which they were received at the secondary database management system 804, this may result in data corruption at the respective hosts 816, 820.

[0089] The secondary database management system 804 can include a coordinator component 814 configured to direct redo logs 824 to the respective hosts 816, 818, 820, 822. In various examples, the coordinator component 814 can run in a container in a manner similar to the respective hosts 816, 818, 820, 822. The coordinator component 814 can cache the redo logs 824 received from the primary database management system 802 and provide the redo logs 824 to the respective hosts 816, 818, 820, 822 in the time order in which the redo logs 824 were sent from the primary database management system 802. In some examples, the coordinator component 814 is also configured to configure the secondary database management system 804 to take over the source role and location of the primary database management system 802.

[0090] Fig. 9 is a flow chart showing one example of a process flow 900 that may be executed in a secondary database management system 804. The process flow 900 includes two columns 901, 903. Column 901 includes operations performed by the coordinator component 814. Column 903 includes operations performed by example hosts 816, 820 performing a source role in the secondary database management system 804.

[0091] At operation 902, the coordinator component 814 may receive a redo log 905 from a primary database management system 802. As described herein, the redo log 905 may describe write operations executed at a host 808, 810, 812 of the primary database management system 802. The redo log 905 may include a description of the host 808, 810, 812 and a description of the write request, including, for example, data used to implement the write request.

[0092] At operation 904, the coordinator component 814 can determine the source host role to receive the redo log at the secondary database management system 804. For example, the redo log can be directed to the source role corresponding to the source host 808, 810, 812 running the corresponding write request at the primary database management system 802.

[0093] At operation 906, the coordinator component 814 can determine whether the redo log 905 is the next redo log associated with the determined source role. For example, if the redo logs are received out of order from the primary database management system 802, there may be one or more unreceived redo logs that are directed to the same source role before the redo log 905. If the host executing the source role replays the redo log 905 before replaying the intervening redo log, the data at the host may be corrupted. The coordinator component 814 can determine whether the redo log 905 is the next redo log in any suitable manner. For example, the redo logs received from the primary database management system 802 can be numbered or otherwise marked with an indication of the order of the redo logs.

[0094] If the redo log 905 is not the next redo log for the determined source role, then at operation 908, the coordinator component 814 can cache the redo log 905. After caching the redo log 905 at operation 908, at operation 912, the coordinator component 814 can wait to receive the next redo log from the primary database management system 802. When the next redo log is received, the coordinator component can return to operation 904.

[0095] If, at operation 906, the coordinator component 814 determines that redo log 905 is the next redo log for the determined source role, then at operation 910, the coordinator component 814 can send redo log data 907 to the first host executing the determined source role. Redo log data 907 can include redo log 905. Redo log data 907 can optionally include any other redo logs that have been cached for the determined source role. For example, redo log data 907 can include a single redo log (e.g., redo log 905) or can include multiple redo logs (e.g., including redo log 905). In examples where redo log data 907 includes more than one redo log, redo log data 907 can also include an indication of the order of the redo logs.

[0096] Upon receiving redo log data 907, at operation 914, the first host may replay a first redo log from redo log data 907. The first host may be configured to replay the redo logs in sequence. For example, if the redo log data includes more than one redo log, the first host may select the earliest or first redo log in time and replay that redo log first.

[0097] At operation 916, the first host may send the redo log to a second host that is performing a replica role associated with the source role that the first host is performing. Upon receiving the redo log, the second host may replay the redo log. When the first host receives confirmation that the second host has replayed the redo log, at operation 918, the first host may commit the transaction that implements the replay. This may maintain the second host as an asynchronous replica of the first host.

[0098] At operation 920, the first host determines whether any additional redo logs are included in the redo log data 907. If the redo log data 907 does not include additional redo logs, then at operation 922, the first host can wait to receive redo log data from the coordinator component 814. If the redo log data 907 includes one or more additional redo logs, then at operation 924, the first host can access the next redo log from the redo log data 907 and return to operation 914 to replay the next redo log.

[0099] Fig.10 1 is a flow chart illustrating an example of a process flow 1000 that can be executed by the coordinator component 814 to respond to a takeover request. It should be understood that in an arrangement where an asynchronously replicated secondary database management system includes multiple synchronously replicated hosts, not all hosts and their replicas will reflect the state of the primary database management system at the same time. Therefore, the coordinator component 814 can select the source role host with the earliest last valid commit and restore all hosts at the secondary database management system 804 to the time of the earliest last valid commit. Determining the earliest last valid commit can include comparing the last valid commits of different source roles.

[0100] At operation 1002, the coordinator component 814 can receive a takeover request. The takeover request can include data indicating that the secondary database management system 804 will assume the role of the primary database management system 802. At operation 1004, the coordinator component 814 can identify the earliest last valid commit at the host 816, 820 that performs the source role. Each host that performs the source role, such as host 816, 822, can have a last valid commit. The last valid commit is the most recent write request that was completed and committed on the host that performs the source role. As described herein, for example, with reference to Fig. 9, when the host executing the source role has replayed the relevant one or more replay logs and the host executing the corresponding replica role has also replayed the relevant one or more replay logs, a valid commit at the host executing the source role can occur. The earliest last valid commit at the auxiliary database management system 804 can be the last valid commit at the host executing the source role, corresponding to the earliest time at the primary database management system 802.

[0101] In operation 1006, the coordinator component 814 can restore the hosts 816, 818, 820, 822 to the time of the earliest last valid commit identified in operation 1004. The host executing the source role associated with the earliest last valid commit and the host executing the corresponding replica role may have been synchronized with the primary database management system 802 at the time of the last valid commit. Other hosts can be restored by replaying one or more replay logs in reverse. For example, the coordinator component 814 can instruct the host executing the source role to replay one or more redo logs in reverse until the earliest last valid commit time is reached. The host executing the source role can replay the redo log in reverse and commit the replay after receiving confirmation that the host executing the corresponding replica role is also replaying the redo log in reverse.

[0102] At operation 1008, the coordinator component 814 can configure the secondary database management system 804 to perform the role of the primary database management system 802. For example, the secondary database management system 804 can be configured to receive requests from the client 806, including, for example, read requests and write requests.

[0103] Example:

[0104] Example 1 is a database management system, comprising: at least one processor programmed to perform operations, including: a first host running at a first container in a cloud environment, the first host being a first version, and the first host being configured to execute a source role; a second host running at a second container in the cloud environment, the second host having a second version different from the first version, and the second host being configured to execute a replica role of the source role; receiving, by a network layer running in the cloud environment, a first request directed to the second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; and sending, by the network layer, the first request to the second host at the second container.

[0105] In Example 2, the subject matter of Example 1 optionally includes operations further including the following steps: receiving, by the network layer, a second request directed to a second host; determining, by the network layer, that the second request is inconsistent with allowed request data; and sending, by the network layer, the second request to the first host.

[0106] In Example 3, the subject matter of Example 2 optionally includes the second request being a read request and the first request being a copy request.

[0107] In Example 4, the subject matter of any one or more of Examples 1-3 optionally includes operations further including the following steps: receiving, by the network layer, a third request directed from the second host to the first host; determining, by the network layer, that the third request is inconsistent with allowed request data; and blocking, by the network layer, the third request.

[0108] In Example 5, the subject matter of any one or more of Examples 1-4 may optionally include operations, which further include, before receiving the first request: receiving an upgrade instruction indicating a version upgrade for the first host and the second host; shutting down the second host; upgrading the second host to the second version; and restarting the second host at the second container.

[0109] In Example 6, the subject matter of Example 5 optionally includes operations further comprising the steps of: receiving an indication that a second host is synchronized with the first host running at the first container; and configuring the second host to run the source role.

[0110] In Example 7, the subject matter of Example 6 optionally includes operations further including the following steps: shutting down the first host at the first container; upgrading the first host to the second version; and restarting the first host at a new container in the cloud environment, wherein the restarted first host at the new container is configured to perform a replica role of the source role.

[0111] In Example 8, the subject matter of any one or more of Examples 1-7 may optionally include operations further comprising: receiving an indication that a first host running at the first container has crashed; and configuring a second host to run the source role.

[0112] Example 9 is a method for operating a database management system, the method comprising: a first host running at a first container in a cloud environment, the first host having a first version, and the first host being configured to execute a source role; a second host running at a second container in the cloud environment, the second host having a second version different from the first version, and the second host being configured to execute a replica role of the source role; receiving, by a network layer running in the cloud environment, a first request directed to the second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; and sending, by the network layer, the first request to the second host at the second container.

[0113] In Example 10, the subject matter of Example 9 can optionally include receiving, by the network layer, a second request directed to the second host; determining, by the network layer, that the second request is inconsistent with allowed request data; and sending, by the network layer, the second request to the first host.

[0114] In Example 11, the subject matter of Example 10 optionally includes the second request being a read request and the first request being a copy request.

[0115] In Example 12, the subject matter of any one or more of Examples 9-11 may optionally include receiving, by the network layer, a third request directed from the second host to the first host; determining, by the network layer, that the third request is inconsistent with allowed request data; and blocking, by the network layer, the third request.

[0116] In Example 13, the subject matter of any one or more of Examples 9-12 may optionally include, before receiving the first request: receiving an upgrade instruction indicating a version upgrade for the first host and the second host; shutting down the second host; upgrading the second host to the second version; and restarting the second host at the second container.

[0117] In Example 14, the subject matter of Example 13 may optionally include receiving an indication of a second host to synchronize with the first host running at the first container; and configuring the second host to run the source role.

[0118] In Example 15, the subject matter of Example 14 optionally includes shutting down the first host at the first container; upgrading the first host to the second version; and restarting the first host at a new container in the cloud environment, wherein the restarted first host at the new container is configured to perform a replica role of the source role.

[0119] In Example 16, the subject matter of any one or more of Examples 9-15 may optionally include receiving an indication that a first host running at the first container has crashed; and configuring a second host to run the source role.

[0120] Example 17 is a non-transitory machine-readable medium comprising instructions that, when executed by at least one processor, cause the at least one processor to perform operations, including: a first host running at a first container in a cloud environment, the first host having a first version, and the first host being configured to execute a source role; a second host running at a second container in the cloud environment, the second host having a second version different from the first version, and the second host being configured to execute a replica role of the source role; receiving, by a network layer running at the cloud environment, a first request for the second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; and sending, by the network layer, the first request to the second host at the second container.

[0121] In Example 18, the subject matter of Example 17 optionally includes the following steps: receiving, by the network layer, a second request for the second host; determining, by the network layer, that the second request is inconsistent with allowed request data; and sending, by the network layer, the second request to the first host.

[0122] In Example 19, the subject matter of Example 18 may optionally include the second request being a read request and the first request being a copy request.

[0123] In Example 20, the subject matter of any one or more of Examples 17-19 optionally includes the following steps: receiving, by the network layer, a third request sent from the second host to the first host; determining, by the network layer, that the third request is inconsistent with allowed request data; and blocking, by the network layer, the third request.

[0124] Fig.11 1 is an example diagram of an in-memory database management system 1100. As described herein, an in-memory database stores data primarily in a main memory such as a random access memory. This is different from a database that primarily employs a disk storage mechanism. In some examples, database management system 1100 may be or include an example of a HANA system from SAP SE of Walldorf, Germany. Although various features of environmental metric integration are described herein in the context of an in-memory database, carbon footprint optimization may generally be performed in any suitable database management system.

[0125] The in-memory database management system 1100 may be coupled to one or more clients 1102A, 1102B. The clients 1102A, 1102B may be similar to the clients 104, 106, 108, 806 described herein. The clients 1102A, 1102B may communicate with the in-memory database management system 1100 via a variety of different protocols, including structured query language (SQL), multidimensional expressions (MDX), hypertext transfer protocol (HTTP), representational state transfer (REST), and hypertext markup language (HTML).

[0126] Fig.11 Also shown is a platform 1104 that can be used to perform modeling by accessing the in-memory database management system 1100. In some examples, the platform 1104 can allow for complex analysis to be performed on data extracted not only from real-time event data and windows, but also from stored database information. As described herein, in some examples, carbon footprint data can be generated by the platform.

[0127] The in-memory database management system 1100 can include a number of different components, including an index server 1106, an XS engine 1108, a statistics server 1110, a preprocessor server 1112, and a name server 1114. These components can run on a single computing device, or can be distributed across multiple computing devices (e.g., separate servers). The index server 1106 contains the actual data and the engine for processing the data. It can also coordinate and use other servers. In some examples, the various hosts described herein can perform source roles for implementing different instances of index servers similar to the index server 1106.

[0128] The XS engine 1108 allows clients to connect to the in-memory database management system 1100 using a web protocol such as HTTP. Although the XS engine 1108 is illustrated as a component of the in-memory database management system 1100, in some examples, the XS engine may be implemented as one or more APIs and / or services located between the clients 1102A, 1102B and the in-memory database management system 1100. In some examples, the XS engine 1108 may process client requests received in languages ​​other than SQL, such as MDX, HTTP, REST, HTML, etc.

[0129] Statistics server 1110 collects information about status, performance and resource consumption from all other server components. Statistics server 1110 can be accessed from platform 1104 to obtain the status of various alarm monitors.

[0130] The pre-processor server 1112 is used to analyze text data and extract information upon which the text search capability is based.

[0131] The name server 1114 maintains information about the database topology. This is used for distributed systems where database instances are located on different hosts. The name server 1114 knows where components are running and which data is located on which server. In an example embodiment, a separate enqueue server can operate in the manner described above with respect to the enqueue server, particularly with respect to creating and managing lightweight enqueue sessions.

[0132] Fig.12 1106. Specifically, the following describes in more detail Fig.11The index server 1106 of FIG. 1106 includes a connection and session management component 1200 that is responsible for creating and managing sessions and connections for database clients (e.g., clients 1102A, 1102B). Once a session is established, the client can communicate with the database management system using SQL statements. For each session, a set of session parameters 1202 can be maintained, such as auto-commit, current transaction isolation level, etc. Users (e.g., system administrators, developers) can be authenticated by the database management system itself (e.g., by logging in with login information such as a username and password using an authentication component 1204), or authentication can be delegated to an external authentication provider such as a Lightweight Directory Access Protocol (LDAP) directory.

[0133] The client request can be analyzed and executed by a set of components summarized as request processing and execution control 1206. SQL processor 1208 checks the syntax and semantics of the client SQL statement and generates a logical execution plan. MDX is a language for querying and manipulating multidimensional data stored in OLAP multidimensional cubes. Thus, an MDX engine 1210 can be provided to allow parsing and execution of MDX commands. Planning engine 1212 allows applications to run basic planning operations in the database layer. One of the operations is to create a new version of a data set as a copy of an existing data set while applying filters and transformations.

[0134] The calculation engine 1214 implements a variety of SQL script and plan operations. The calculation engine 1214 creates a logical operation plan for the calculation model derived from the SQL script, MDX, plan, and domain-specific model. The logical operation plan may include, for example, decomposing the model into operations that can be processed in parallel. Data is stored in the relational memory 1216, which implements a relational database in the main memory. Each SQL statement can be processed in the context of a transaction. New sessions are implicitly assigned to new transactions. The transaction manager 1218 coordinates database transactions, controls transaction isolation, and tracks running and closed transactions. When a transaction is committed or rolled back, the transaction manager 1218 notifies the engines involved of the event so that they can run the required actions. The transaction manager 1218 also cooperates with the persistence layer 1220 to implement atomic and durable transactions.

[0135] The authorization manager 1222 is called by other database management system components to check whether the user has the specified permissions to perform the requested operation. The database management system allows permissions to be granted to users or roles. Permissions grant the right to perform specified operations on specified objects.

[0136] The persistence layer 1220 ensures that the database is restored to the most recently committed state after a restart, and that transactions are fully run or fully undone. To achieve this goal effectively, the persistence layer 1220 uses a combination of redo logs, shadow pages, and snapshot data obtained at one or more save points. The persistence layer 1220 also provides a page management interface 1224 for writing and reading data to separate disk storage 1226, and also includes a logger 1228 for managing transaction logs. When data is written via the persistence layer interface, the persistence layer 1220 can write log entries implicitly, or explicitly write log entries by using the log interface.

[0137] Fig.13 FIG. 1206 is a diagram of an example of request processing and operation control 1206. The diagram describes in more detail Fig.12 Request processing and execution control 1206. SQL processor 1208 includes SQL parser 1300, which parses SQL statements and generates logical execution plan 1302, which is passed to SQL optimizer 1304. SQL optimizer 1304 optimizes logical execution plan 1302 and converts it into physical execution plan 1306, which is then passed to SQL executor 1308. Calculation engine 1214 implements various SQL script and plan operations, including calculation engine optimizer 1310 that optimizes operations, calculation engine executor 1312 that executes operations, internal calculation engine operators 1314, L operators 1316, and R operators 1318.

[0138] The L infrastructure 1320 includes multiple components for assisting in running L programs, including an L runtime (system mode) 1322 , an L compiler 1324 , and an L runtime (user mode) 1326 .

[0139] Fig.14 1 is a block diagram 1400 showing one example of a software architecture 1402 for a computing device. For example, as described herein, the architecture 1402 can be used in conjunction with a variety of hardware architectures. Fig.14 The hardware layer 1404 is shown as a non-limiting example of a software architecture, and many other architectures may be implemented to facilitate the functionality described herein. A representative hardware layer 1404 is shown, which may represent, for example, any of the computing devices described above. In some examples, the hardware layer 1404 may be based on Fig.15 It is implemented by the architecture of the computer system.

[0140] The representative hardware layer 1404 includes one or more processing units 1406 with associated executable instructions 1408. The executable instructions 1408 represent executable instructions of the software architecture 1402, including implementations of the methods, modules, subsystems, components, etc. described herein, and may also include a memory and / or storage module 1410 also having executable instructions 1408. The hardware layer 1404 may also include other hardware, as shown by other hardware 1412, which represents any other hardware of the hardware layer 1404, such as other hardware shown as part of the architecture 1402.

[0141] exist Fig.14 In the example architecture of , software architecture 1402 can be conceptualized as a stack of layers, each of which provides specific functionality. For example, software architecture 1402 may include layers such as operating system 1414, library 1416, middleware layer 1418, application 1420, and presentation layer 1444. In operation, application 1420 and / or other components within a layer may call API call 1424 through the software stack and access responses, return values, etc., which are shown as messages 1426 in response to API call 1424. The layers shown are representative in nature, and not all software architectures have all layers. For example, some mobile or dedicated operating systems may not provide middleware layer 1418, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.

[0142] The operating system 1414 can manage hardware resources and provide public services. The operating system 1414 can include, for example, a kernel 1428, a service 1430, and a driver 1432. The kernel 1428 can act as an abstraction layer between the hardware and other software layers. For example, the kernel 1428 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The service 1430 can provide other public services for other software layers. In some examples, the service 1430 includes an interrupt service. The interrupt service can detect the reception of an interrupt, and in response, when the interrupt is accessed, the architecture 1402 suspends its current processing and runs an interrupt service routine (ISR).

[0143] Driver 1432 may be responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, driver 1432 may include a display driver, a camera driver, a Bluetooth driver, drives, flash drives, serial communications drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, NFC drivers, audio drivers, power management drivers, etc.

[0144] Libraries 1416 may provide a common infrastructure that applications 1420 and / or other components and / or layers may utilize. Libraries 1416 generally provide functionality that allows other software modules to perform tasks in an easier manner than directly interfacing with underlying operating system 1414 functions (e.g., kernel 1428, services 1430, and / or drivers 1432). Libraries 1416 may include system 1434 libraries (e.g., C standard libraries), which may provide functionality such as memory allocation functions, string manipulation functions, mathematical functions, and the like. In addition, libraries 1416 may include API libraries 1436, such as media libraries (e.g., libraries that support rendering and manipulation of multiple media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.), graphics libraries (e.g., OpenGL frameworks that may be used to render 2D and 3D in graphical content on a display), database libraries (e.g., SQLite that may provide multiple relational database functions), network libraries (e.g., WebKit that may provide web browsing functionality), and the like. The library 1416 may also include a variety of other libraries 1438 to provide numerous other APIs to the applications 1420 and other software components / modules.

[0145] The middleware layer 1418 (also sometimes referred to as a framework) may provide a higher level common infrastructure that may be utilized by the applications 1420 and / or other software components / modules. For example, the middleware layer 1418 may provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. The middleware layer 1418 may provide various other APIs that may be used by the applications 1420 and / or other software components / modules, some of which may be specific to a particular operating system or platform.

[0146] Applications 1420 include built-in applications 1440 and / or third-party applications 1442. Examples of representative built-in applications 1440 may include, but are not limited to, contact applications, browser applications, book reader applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 1442 may include any of built-in applications 1440 as well as a wide variety of other applications. In a specific example, third-party applications 1442 (e.g., applications created by entities other than the vendor of a particular platform using Android TM or iOS TM Software Development Kit (SDK) can be used to develop applications that run on platforms such as iOS. TM 、Android TM , Mobile software on a mobile operating system of a mobile phone or other mobile computing device operating system. In this example, third-party applications 1442 can call API calls 1424 provided by a mobile operating system such as operating system 1414 to facilitate the functions described herein.

[0147] Applications 1420 may utilize built-in operating system functionality (e.g., kernel 1428, services 1430, and / or drivers 1432), libraries (e.g., system 1434, API library 1436, and other libraries 1438), and middleware layer 1418 to create a user interface to interact with a user of the system. Alternatively or additionally, in some systems, interaction with the user may occur through a presentation layer, such as presentation layer 1444. In these systems, the application / module "logic" may be separated from aspects of the application / module that interact with the user.

[0148] Some software architectures make use of virtual machines. Fig.14 In the example of , this is illustrated by virtual machine 1448. A virtual machine creates a software environment in which applications / modules can run as if they were running on a hardware computing device. The virtual machine is hosted by a host operating system (operating system 1414) and typically, although not always, has a virtual machine monitor 1446 that manages the operation of the virtual machine 1448 and the interface with the host operating system (i.e., operating system 1414). Software architecture runs within virtual machine 1448, such as operating system 1450, libraries 1452, framework / middleware 1454, applications 1456, and / or presentation layer 1458. These layers of the software architecture executed within virtual machine 1448 can be the same as the corresponding layers previously described, or they can be different.

[0149] Modules, components and logic

[0150] Certain embodiments are described herein as including logical or multiple components, modules, or mechanisms. A module may constitute a software module (e.g., code contained on (1) a non-transitory machine-readable medium or (2) a transmission signal) or a hardware-implemented module. A hardware-implemented module is a tangible unit that is capable of performing a specific operation and may be configured or arranged in a specific manner. In an example embodiment, one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors may be configured by software (e.g., an application or application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

[0151] In various embodiments, hardware-implemented modules can be implemented mechanically or electronically. For example, a hardware-implemented module may include dedicated circuits or logic that are permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module may also include programmable logic or circuits (e.g., contained in a general-purpose processor or another programmable processor) that are temporarily configured by software to perform certain operations. It should be understood that the decision to implement a hardware-implemented module mechanically, in a dedicated and permanently configured circuit, or in a temporarily configured circuit (e.g., configured by software) may be driven by cost and time considerations.

[0152] Thus, the term "hardware-implemented module" should be understood to include a tangible entity, i.e., an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily or provisionally configured (e.g., programmed) to operate in a certain manner and / or perform certain operations described herein. Considering embodiments in which hardware-implemented modules are temporarily configured (e.g., programmed), each hardware-implemented module need not be configured or instantiated at any one time. For example, where the hardware-implemented module includes a general-purpose processor configured using software, the general-purpose processor can be configured as correspondingly different hardware-implemented modules at different times. The software can configure the processor accordingly, for example, to constitute a particular hardware-implemented module at one time, and to constitute different hardware-implemented modules at different times.

[0153] Hardware-implemented modules can provide information to other hardware-implemented modules and receive information from other hardware-implemented modules. Therefore, the described hardware-implemented modules can be considered to be communicatively coupled. In the case where multiple such hardware-implemented modules exist at the same time, communication can be achieved through signal transmission (for example, by connecting appropriate circuits and buses of the hardware-implemented modules). In embodiments where multiple hardware-implemented modules are configured or instantiated at different times, communication between such hardware-implemented modules can be achieved, for example, by storing and retrieving information in a memory structure accessible to multiple hardware-implemented modules. For example, a hardware-implemented module can perform an operation and store the output of the operation in a memory device to which it is communicatively coupled. Then, another hardware-implemented module can access the memory device at a later time to retrieve and process the stored output. Hardware-implemented modules can also initiate communication with input or output devices and can operate on resources (for example, information sets).

[0154] The various operations of the example methods described herein may be performed at least in part by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules for performing one or more operations or functions. In some example embodiments, the modules mentioned herein may include processor-implemented modules.

[0155] Similarly, the methods described herein are implemented at least in part by a processor. For example, at least some of the operations of the method may be performed by one or more processors or modules implemented by the processor. The execution of certain operations may be distributed between one or more processors, not only residing in a single machine, but also deployed on multiple machines. In some example embodiments, one or more processors may be located in a single location (e.g., in a home environment, an office environment, or a server farm), while in other embodiments, the processor may be distributed in multiple locations.

[0156] One or more processors may also be used to support execution of the related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as an example of a machine including a processor), which may be accessed via a network (e.g., the Internet) and one or more appropriate interfaces (e.g., APIs).

[0157] Electronic devices and systems

[0158] Example embodiments may be implemented in digital electronic circuitry, computer hardware, firmware or software, or in combinations of them. Example embodiments may be implemented using a computer program product, for example, a computer program tangibly embodied in an information carrier, such as a machine-readable medium, for execution by a data processing apparatus (e.g., a programmable processor, a computer or computers), or for controlling the operation of a data processing device.

[0159] Computer programs can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, subroutine or other unit suitable for use in a computing environment. Computer programs can be deployed to run on a single computer, or deployed to execute on multiple computers at a single site, or distributed across multiple sites and interconnected by a communication network.

[0160] In example embodiments, operations may be performed by one or more programmable processors running a computer program to perform functions by operating on input data and generating output. Method operations may also be performed by special purpose logic circuits (e.g., FPGAs or ASICs), and the apparatus of example embodiments may be implemented as special purpose logic circuits.

[0161] The computing system may include a client and a server. The client and the server are usually far away from each other and usually interact through a communication network. The relationship between the client and the server is generated due to the computer program running on the corresponding computer and having a client-server relationship with each other. In the embodiment of the deployment of the programmable computing system, it should be understood that both hardware and software architectures are worthy of consideration. Specifically, it should be understood that it may be a design choice to select to implement certain functions in a combination of permanently configured hardware (e.g., ASIC), temporarily configured hardware (e.g., a combination of software and a programmable processor) or permanently and temporarily configured hardware. Hardware (e.g., machine) and software architectures that can be deployed in a variety of example embodiments are listed below.

[0162] Example machine architecture and machine-readable medium

[0163] Fig.15 It is a block diagram of a machine in the example form of a computer system 1500, in which instructions 1524 can be run to cause the machine to perform any one or more methods discussed herein. In an optional embodiment, the machine operates as a standalone device, or can be connected (e.g., networked) to other machines. In a networked deployment, the machine can run as a server or client machine in a server-client network environment, or as a peer machine in a peer (or distributed) network environment. The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network device, a network router, a switch or a bridge, or any machine capable of running instructions (sequential or other) specifying the actions to be taken by the machine. In addition, although only a single machine is shown, the term "machine" should also be understood to include any machine set that executes a set (or multiple sets) of instructions individually or jointly to run any one or more methods discussed herein.

[0164] The example computer system 1500 includes a processor 1502 (e.g., a CPU, a graphics processing unit (GPU), or both), a main memory 1504, and a static memory 1506, which communicate with each other via a bus 1508. The computer system 1500 may also include a video display unit 1510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1500 also includes an alphanumeric input device 1512 (e.g., a keyboard or a touch-sensitive display screen), a user interface (UI) navigation (or cursor control) device 1514 (e.g., a mouse), a disk drive unit 1516, a signal generating device 1518 (e.g., a speaker), and a network interface device 1520.

[0165] Machine readable medium

[0166] The disk drive unit 1516 includes a machine-readable medium 1522 on which is stored one or more sets of data structures and instructions 1524 (e.g., software) that embody or are utilized by any one or more of the methodologies or functions described herein. During execution of the instructions 1524 by the computer system 1500, the instructions 1524 may also reside, completely or at least partially, in the main memory 1504 and / or the processor 1502, which also constitute the machine-readable medium 1522.

[0167] Although the machine-readable medium 1522 is shown as a single medium in the example embodiment, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instructions 1524 or data structures. The term "machine-readable medium" should also be understood to include any tangible medium that can store, encode, or carry instructions 1524 executed by a machine and cause the machine to perform any one or more methods of the present disclosure, or any tangible medium that can store, encode, or carry data structures used by or associated with such instructions 1524. Therefore, the term "machine-readable medium" should include, but is not limited to, solid-state memory, optical and magnetic media. Specific examples of machine-readable media 1522 include non-volatile memory, including, by way of example, semiconductor storage devices such as erasable 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; and DVD-ROM disks.

[0168] Transmission medium

[0169] The instructions 1524 may also be sent or received over a communication network 1526 using a transmission medium. The instructions 1524 may be transmitted using a network interface device 1520 and any of a variety of well-known transmission protocols (e.g., HTTP). Examples of communication networks include LANs, WANs, the Internet, mobile phone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions 1524 to be executed by the machine, and includes digital or analog communication signals or other intangible media to facilitate communication of such software.

[0170] Although the embodiments have been described with reference to specific example embodiments, it is apparent that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the present disclosure. Therefore, the description and the drawings are to be considered illustrative rather than restrictive. The drawings constituting a part of this specification illustrate specific embodiments in which the present subject matter may be implemented by way of illustration and not limitation. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, so that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, this detailed description should not be construed as limiting, and the scope of the various embodiments is limited only by the appended claims and the full scope of equivalents authorized by these claims.

[0171] These embodiments of the subject matter of the present invention may be referred to herein individually and / or collectively as the term "invention", which is merely for convenience, and if more than one invention or inventive concept is actually disclosed, this does not mean that the scope of the present application is voluntarily limited to any single invention or inventive concept. Therefore, although specific embodiments have been shown and described herein, it should be understood that any arrangement intended to achieve the same purpose can replace the specific embodiments shown. The present disclosure is intended to cover any and all modifications or variations of the various embodiments. By reading the above description, the combination of the above embodiments and other embodiments not specifically described here will be obvious to those skilled in the art.

Claims

1. A database management system comprising: At least one processor is programmed to perform operations comprising: a first host running at a first container of the cloud environment, the first host having a first version, and the first host being configured to perform a source role; a second host running at a second container of the cloud environment, the second host having a second version different from the first version, and the second host being configured to perform a replica role of the source role; receiving, by a network layer operating in the cloud environment, a first request directed to a second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; as well as The first request is sent by the network layer to the second host at the second container.

2. The database management system according to claim 1, wherein the operation further comprises: receiving, by the network layer, a second request directed to a second host; The network layer determines that the second request is inconsistent with the allowed request data; as well as The network layer sends a second request to the first host.

3. The database management system of claim 2, the second request is a read request and the first request is a copy request.

4. The database management system according to claim 1, wherein the operation further comprises: receiving, by the network layer, a third request from the second host directed to the first host; The network layer determines that the third request is inconsistent with the allowed request data; as well as The third request is blocked by the network layer.

5. The database management system according to claim 1, before receiving the first request, the operation further comprises: receiving an upgrade instruction indicating a version upgrade for the first host and the second host; Shut down the second host; Upgrade the second host to the second version; as well as Restart the second host at the second container.

6. The database management system according to claim 5, wherein the operation further comprises: receiving an indication that the second host is synchronized with the first host running at the first container; and Configure the secondary host to run the source role.

7. The database management system according to claim 6, wherein the operation further comprises: shutting down the first host at the first container; Upgrading the first host to the second version; and The first host at the new container in the cloud environment is restarted, and the restarted first host at the new container is configured to perform a replica role of the source role.

8. The database management system according to claim 1, wherein the operation further comprises: receiving an indication that a first host running at a first container has crashed; and Configure the secondary host to run the source role.

9. A method for operating a database management system, the method comprising: a first host running at a first container of the cloud environment, the first host having a first version, and the first host being configured to perform a source role; a second host running at a second container of the cloud environment, the second host having a second version different from the first version, and the second host being configured to perform a replica role of the source role; receiving, by a network layer operating in the cloud environment, a first request directed to a second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; as well as The first request is sent by the network layer to the second host at the second container.

10. The method according to claim 9, further comprising: receiving, by the network layer, a second request directed to a second host; determining, by the network layer, that the second request is inconsistent with allowed request data; and The network layer sends a second request to the first host. The method of claim 10 , the second request being a read request and the first request being a copy request.

12. The method according to claim 9, further comprising: receiving, by the network layer, a third request from the second host directed to the first host; determining, by the network layer, that the third request is inconsistent with allowed request data; and The third request is blocked by the network layer.

13. The method according to claim 9, before receiving the first request, further comprising: receiving an upgrade instruction indicating a version upgrade for the first host and the second host; Shut down the second host; Upgrade the second host to the second version; as well as Restart the second host at the second container.

14. The method according to claim 13, further comprising: receiving an indication that the second host is synchronized with the first host running at the first container; and Configure the secondary host to run the source role.

15. The method according to claim 14, further comprising: shutting down the first host at the first container; Upgrading the first host to the second version; and The first host at the new container in the cloud environment is restarted, and the restarted first host at the new container is configured to perform a replica role of the source role.

16. The method according to claim 9, further comprising: receiving an indication that a first host running at a first container has crashed; and Configure the secondary host to run the source role.

17. A non-transitory machine-readable medium comprising instructions thereon, the instructions, when executed by at least one processor, causing the at least one processor to perform operations comprising: a first host running at a first container of the cloud environment, the first host having a first version, and the first host being configured to perform a source role; a second host running at a second container of the cloud environment, the second host having a second version different from the first version, and the second host being configured to perform a replica role of the source role; receiving, by a network layer operating in the cloud environment, a first request directed to a second host; determining, by the network layer, that the first request is consistent with allowed request data describing allowed requests; as well as The first request is sent by the network layer to the second host at the second container.

18. The medium of claim 17, the operations further comprising: receiving, by the network layer, a second request directed to a second host; determining, by the network layer, that the second request is inconsistent with allowed request data; and The network layer sends a second request to the first host.

19. The medium of claim 18, the second request is a read request and the first request is a copy request.

20. The medium of claim 17, the operations further comprising: receiving, by the network layer, a third request from the second host directed to the first host; The network layer determines that the third request is inconsistent with the allowed request data; as well as The third request is blocked by the network layer.

Images