Multi-tenant provider network database connection management and governance

Abstract

Techniques for database connection management and governance in a multi-tenant provider network are described. One or more database broker instances connect to client applications and can obtain database connections for those client applications. The database connections can be pinned to particular client applications and / or multiplexed by and thus shared by multiple clients.

Description

Background Technology

[0001] Developing modern software applications that scale not only easily but also efficiently using databases is extremely complex. This work requires carefully matching application requirements with available database capacity to maintain predictable performance at a reasonable cost and with considerable complexity. For example, a trading platform application might rapidly scale to respond to market events and create a large number of database connections. Similarly, an e-commerce application might keep database connections open and idle to provide faster responses to buyers when they engage.

[0002] Therefore, many developers over-provision database capacity to handle peak (or even excessive) expected utilization. This results in significant resource waste, as many database resources are often left idle, increasing complexity and management overhead, and raising overall costs. Furthermore, developers may need to distribute their databases across multiple instances to gain additional capacity, further increasing complexity. Even so, applications and databases can still be overwhelmed when faced with unforeseen peaks. Attached Figure Description

[0003] Various embodiments according to this disclosure will be described with reference to the accompanying drawings, in which:

[0004] Figure 1 This is a diagram illustrating an environment for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0005] Figure 2 This is a diagram illustrating database session state tracking and connection matching according to some implementation schemes.

[0006] Figure 3 This is a diagram illustrating dynamic database connection multiplexing according to some implementation schemes.

[0007] Figure 4 This is a diagram illustrating the database connection buffer in a database proxy instance according to some implementation schemes.

[0008] Figure 5 This is a diagram illustrating an exemplary architecture for selecting a database agent instance according to some implementation schemes.

[0009] Figure 6 This is a diagram illustrating exemplary application programming interface calls used in an environment for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0010] Figure 7This is a diagram illustrating an exemplary user interface for configuring a database agent for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0011] Figure 8 , Figure 9 , Figure 10 and Figure 11 This is a diagram illustrating an exemplary user interface for creating a database agent for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0012] Figure 12 This is a diagram illustrating an exemplary modification of a connection string for utilizing a database agent for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0013] Figure 13 This is a flowchart illustrating the operation of a method for database connection management and control in a multi-tenant provider network according to some implementation schemes.

[0014] Figure 14 This illustrates an example provider network environment based on some implementation schemes.

[0015] Figure 15 This is a block diagram of an example provider network offering storage services and hardware virtualization services to customers, based on some implementation schemes.

[0016] Figure 16 This is a block diagram illustrating an example computer system that can be used in some implementation schemes. Detailed Implementation

[0017] This disclosure relates to methods, apparatus, systems, and non-transitory computer-readable storage media for database connection management and allocation in multi-tenant provider networks. According to some embodiments, the database service provides a fully managed connection allocation and management system that can intelligently reuse established database connections to serve queries or transactions from multiple application connections. Thus, a smaller number of database connections can support a large number of application connections. Therefore, the database service can allow users to maintain predictable database performance by adjusting the number of open database connections and removing unnecessary application connections. The connection allocation and management system can automatically perform management functions on behalf of its users, for example, through automatic provisioning, updating, scaling, and / or fault tolerance features. Furthermore, embodiments can automatically scale capacity in response to application load and can distribute workloads across multiple fault-tolerant zones to minimize interruptions caused by hardware or system failures.

[0018] Therefore, applications (including those based on modern "serverless" technologies) can effectively utilize relational databases with scalable and predictable performance. By regulating application connections to the database and reusing database connections to serve multiple application requests, implementations provide resilience for applications that can transparently tolerate transient failures without requiring complex fault handling code. In some implementations, database traffic destined for the database can be quickly and automatically routed to an alternate database instance while preserving application connections. Furthermore, in some implementations, users can build secure applications that leverage the database through centralized credential management and optional implementations of database authentication via IAM roles. Advantageously, the implementations disclosed herein eliminate the burden typically borne by application developers in deploying, managing, or scaling computing infrastructure associated with database connectivity.

[0019] Figure 1 This is a diagram illustrating an environment for database connection management and control in a multi-tenant provider network, according to some implementation schemes. Figure 1 A database connection management and control system 150 (or "DCMGS") is illustrated, in which a database service 110 performs database connection management and control using one or more database agent instances 120A-120N. The DCMGS 150 and the database service 110 may be implemented as software, hardware, or a combination of both. In some embodiments, the implementation of these components may be part of a provider network 100.

[0020] Provider Network 100 (or “cloud” provider network) provides users with the ability to utilize one or more computing-related resources of various types, such as computing resources (e.g., executing virtual machine (VM) instances and / or containers, executing batch jobs, executing code instead of pre-configured servers), data / storage resources (e.g., object storage, block-level storage, data archive storage, databases and database tables, etc.), network-related resources (e.g., configuring virtual networks comprising multiple sets of computing resources, content delivery networks (CDNs), domain name services (DNS)), application resources (e.g., databases, application build / deployment services), access policies or rules, identity policies or rules, machine images, routers, and other data processing resources, etc. These computing resources and other computing resources may be provided as services, such as hardware virtualization services that can execute computing instances, storage services that can store data objects, etc. Users of Provider Network 100 (or “customers”) may utilize one or more user accounts associated with a customer account, but these items may be used somewhat interchangeably depending on the context of use. Users can interact with provider network 100 on one or more intermediate networks 106 (e.g., the Internet) via one or more interfaces, such as through application programming interface (API) calls, via a console implemented as a website or application, etc. The interface may be part of the provider network 100's control plane, or serve as a front-end to said control plane, which includes "back-end" services that support and enable services that may be offered more directly to customers.

[0021] Therefore, a cloud provider network (or simply "the cloud") typically refers to a large pool of accessible virtualized computing resources (such as compute, storage, and network resources, applications, and services). The cloud provides users with convenient, on-demand network access to a shared pool of configurable computing resources that can be programmatically provisioned and published in response to client commands. These resources can be dynamically provisioned and reconfigured to adapt to variable loads. Thus, cloud computing can be viewed as both applications delivered as a service over a publicly accessible network (e.g., the internet, cellular networks) and the hardware and software in the cloud provider's data centers that provide these services.

[0022] A cloud provider network can be structured into multiple zones, where a zone can be a geographical area where the cloud provider clusters its data centers. Each zone can include multiple (e.g., two or more) Availability Zones (AZs) interconnected via a dedicated high-speed network (e.g., fiber optic communication connection). AZs provide isolated fault domains and comprise one or more data center facilities with independent power supplies, networks, and cooling compared to facilities in other AZs. Preferably, AZs within a zone are spaced far enough apart that the same natural disaster (or other fault-causing event) should not simultaneously affect or take down more than one AZ. Customers can connect to the cloud provider network's AZs via a publicly accessible network 106 (e.g., the Internet, cellular communication network).

[0023] Typically, provider network traffic and operations can be broadly categorized into two types: control plane operations carried on the logical control plane and data plane operations carried on the logical data plane. The data plane represents the movement of user data through a distributed computing system, while the control plane represents the movement of control signals through the distributed computing system. The control plane typically includes one or more control plane components distributed across and implemented by one or more control servers. Control plane traffic typically includes administrative operations such as system configuration and management (e.g., resource placement, hardware capacity management, diagnostic monitoring, system status information). The data plane includes customer resources implemented on the provider network (e.g., compute instances, containers, block storage volumes, databases, file storage). Data plane traffic typically includes non-administrative operations such as moving customer data to and from customer resources. Control plane components are typically implemented on a separate set of servers from the data plane servers, and control plane traffic and data plane traffic can be sent through separate / different networks.

[0024] To provide these and other computing resource services, provider network 100 typically relies on virtualization technology. For example, virtualization technology can be used to provide users with the ability to control or utilize computing instances (e.g., VMs using a passenger operating system (O / S) that may or may not run on top of the underlying host O / S; containers that may or may not operate within a VM; instance operations that can be performed on "bare metal" hardware without an underlying hypervisor), where one or more computing instances can be implemented using a single electronic device. Thus, users can directly utilize computing instances hosted by the provider network (e.g., provided by a hardware virtualization service) to perform various computing tasks. Alternatively, users can indirectly utilize computing instances by submitting code to be executed by the provider network (e.g., via an on-demand code execution service), which in turn utilizes the computing instances to execute the code, typically without requiring the user to have any control or knowledge of the underlying computing instances involved.

[0025] For example, in various implementations, a "serverless" function may include code that can be executed on demand, provided by a user or other entity, such as the provider network itself. The serverless function may be maintained within the provider network 100 by an on-demand code execution service and may be associated with a specific user or account or generally accessible by multiple users / accounts. The serverless function may be associated with a Uniform Resource Locator (URL), Uniform Resource Identifier (URI), or other references that can be used to invoke the serverless function. The serverless function may be executed by a compute instance, such as a virtual machine or container, upon triggering or invocation. In some implementations, the serverless function may be invoked via an Application Programming Interface (API) call or a specially formatted Hypertext Transfer Protocol (HTTP) request message. Therefore, a user can define serverless functions that can be executed on demand without requiring the user to maintain dedicated infrastructure to execute the serverless function. Alternatively, the serverless function can be executed on demand using resources maintained by the provider network 100. In some implementations, these resources may be maintained in a "ready" state (e.g., with a pre-initialized runtime environment configured to execute the serverless function), thereby allowing near real-time execution of the serverless function.

[0026] Typically, many types of modern computing applications rely on databases, particularly relational databases. For example, computing applications backing up websites or mobile applications may be implemented within provider network 100 using one or more computing type services 132 (e.g., hardware virtualization services or serverless code execution services), or in another location by one or more computing devices 105 (e.g., applications running in a data center, applications running via “client” devices such as personal computers, smart devices, mobile devices, etc.). At any given time, these computing applications can utilize the database functionality provided by one or more database instances 122A-122N of database service 110 by sending messages carrying database statements (e.g., Structured Query Language (SQL) statements) to database instances 122A-122N, which can perform operations in response and optionally send back database results (e.g., status indicators, data stored in the database, data generated based on data stored in response to a query, etc.). In this way, the computing application acts as a “client” application 130A-130B and thus a “server” by requesting database instances 122A-122N to perform some operations.

[0027] In some implementations, database instances 122A-122N are isolated database environments running within provider network 100 and typically contain one or more user-created databases that can be accessed using the same client tools and applications used to access the independent database instances. Each database instance 122A-122N may have a database instance identifier, which may be a user-provided name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of provider network 100) the database instance 122A-122N during user interaction with the database service 110 interface. Each database instance 122A-122N may support a database engine. For example, database service 110 may support multiple database engines, including but not limited to MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Aurora, etc. In some implementations, database service 110 may support one or more NoSQL databases, one or more object database management systems, one or more object relational database systems, one or more data warehouse systems (e.g., Amazon Redshift), serverless interactive query services, etc. Interaction with database instances 122A-122N can be performed using database statements (e.g., queries, commands, etc.) that conform to a defined query language (such as that defined by the query language definition). This defined query language can be one or more of various dialects, extensions, and implementations of SQL, such as Transact-SQL (T-SQL), Procedural Language / SQL (PL / SQL), PL / pgSQL (Procedural Language / PostgreSQL), SQL-86, SQL-92, SQL:2016, etc. Therefore, database instances 122A-122N can implement various types of databases with various configurations. For example, the first database instance 122A and the second database instance 122B can be a master failover pair, completely different databases, etc.

[0028] In some implementations, user 102 can interact with DCMGS 150 to configure a database proxy service that automatically manages and controls database connections on behalf of the user and the user's applications 130A-130B.

[0029] As indicated above, many types of modern applications 130A-130B that rely on databases may require over-provisioning and managing database resources for various reasons. The DCMGS 150 can eliminate this often-needed over-provisioning and proactive management.

[0030] For example, many applications have unpredictable workloads. Applications supporting highly variable workloads may attempt to open a large number of new database connections to support the surge. DCMGS's 150 connection dominance allows users to gracefully scale applications handling unpredictable workloads by efficiently using database connections. DCMGS150 can reuse established database connections to serve queries or transactions requested from multiple applications. Therefore, users can support more application connections with fewer database connections, thus efficiently utilizing database resources. DCMGS 150 allows users to maintain predictable database performance by adjusting the number of open database connections. In some implementations, DCMGS 150 can remove unnecessary application requests to maintain overall application performance and availability.

[0031] As another example, some applications frequently open database connections. Applications based on technologies such as serverless, PHP, or Ruby on Rails may frequently open new database connections with each application request. The DCMGS 150 allows clients to maintain a pool of database connections to avoid inefficiently establishing a new connection for every new request.

[0032] In addition, many applications keep database connections open but idle (or unused). Applications in industries such as SaaS or e-commerce often keep database connections idle to minimize response time when customers re-engage. Instead of over-provisioning the database to support most idle connections, users can configure DCMGS 150 to maintain these idle connections while establishing database connections only as needed to optimally serve active requests.

[0033] As yet another example, many applications require high availability through transient failures. In some implementations, the DCMGS 150 allows users to build resilient applications that can transparently tolerate transient failures without complex fault handling code. In some implementations, the DCMGS 150 very quickly and automatically routes traffic to a standby database instance while maintaining many or all application connections.

[0034] Furthermore, in some implementations, DCMGS 150 provides improved security and centralized credential management. DCMGS 150 helps users build secure applications by allowing users to choose to implement Identity and Access Management (IAM)-based authentication (e.g., via IAM service 108) to access the database, and also enables users to centralize database credential management through a secure credential storage service 109.

[0035] For example, user 102 can use an application (e.g., a web-based console) or other functionality to launch one or more database instances 122A-122N (as reflected in circle (A)) within database service 110, which may be a relational database, a NoSQL instance, or other type of database. For example, user 102 can use a web-based console application to select a “Launch DB Instance” user interface input element and provide multiple configuration parameters, such as the identifier of the requested DB engine type and version, licensing model, instance type, storage type and quantity, master user credentials, etc. Alternatively, the user's computing device can issue an API call to database service 110 with similar information, or the user can launch and / or configure the database instance using other techniques known to those skilled in the art.

[0036] Optionally, as shown in circle (B), user 102 may enable computing device 104 to configure role information for IAM service 108, thereby allowing DCMGS 150 to create resources on behalf of the user's account (e.g., one or more load balancers 112A-112X, one or more routers 116A-116M, one or more database agent instances 120A-120N, etc.), and / or configure IAM service 108 with execution role information associated with client applications 130A-130B.

[0037] As shown in circle (C), user 102 may also optionally store “secret” values ​​(e.g., usernames and / or passwords for accessing database instances) through a secure credential storage service 109 (e.g., AWS Secret Manager), which can securely store and control access to these secret values ​​(e.g., via encryption, access control, etc.).

[0038] User 102 can then configure DCMGS 150 using an application executed by computing device 104 to provide connection management and control over database instance 122. As an example, user 102 can utilize one or more user interfaces, such as... Figure 7 , Figure 8 , Figure 9 , Figure 10 and / or Figure 11One or more of the user interfaces depicted herein provide configuration information to the controllers 114 of the DCMGS 150 (possibly many controllers 114 operating in a distributed manner) via one or more messages (as shown in circle (1)). Among various types of data, the configuration information may include one or more of the following: identifiers of database instances 122A-122N, agent names, identifiers of the database engine type implemented by database instances 122A-122N, whether backend database connections should be encrypted (e.g., using TLS), a set of tags, etc. Figures 7 to 11 The following description provides other examples of potential types of configuration information.

[0039] Upon receiving one or more of these requests, controller 114 may initiate a workflow to configure database connection management and domination accordingly. For example, in some implementations, controller 114 creates resources, such as endpoints (e.g., entities associated with network addresses that can receive network traffic destined for those addresses), in a provider network account associated with a user account. These resources will later be used by client application 130 to send database statements to database instance 122. The workflow may also include provisioning one or more database agent instances 120A-120N, which may include launching compute instances (e.g., virtual machines) with database agent software configured as described herein, and / or configuring database agent instances 120A-120N for users (e.g., configuring rule engine 141 with system and / or user-provided rules to control how each database agent instance will operate). In some implementations, controller 114 may launch at least two database agent instances 120A-120N (e.g., in an active-active configuration), which may be specifically placed in different availability zones (e.g., isolated fault domains) of provider network 100. Before and / or after starting each database instance 122A-122N, controller 114 may configure database instances 122A-122N and / or database agent instances 120A-120N directly (or indirectly, such as via configuration initialization files or flags) based on configuration information provided by the user (e.g., in circle (1)).

[0040] After startup and configuration, in some implementations, optionally using authentication / authorization information (e.g., credentials) provided by user 102 as configuration information, by IAM service 108, by security credential storage service 109, etc., each database agent instance 120A-120N opens a management connection 154 at circle (3) to each database instance 122 (as identified by user 102 during initial configuration). Management connection 154 allows database agent instances 120A-120N to ensure that database instances 122A-122N are running and responsive, and can successfully access database instances 122A-122N, etc., via the provided credentials. Management connection 154 may also allow database agent instances 120A-120N to detect failures of database instance 122A and cause additional database statements received during this downtime to be alternatively passed to another database instance (e.g., a failover database instance), and / or can resume using the initial database instance (if it recovers). Therefore, client connections that do not actively use to connect to the backend database of the faulty database instance are likely to be unaffected by the fault and may not even be aware of it.

[0041] As part of the workflow, controller 114 can also configure load balancer 112, one or more routers 116A-116M, and endpoints such that the endpoints provide database statements (e.g., client-initiated requests to the database instance) to the database agent instance (e.g., 120A). This can occur from load balancer 112 to router 116, and the database statements can identify the database agent instance 120A, for example, via an endpoint identifier of the location where the database statements are received. Controller 114 can also configure rules for the rule engine 141 of each database agent instance 120 to control how the database agent instance 120A will operate. Rules can be configured by the operator of provider network 100 and / or by user 102. For example, user 102 can provide configuration data indicating whether user 102 wants to pin certain client connections to certain database connections, and optionally provide instructions on how to determine which connections to pin (e.g., defining conditions for client connections, such as the existence of a database statement that creates a ready statement, and when said conditions are observed, pinning the client connection to the database connection). As another example, user 102 can provide configuration data indicating whether, when, and / or how a connection should be considered terminated (e.g., due to a certain amount of inactivity), whether to enable connection multiplexing, whether to enable pinning, the number of possible database connections that can be used, whether (and / or how) certain database statements should be rewritten, etc. During operation, each database agent instance 120A can therefore use this rule engine 141 and associated rules to determine the actions to be performed.

[0042] In some implementations, router 116 and database proxy instances 120A-120N may implement a heartbeat mechanism, wherein database proxy instances 120A-120N periodically or periodically send heartbeat messages to one or more routers 116A-116M, the heartbeat messages indicating the continued availability of database proxy instances 120A-120N. In some implementations, the heartbeat message includes a load value indicating the current (or most recent) "load" placed on the proxy instance. For example, the load value may be the number of client connections 140A-140Z that database proxy instance 120A is handling (or is capable of handling), and / or amounts of processor utilization, memory utilization, network utilization, etc.

[0043] In some implementations, router 116A may select one of the database proxy instances 120A-120N as the recipient of client connections based on this load value associated with each of the one or more database proxy instances 120A-120N, which are associated with the endpoints receiving database statements. For example, router 116A may select the one with the lowest load among those matching database proxy instances 120A-120N, such as the one with the lowest load value, although other routing mechanisms may be implemented. This mechanism can be beneficial when using multiple routers 116, because a purely “local” decision made on a part of the router may not be optimal due to the actions of other routers. For example, while a router may only send a small number of connections to a particular database proxy instance (and therefore it may appear unbusy locally), it is possible that other routers have already sent a large number of connections to the proxy instance. Therefore, the router can avoid making poor decisions based solely on its local view, but can instead gain global visibility into the true load of the proxy due to the load value reported via heartbeat messages.

[0044] The controller 114 can then send an endpoint identifier (e.g., one or more of an IP address, hostname, port value, etc.) to the user 102's computing device 104 at circle (4), which the user 102 can use to configure client applications 130A-130B at circles (5A) and / or (5B). For example, the user 102 can update the database connection string used by client application 130 to connect to a database instance via the endpoint identifier.

[0045] Subsequently, when client application 130 needs to access database instance 122, client application 130 can open a client connection 140A with database proxy instance 120A at circle (6). This connection can be achieved by client application 130B, for example, executing within a virtual network within provider network 100, sending a request to an endpoint within the virtual network, which is thus routed to load balancer 112, router 116, and / or database proxy instance 120A, which may be outside the virtual network. In this way, database proxy 120A may optionally “emerge” in multiple different virtual networks within provider network 100.

[0046] Database proxy instance 120A may authorize and / or authenticate using a role of the calling application or an authentication token provided by the calling application, for example by leveraging IAM service 108 to determine whether the role is allowed to access the database instance (and therefore the client application does not need to directly access database authentication credentials), determining whether the authentication token is valid and associated with privileges to access the database instance, etc. Alternatively, database proxy instance 120A may use a token provided by the client application (e.g., as part of opening a connection or with a database statement request) to retrieve credentials (e.g., username and / or password) for accessing the database instance, or retrieve this token from IAM service 108 and use it with security credential storage service 109 to obtain credentials that can be passed to database instance 122A to authenticate the client. Alternatively, database proxy instance 120A may use a token including a username / password provided by the client application (e.g., as part of opening a connection or with a database statement request) to directly authenticate the client to the database instance.

[0047] Database agent instance 120A can acquire database connection 152 (between the agent and the database instance) at circle (7) by opening a new database connection 152, identifying and thus selecting a database connection from a pool of available open connections 145 that matches the characteristics of the client connection, or by updating an existing connection from the pool of available open connections 145 to match the expected connection state of the client connection (e.g., by sending a database statement / command to the database instance to change the session state as described herein). In some implementations, database connection 152 may or may not be "fixed" to the client connection based on configured rules and / or thresholds (i.e., dedicated to the client's use), and may further be switched between unfixed (i.e., multiplexed) and fixed or fixed and unfixed by similar rules and / or thresholds. When a particular client connection and database connection are peered (temporarily or when fixed), database agent instance 120A may update the peer mapping 143 data structure so that the database agent instance can determine which connections are in use and which connections are peers. In some implementations, when a database connection in pool 145 is selected and used, database agent instance 120A can therefore remove the connection from pool 145 (e.g., by removing the connection identifier from the pool 145 structure, or updating the status flag associated with the connection), and / or update peer mapping 143 to reflect the connection's association.

[0048] In some implementations, database agent instance 120A can track database statement traffic to identify commands or actions performed within the traffic that modify the session state of a connection. Database agent instance 120A can thus maintain a mapping of the current "state" of a connection for each client connection (in client connection state 144 storage device) and database connection (in database connection state 142 storage device).

[0049] It is known that for a database connection, the client application and / or the database instance itself can set or modify the connection settings. Throughout the lifecycle of this connection, or before further modification of these settings, both the database instance and the client implicitly assume agreement to this state. However, due to the possible multiplexing of these database connections 152, a particular database connection 152 can be used by different clients with different expectations regarding the connection state. Therefore, the database agent instance 120A can identify the connection state, for example, by tracking database statement traffic through observing specific known statements that cause the state to change. Thus, as indicated above, this state can be tracked on a per-client-connection and per-database-connection basis via states 142 / 144.

[0050] Subsequently, when a database statement is received on client connection 140A, if the client connection is not "pinned" to a specific database connection, database agent instance 120A can use the client connection's trace state (144) and compare the trace state with the state (142) of one of the database connections to identify available open connections from the connection pool 145 between the agent instance and the database instance. It is possible that an exact match is found, and thus the matched database connection 152 can be directly used to process the database statement. However, if no matching database connection is found through this state comparison process, database agent instance 120A can, for example, modify the state of the available database connection to match the client connection state by replaying or issuing one or more database statements (e.g., to set encoding values ​​or time zones).

[0051] In various implementations, various types of state can be tracked depending on the specific type of database protocol used. For example, state may include system variables set on a per-connection basis, including but not limited to timezone values, session timeouts, connection modes (e.g., read / write), and the specific interpretation mode used by the database (e.g., ANSI mode, legacy mode). As another example, state may include connection characteristics, including but not limited to character sets, usernames, and whether the connection uses encryption. As yet another example, state may include database characteristics such as the existence of temporary tables created during the connection or prepared statements (e.g., SQL templates) (which may be referenced later).

[0052] However, in some implementations, if any (or a particular type of) state change occurs, the database agent instance 120A-120N may alternatively “pin” the client connection to the associated database connection (thus eliminating multiplexing of the database connection until the client connection terminates), which may depend on the agent instance having enough other database connections that will remain available for multiplexing (depending on a configurable threshold).

[0053] After obtaining the correct database connection 152, at circle (8), database agent instance 120A can forward the database statement received from client application 130 to database instance 122A, which can process the database statement and return any necessary response, which can be sent back to client application 130.

[0054] In some implementations, database agent instance 120A may also track the connection protocol-level state 140 for each connection to determine whether the database instance has completed all processing of a particular database statement (e.g., a query). Therefore, database agent instance 120A can be state-aware with respect to the connection protocol itself and track this state as connection protocol-level state 140. Thus, database agent instance 120A can determine when it can “release” database connection 152 into the pool as an available connection. For example, releasing a connection in the middle of a transaction (e.g., between when the query has been passed to the database instance and when all data has been returned) is inappropriate, but it can release the connection when database agent instance 120A can verify that the transaction has completed. Database agent instance 120A may need to track various subtle protocol scenarios to prevent premature release, such as when a client sends a multi-statement query (where the database will return multiple sets of results), so database agent instance 120A can track how many sets of results are to be returned, thereby determining when the transaction is complete.

[0055] More in detail, Figure 2 This is a diagram illustrating database session state tracking and connection matching according to some implementation schemes. In this example, a database agent instance 120A of DCMGS 150 receives one or more database statements (or commands) through an existing client connection C[B] 140B. Therefore, database agent instance 120A obtains a database connection 154 for forming an end-to-end client-to-database connection, which can be used to deliver one or more database statements and receive responses from the database instance. As previously indicated, database agent instance 120A may track connection-related information such as client connection status 144, database connection status 142, connection protocol level status 140, connection pool 145 availability information (e.g., where each entry indicates which database connections 152 are still in use or available), and / or a connection peering map 200 storing peer entries indicating which client connections are using which database connections (at a certain point in time, or as “fixed” peers).

[0056] To obtain database connection 152, the database agent instance 120A can be flexibly configured according to the implementer's needs to perform one or more operations. For example, in some cases, the database agent instance 120A can check whether the client connection is already "pinned" to a backend database connection, thus reserving the backend database for the client connection. For example, this mapping information can be tracked as part of a peer mapping 200 that associates client connections with corresponding database connections. If a matching database connection is found for the client connection, that database connection can be used; otherwise, the database agent instance 120A can perform other operations.

[0057] For example, in some implementations, database agent instance 120A may create new database connections that may or may not be permanently used for client connections. This may occur, for example, under certain connection restrictions imposed by the database instance or the configuration user.

[0058] In some implementations, database agent instance 120A may attempt to find a “matching” database connection with the same state as the client connection. For example, database agent instance 120A may attempt to find a similar state between an entry in database connection state 142 and an entry in client connection state 144 corresponding to the client connection where the database statement arrived. As shown, client connection C[B] state 144 indicates that the connection / session expects the character set to be “UTF-8”, and a matching database connection DB[A] state 142 with the character set also being “UTF-8” is found (and is also marked as “available” in the availability state of connection pool 145). Therefore, this connection is suitable for use because it does not conflict with any assumptions / expectations of the client connection.

[0059] Alternatively, database agent instance 120A can update existing database connection states to match the state desired by the client connection. For example, client connection C[C] state 144 is shown as including the character set LATIN1 and a defined temporary table. Database agent instance 120A can update an existing database connection to a matching state, for example, by “replaying” the database statement created using the temporary table through database connection C[B], or by replaying the database statement created using the temporary table and also changing the character set (from UTF-8 to LATIN1) using connection C[A].

[0060] Figure 3This diagram illustrates dynamic database connection multiplexing according to some embodiments. In some embodiments, DCMGS 150 can implement dynamic connection multiplexing technology, where client connections can be pinned to a backend database connection until a point or threshold (e.g., the maximum number of connections being utilized at a certain threshold), and after said point, DCMGS 150 can begin multiplexing database connections with future and / or existing client connections. DCMGS 150 can also revert to using pinned connections when the threshold (or a second threshold) is crossed again in another aspect. For example, DCMGS 150 can use only pinned connections until 75% of the allowed database connections 152 are used, and then, exceeding said threshold, DCMGS 150 can begin multiplexing additional database connections for subsequent client connections and / or existing (previously pinned) client connections. Furthermore, DCMGS 150 can return to dedicating itself to pinned connections, for example, when a certain threshold (e.g., less than 50%) of connections are in active use at a certain point in time or within a time window. Using multiple thresholds can prevent the "jittering" between these states that might occur when using a single threshold.

[0061] Therefore, by using dynamic multiplexing, the implementation can increase processing speed by using fixed connections 140A-140M (which does not require the backend database connection acquisition operation), while flexibly allowing additional multiplexed connections 140N-140Z, which together (in conjunction with fixed connections 140A-140M) allow more client connections to database instance 122A than database instance 122A can directly provide (via database connection 152) to the client connections of database instance 122A.

[0062] Figure 4 This is a diagram illustrating database connection buffering in a database proxy instance according to some implementations. In some implementations, database instance 122A can prevent database failures through connection dominance, where, for example, when more requests 402 are waiting to be processed than database connections 152 available to database instance 122A, database instance 122A can buffer 400 requests arriving at client connections 140A-140Z (e.g., database statements for queries, which may be implemented using a first-in-first-out (FIFO) queue or similar). Therefore, by tracking the database protocol state of actively used database connections 152, at the end of a session where it is detected that a database connection can be reused for one of the buffered requests 402, these buffered requests 402 are allowed to continue being served (albeit with some introduced latency), rather than the previous system that had already encountered a failure (e.g., the client was unable to connect to the database instance). Client applications would require special connection management logic to gracefully handle said failures without impacting their users.

[0063] Optionally, in some implementations, this scenario can be achieved by providing the load value (via heartbeat messages) of database instance 122A to one or more routers 116A-116M, thereby enabling horizontal scaling of the set of database instances 122A-122N. The routers can detect saturation of the proxy instances (e.g., by determining that the proxy instances are handling a threshold number of client connections) and signal to controller 114 (at circle (A)) to add one or more additional database proxy instances 120B-120N (at circle (B)). This may include starting one or more additional database proxy instances 120B-120N, updating the routing configuration of one or more routers 116A, etc.

[0064] Traditionally, horizontally scaling a database is very difficult and resource-intensive, especially when database writers are involved. However, with the techniques disclosed herein, implementations can scale the database more simply, even when writers are involved, and reduce the resource burden of such scaling work (e.g., establishing and / or dismantling TLS connections) on the database instance by offloading it to a database proxy instance. Furthermore, complex authentication can be similarly offloaded to the database proxy instance (e.g., by interacting with IAM services and / or security credential storage services) and removed from the database instance itself, allowing the database instance to perform the actual data querying and manipulation operations.

[0065] In some implementations, it's possible that clients will only access the "new" database proxy instance when they create a new connection, since existing connections may belong to a previously existing database proxy instance. Therefore, in some implementations, client connections may expire after a period of inactivity (e.g., 10 seconds, 1 minute, 5 minutes, 30 minutes, 1 hour) and / or according to a schedule, causing these clients that later need to reconnect to use the database instance, which will distribute the client connection load accordingly.

[0066] In some implementations, if the client connection is lost (from the perspective of the proxy instance), the database instance can continue sending response data. Some implementations may simply terminate this connection and create a new one; however, some implementations may sense the disconnection and allow response data to be "drained" to the proxy instance, and at the end, the proxy instance may reuse the connection (e.g., by designating it as available in a connection pool).

[0067] Figure 5This is a diagram illustrating an exemplary architecture for selecting a database proxy instance according to some implementation schemes. As described herein, multiple routers 116A-116M can be used to distribute traffic to the database proxy instance 120, and it is possible that multiple different database proxy instances may be eligible to serve a particular client connection.

[0068] In some implementations, router 116A can select a database proxy instance for client connections by identifying the qualified database proxy instance with the lowest load (e.g., associated with an appropriate database instance). In some implementations, this determination can be based on comparing multiple client connections that, from the router's perspective, have been routed to each of these database proxy instances. As shown at 510, router 116A might have a local perspective, i.e., it has routed ten connections to the first proxy instance 'A' and twenty connections to the second proxy instance 'B', and therefore router 116A can determine to select database proxy instance 'A' 120A for new client connections 140X service. This configuration is very efficient when a group of database proxy instances are connected through only a single router 116A; however, it can be further improved when multiple routers 116A-116M are involved.

[0069] In some implementations, database proxy instances 120A-120N may periodically or on a schedule send heartbeat messages 502A-502B to one or more routers 116A-116M. These heartbeat messages allow routers 116A-116M to determine that database proxy instances 120A-120N are operational. In some implementations, these heartbeat messages 502A-502B include a load value, as described herein, which, as an example, may indicate the number of client connections served by the sending database proxy instance. In the example shown here, database proxy instance 'A' 120A is indicated by a star icon with the number '500', indicating that the instance is serving five hundred client connections, while database proxy instance 'B' 120B is indicated by a star icon with the number '25', indicating that the instance is serving twenty-five client connections. Therefore, as shown at 510, each router 116A-116M can obtain a "global" view of the true utilization of database proxy instances 120A-120N and better select the proxy instance with the least load, where database proxy instance 'B' is known to serve a total of twenty-five connections, even though the first router 116A passes twenty of these connections.

[0070] In some implementations, the set of database agents 120 can also be used to improve the performance of multi-instance databases. For example, the database can be implemented in a "multi-master" replication configuration, where multiple database instances 122 may be able to perform writes / updates to the underlying data. In this case, it is generally beneficial for only one database instance to perform these writes, thereby eliminating the communication and processing overhead required for multiple instances to update each other, perform conflict detection and resolution, etc. Therefore, in some implementations, the database agent instances can be configured with a consistent selection scheme, allowing each agent instance to independently and always select the same database instance as the recipient of write statements. For example, each agent selects the database instance with the lowest network address (e.g., its hash), which may be the same at all times and vary between different time periods (e.g., database instance 'A' is selected by all agents in the first hour, then database instance 'D' is selected by all agents in the next hour, etc.). This configuration performs particularly well when a database instance used as the selected “writer” instance encounters a failure or other problem, in which case some database agents can detect the problem (e.g., unresponsiveness of the database instance) and fall back to the “next” writer instance based on their common selection criteria (e.g., the second smallest network address).

[0071] Figure 6 This is a diagram illustrating exemplary application programming interface calls used in an environment for database connection management and control in a multi-tenant provider network, according to some implementation schemes. (See also: Regarding...) Figure 1 As shown and described, a user can use a computing device to send one or more messages to the DCMGS150 to provide configuration information. These messages can carry API method calls to, for example, create a database agent (shown in 605) and register one or more database agent targets (shown in 610).

[0072] The create-db-proxy 605 API call used to create a database proxy can include one or more attribute values ​​shown here as attribute value pairs, including but not limited to the user-specified identifier of the proxy (db-proxy-name), the identifier of the database engine family of the associated database instance (engine-family), such as MySQL, Oracle, etc., the user definition and / or the user's authentication technology (auth, which may include the identifier of the user or user group and the corresponding authentication technology, such as regular database credentials, the use of IAM-based technologies disclosed herein, etc.), the identifier of one or more subnets (or networks) from which client applications can access the proxy service, the identifier of whether an encrypted connection (e.g., TLS or SSL) will be used (require-tls), and the identifier of one or more user-provided tags (tags) that can be associated with the proxy that the user can use for resource tracking, accounting, etc.

[0073] This create-db-proxy 605 API call can be issued together with the register-db-proxy-targets 610 API call, and it can include one or more attribute values ​​shown here as attribute value pairs. These attribute values ​​may include, for example, identifiers of a group of database instances (target-group-name), identifiers of a database instance cluster (db-cluster-identifier), and / or identifiers of one or more database instances (db-instance-identifier), which the user may have defined / registered with the database service.

[0074] These API calls 605 / 610 can be issued by an application or user, for example, via a computing device that responds to the user's interaction with it. For example, database services and / or DCMGS can provide various types of user interfaces to allow users to configure the database connection management and control services described herein.

[0075] For example, Figure 7 This is a diagram illustrating an exemplary user interface 700 for configuring a database agent for database connection management and control in a multi-tenant provider network, according to some implementation schemes.

[0076] For example, a database service may provide a console (e.g., via a web-based application, a dedicated application, etc.) that allows users to easily configure the proxy service (e.g., as a step in database creation) in an interface that is the same as or related to the interface used for more direct database management. This console may include a user interface 700 that provides user interface input elements (e.g., text boxes) that allow users to provide an identifier (or name) for the proxy (the proxy identifier, here configured as 'database-1_proxy-1'), which may be unique for all user proxies within their account or within a specific area of ​​the provider's network. This exemplary user interface 700 also provides input elements (here, checkboxes) that allow users to specify whether encryption will be used for the connection (requiring transport layer security).

[0077] This exemplary user interface 700 also provides user input elements (drop-down boxes) allowing users to indicate the maximum percentage of connections that can be used for the connection pool (e.g., the maximum connection limit for a database) (Connection Pool Maximum Connections, configured here by the user to 90%), drop-down boxes allowing users to select “secret” credentials (e.g., provided by the security credential storage service 109) for the database user accounts that the agent can connect to (Credential Manager Secrets), IAM execution roles that the agent system can use to access these secrets (IAM Roles for Accessing Secrets), and drop-down user input elements allowing users to select whether (e.g., in addition to specifying database credentials) IAM-based authentication will be used to connect to the agent.

[0078] Alternatively or otherwise, Figure 8 , Figure 9 , Figure 10 and Figure 11 This is a diagram illustrating an exemplary user interface for creating a database agent for database connection management and control in a multi-tenant provider network, according to some implementation schemes. This set of user interfaces can be provided as part of a dedicated process for configuring agent-based services for databases.

[0079] Figure 8 The user interface 800 may include... Figure 7 Similar to the user input elements shown, these elements can request a proxy identifier, a database engine family identifier, and configuration data regarding whether the database connection needs to be encrypted.

[0080] As the next user interface 900, Figure 9This user interface 900 allows users to specify, for example, the target database group to be served by a proxy-based service via the 'Add Database' user input element, where users can select database identifiers known to the database service one or more times. In this example, the user has selected identifiers for two databases, 'B' and 'D', both of which are MySQL type databases. This user interface 900 also allows users to provide an idle timeout for the client (here, by selecting values ​​in minutes and seconds), indicating when the client connection can be "closed" after inactivity. This user interface 900 also allows users to specify conditions (here, selecting the default fixed configuration for exiting certain statements) when the client connection is pinned (or not pinned) to the database connection, and / or to set a connection "borrowing" timeout value (by setting values ​​in minutes and seconds) for how long a database connection can be "borrowed" from the pool.

[0081] Figure 10 The user interface 1000 allows the user to specify authentication-related configuration information, including "secret" credentials (credential manager resource name) used to create a connection to the database, IAM roles (IAM roles) of the agent used to access these secret credentials, identifiers for the client's authentication method (e.g., credentials stored in the secure credential storage service 109, encrypted with the database's default username and password, IAM authentication roles, etc.), identifiers for the database's virtual network, and / or providing one or more subnets of the IP range that the database can use in the selected virtual network (selected here as "default" and "SUB-1A").

[0082] Figure 11 The user interface 1100 includes additional user interface input elements related to configuring capacity settings, which may include allowing the user to specify whether DCMGS 150 can automatically manage (e.g., autoscaling) the amount of resources used, and / or the minimum and / or maximum amount of “capacity” units that the agent can utilize (e.g., the number of compute instances, the amount of a single compute resource, etc.). Here, the user has specified that at least two compute instances can be used (one agent instance for each execution / implementation), and a maximum of 256 compute instances can be utilized.

[0083] Figure 12This is a diagram illustrating exemplary connection string modifications for utilizing a database agent for database connection management and domination in a multi-tenant provider network, according to some implementation schemes. As described herein, when configuring agent-based database connection management and domination, DCMGS 150 can provide a response to a user / client instructing them on one or more endpoints (e.g., network address, hostname, port, etc.) that they can use to access the database instance. Therefore, a user can configure their application to access the database, for example, by simply changing the query connection string to use the returned hostname and port. Thus, the existing connection string 1205 can be modified by changing DATABASE_INSTANCE_HOSTNAME to DBPROXY_DNS_NAME returned by DCMGS (in 1210) and changing DATABASE_INSTANCE_PORT (in 1205) to DBPROXY_PORT (in 1210).

[0084] Figure 13 This is a flowchart illustrating operation 1300 of a method for database connection management and control according to some embodiments. Some or all of operation 1300 (or other processes described herein, or variations thereof, and / or combinations thereof) is executed under the control of one or more computer systems configured with executable instructions, and is implemented as code (e.g., executable instructions, one or more computer programs, or one or more application programs) that commonly executes on one or more processors, implemented by hardware, or implemented by a combination thereof. The code is stored, for example, on a computer-readable storage medium in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of operation 1300 is executed by DCMGS 150 and / or database service 110 as shown in other figures.

[0085] Operation 1300 includes: at box 1305, receiving one or more database statements at the database agent instance via a first client connection to the first client application. For example, the database statements may include database queries such as 'SELECT' queries, UPDATE statements, DELETE statements, etc. The first client application and the database agent instance may be implemented in a multi-tenant provider network, and the first client application may be executed by a hardware virtualization service, a serverless code execution service, etc.

[0086] Operation 1300 further includes, at block 1310, determining that the first client connection is not pinned to a database connection with the database instance. In some implementations, determining this includes performing a lookup in the data structure using a key (e.g., an identifier for the first client connection, etc.) to determine whether a connection has already been mapped to a specific database connection, and in this case, determining that no connection has been mapped to a specific database connection. In some implementations, a client connection may be pinned to a database connection when the client issues a specific type of database statement (e.g., changing the connection state in a specific way), when the database broker instance is serving fewer than a threshold number of client connections, when fewer than a threshold number of client connections are active or predicted to be active, when fewer than a threshold number of database connections are being used, etc.

[0087] Operation 1300 further includes, at block 1315, identifying the connection state associated with the first client connection, wherein the connection state is based at least in part on previous database statements sent by the first client application through the first client connection. In some embodiments, the database agent instance tracks the state of each client connection based on traces, such as commands sent as part of database statements. In some embodiments, this state is tracked for each client connection in a data structure.

[0088] At box 1320, operation 1300 also includes obtaining a first database connection from a database connection pool between the database broker and the database instance, at least in part based on the connection state. In various implementations, obtaining may include creating a new database connection, identifying a database connection with a state that is the same as (or does not conflict with) the client connection's connection state, modifying a database connection with a state that conflicts with the client connection state so that it no longer conflicts (e.g., by sending or “replaying” one or more database statements that set the state), etc.

[0089] In some implementations, block 1320 includes determining that the connection state associated with the first client connection and another connection state associated with the first database connection do not conflict.

[0090] In some implementations, block 1320 includes sending a fifth or more database statements via a first database connection to bring the first database connection into conformance to a connection state associated with the first client connection, wherein the fifth or more database statements are selected at least in part based on the connection state. In some implementations, the fifth or more database statements cause the database instance to update at least one of the following: system variables, wherein system variables include one of a timezone, session timeout, connection mode, or a Structured Query Language (SQL) standard or mode; connection characteristic values, including one of a character set, username, or encryption utilization; or database characteristics, including one of a temporary table or a prepared statement.

[0091] Operation 1300 also includes, at box 1325, sending one or more database statements via the first database connection. The one or more database statements may be specified according to an SQL dialect and may be sent to an endpoint within the provider network associated with the database instance using IP messages.

[0092] In some implementations, operation 1300 further includes determining, by the database agent instance, that a first client connection will be pinned to a first database connection; receiving a second or more database statements via the first client connection; determining that the first client connection is pinned to the first database connection; and sending the second or more database statements via the first database connection. In some implementations, determining that the first client connection will be pinned to the first database connection is based on analysis of a third or more database statements received via the first client connection prior to receiving the second or more database statements.

[0093] In some embodiments, operation 1300 further includes determining that the first client application no longer actively uses the first database connection; and designating the first database connection as available in a database connection pool. In some embodiments, operation 1300 further includes receiving a fourth or more database statements via a second client connection; and sending the fourth or more database statements via the first database connection while the first client connection with the first client application still exists.

[0094] In some embodiments, operation 1300 further includes receiving at the provider network one or more request messages initiated by client devices of users of the provider network to configure a database proxy within the provider network, the one or more request messages identifying one or more database instances within the provider network, the one or more database instances including the database instance; starting one or more database proxy instances within the provider network, the one or more database proxy instances including the database proxy instance; associating endpoints within the provider network with the one or more database proxy instances; and connecting to the one or more database instances through each of the one or more database proxy instances. In some embodiments, operation 1300 further includes determining to add another database proxy instance to the one or more database proxy instances to create a plurality of database proxy instances; starting another database proxy instance; and updating at least one of a router or load balancer to send traffic to the plurality of database proxy instances. In some embodiments, operation 1300 further includes receiving multiple heartbeat signals initiated by the plurality of database proxy instances at the router or load balancer, and in some embodiments, operation 1300 further includes determining that one or more expected heartbeat signals were not received from the database proxy instances; and causing at least some client connections to failover from the database proxy instance to another database proxy instance. In some implementations, operation 1300 further includes maintaining the first client connection during failover; ending the failover; receiving a sixth or more database statements from the first client application via the first client connection; and sending the sixth or more database statements via the database proxy instance, wherein the failover is not visible to the first client application. In some implementations, each of the plurality of heartbeat signals includes a load value associated with the corresponding database proxy instance, wherein the load value is one of resource utilization or the number of client connections; and operation further includes selecting a database proxy instance as the receiver of traffic by a router or load balancer based on analysis of one or more of the plurality of load values.

[0095] Figure 14An example provider network (or “service provider system”) environment according to some implementations is illustrated. Provider network 1400 may provide resource virtualization to customers via one or more virtualization services 1410, which allow customers to purchase, lease, or otherwise obtain virtualized resource instances 1412 implemented on devices within one or more provider networks in one or more data centers. These virtualized resources include, but are not limited to, computing and storage resources. A local Internet Protocol (IP) address 1416 may be associated with resource instance 1412; the local IP address is the internal network address of resource instance 1412 on provider network 1400. In some implementations, provider network 1400 may also provide customers with public IP addresses 1414 and / or ranges of public IP addresses (e.g., Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses) that can be obtained from provider 1400.

[0096] Typically, provider network 1400 can allow service provider customers (e.g., customers of one or more client networks 1450A-1450C, operating one or more customer devices 1452) to dynamically associate at least some public IP addresses 1414 assigned to or allocated to the customer with specific resource instances 1412 assigned to the customer via virtualization service 1410. Provider network 1400 can also allow customers to remap public IP addresses 1414 previously mapped to one virtualized computing resource instance 1412 assigned to the customer to another virtualized computing resource instance 1412 also assigned to the customer. For example, a service provider's (e.g., the operator of customer networks 1450A-1450C) customers can use the virtualized computing resource instances 1412 and public IP addresses 1414 provided by the service provider to implement customer-specific applications and present those applications on an intermediate network 1440, such as the Internet. Then, other network entities 1420 on intermediate network 1440 can generate traffic destined for public IP address 1414 published by customer networks 1450A-1450C; this traffic is routed to the service provider data center and, at the data center, routed via the network layer to the local IP address 1416 of the virtualized computing resource instance 1412, which is currently mapped to the destination public IP address 1414. Similarly, response traffic from virtualized computing resource instance 1412 can be routed back to the source entity 1420 on intermediate network 1440 via the network layer.

[0097] As used herein, a local IP address refers to an internal or “private” network address of a resource instance, such as within a provider network. Local IP addresses may be within an address block reserved by the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 and / or have an address format specified by IETF RFC 4193, and may be changed within the provider network. Network traffic originating outside the provider network is not directly routed to a local IP address; instead, traffic uses a public IP address that maps to the local IP address of the resource instance. A provider network may include network devices or equipment that provide Network Address Translation (NAT) or similar functionality to perform mappings from public IP addresses to local IP addresses and vice versa.

[0098] A public IP address is a variable network address on the Internet assigned to a resource instance by a service provider or customer. Traffic routed to a public IP address is, for example, translated via 1:1 NAT and then forwarded to the corresponding local IP address of the resource instance.

[0099] Some public IP addresses may be assigned to specific resource instances by the provider's network infrastructure; these public IP addresses may be referred to as standard public IP addresses, or simply standard IP addresses. In some implementations, the mapping of standard IP addresses to the local IP addresses of resource instances is the default startup configuration for all resource instance types.

[0100] At least some public IP addresses can be assigned to or obtained by customers of Provider Network 1400; customers can then assign their assigned public IP addresses to specific resource instances assigned to them. These public IP addresses may be referred to as customer public IP addresses, or simply customer IP addresses. Instead of being assigned to resource instances by Provider Network 1400 as in the case of standard IP addresses, customer IP addresses can be assigned to resource instances by the customer, for example, via an API provided by the service provider. Unlike standard IP addresses, customer IP addresses are assigned to customer accounts and can be remapped to other resource instances by the corresponding customer as needed or desired. Customer IP addresses are associated with customer accounts, not with specific resource instances, and the customer controls the IP address until the customer chooses to release it. Unlike traditional static IP addresses, customer IP addresses allow customers to mask resource instance or availability zone failures by remapping their public IP addresses to any resource instance associated with their customer account. For example, customer IP addresses enable customers to resolve customer resource instance or software issues by remapping their customer IP addresses to a replacement resource instance.

[0101] Figure 15This is a block diagram of an example provider network offering storage services and hardware virtualization services to customers according to some implementation schemes. Hardware virtualization service 1520 provides multiple computing resources 1524 (e.g., VMs) to customers. For example, computing resources 1524 may be leased or rented to customers of provider network 1500 (e.g., customers implementing customer network 1550). Each computing resource 1524 may be configured with one or more local IP addresses. Provider network 1500 may be configured to route packets from the local IP addresses of computing resources 1524 to public internet destinations, and from public internet sources to the local IP addresses of computing resources 1524.

[0102] Provider network 1500 may provide a client network 1550, for example, coupled to intermediate network 1540 via local network 1556, with the ability to implement virtual computing systems 1592 via hardware virtualization service 1520 coupled to intermediate network 1540 and provider network 1500. In some embodiments, hardware virtualization service 1520 may provide one or more APIs 1502 (e.g., network service interfaces) via which client network 1550 may access the functionality provided by hardware virtualization service 1520, for example, via console 1594 (e.g., web-based applications, standalone applications, mobile applications, etc.). In some embodiments, at provider network 1500, each virtual computing system 1592 at client network 1550 may correspond to computing resources 1524 that are leased, rented, or otherwise provided to client network 1550.

[0103] Clients can access the functionality of the storage service 1510 from an instance of the virtual computing system 1592 and / or another client device 1590 (e.g., via console 1594) via one or more APIs 1502, for example, to access and store data from storage resources 1518A-1518N of the virtual data storage area 1516 (e.g., folders or "buckets", virtualized volumes, databases, etc.) provided by the provider network 1500. In some embodiments, a virtualized data storage gateway (not shown) may be provided at the client network 1550, which may locally cache at least some data (e.g., frequently accessed or critical data) and may communicate with the storage service 1510 via one or more communication channels to upload new or modified data from the local cache, thereby maintaining the primary storage area (virtualized data storage area 1516) for data storage. In some implementations, users can install and access virtual data storage volumes 1516 via a storage service 1510 that acts as a storage virtualization service via a virtual computing system 1592 and / or on another client device 1590, and these volumes may appear to the user as local (virtualized) storage devices 1598.

[0104] Although Figure 15 Although not shown, virtualization services can also be accessed from resource instances within provider network 1500 via API 1502. For example, a customer, equipment service provider, or other entity can access virtualization services from within a corresponding virtual network on provider network 1500 via API 1502 to request the allocation of one or more resource instances within the virtual network or another virtual network.

[0105] Explanatory System

[0106] In some implementations, a system that implements some or all of the techniques described herein may include a general-purpose computer system that includes or is configured to access one or more computer-accessible media, such as... Figure 16 The computer system 1600 is shown. In the illustrated embodiment, the computer system 1600 includes one or more processors 1610 coupled to system memory 1620 via an input / output (I / O) interface 1630. The computer system 1600 also includes a network interface 1640 coupled to the I / O interface 1630. Although Figure 16 Computer system 1600 is shown as a single computing device, but in various embodiments, computer system 1600 may include a single computing device or any number of computing devices configured to work together as a single computer system 1600.

[0107] In various embodiments, computer system 1600 may be a single-processor system including one processor 1610 or a multiprocessor system including several processors 1610 (e.g., two, four, eight, or another suitable number). Processor 1610 may be any suitable processor capable of executing instructions. For example, in various embodiments, processor 1610 may be a general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs) (e.g., x86, ARM, PowerPC, SPARC, or MIPS ISA or any other suitable ISA). In a multiprocessor system, each of processors 1610 may typically (but not necessarily) implement the same ISA.

[0108] System memory 1620 can store instructions and data accessible by processor 1610. In various embodiments, system memory 1620 can be implemented using any suitable memory technology, such as random access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiment, program instructions and data (e.g., the methods, techniques, and data described above) that implement one or more desired functions are shown stored in system memory 1620 as DCMGS code 1625 and data 1626.

[0109] In one embodiment, I / O interface 1630 may be configured to coordinate I / O traffic between processor 1610, system memory 1620, and any peripheral devices (including network interface 1640 or other peripheral interfaces) in a device. In some embodiments, I / O interface 1630 may perform any necessary protocols, timing, or other data transformations to convert data signals from one component (e.g., system memory 1620) into a format suitable for use by another component (e.g., processor 1610). In some embodiments, I / O interface 1630 may include devices that support attachment via various types of peripheral buses (e.g., variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard). In some embodiments, the functionality of I / O interface 1630 may be split into two or more separate components, such as a northbridge and a southbridge. Moreover, in some embodiments, some or all of the functionality of I / O interface 1630 (e.g., the interface to system memory 1620) may be directly incorporated into processor 1610.

[0110] Network interface 1640 can be configured to allow computer system 1600 to communicate with other devices 1660 attached to one or more networks 1650 (e.g., such as...). Figure 1 The network interface 1640 can exchange data with other computer systems or devices shown in the diagram. In various embodiments, the network interface 1640 can support communication via any suitable wired or wireless general-purpose data network (e.g., Ethernet network type). Additionally, the network interface 1640 can support communication via telecommunications / telephone networks (e.g., analog voice networks or digital fiber optic communication networks), via storage area networks (SANs) (e.g., Fibre Channel SANs), or via I / O of any other suitable type of network and / or protocol.

[0111] In some embodiments, computer system 1600 includes one or more offload cards 1670 (including one or more processors 1675 and possibly one or more network interfaces 1640), which are connected using I / O interfaces 1630 (e.g., a bus implementing a version of the Fast Peripheral Component Interconnect (PCI-E) standard or another interconnect such as Fast Path Interconnect (QPI) or Hyper Path Interconnect (UPI). For example, in some embodiments, computer system 1600 may act as a host electronic device hosting computing instances (e.g., operating as part of a hardware virtualization service), and one or more offload cards 1670 may act as a virtualization manager that can manage the computing instances running on the host electronic device. As an example, in some embodiments, offload card 1670 may perform computing instance management operations, such as pausing and / or unpausing computing instances, starting and / or terminating computing instances, performing memory transfer / copy operations, etc. In some implementations, these management operations may be performed by the offload card 1670 in cooperation with a hypervisor (e.g., upon request from the hypervisor) executed by other processors 1610A-1610N of the computer system 1600. However, in some implementations, the virtualization manager implemented by the offload card 1670 may accommodate requests from other entities (e.g., from the computing instance itself) and may not cooperate with (or serve) any individual hypervisor.

[0112] In some embodiments, system memory 1620 may be an embodiment of a computer-accessible medium configured to store program instructions and data as described above. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible media. Generally, computer-accessible media may include non-transitory storage media or memory media, such as magnetic or optical media, such as a disk or DVD / CD coupled to computer system 1600 via I / O interface 1630. Non-transitory computer-accessible storage media may also include any volatile or non-volatile media, such as RAM (e.g., SDRAM, Double Data Rate (DDR) SDRAM, SRAM, etc.), read-only memory (ROM), etc., which may be included as system memory 1620 or another type of memory in some embodiments of computer system 1600. Furthermore, computer-accessible media may include transmission media or signals conveyed via communication media (e.g., networks and / or wireless links, such as those implemented via network interface 1640), such as electrical signals, electromagnetic signals, or digital signals.

[0113] The various implementation schemes discussed or proposed herein can be implemented in a wide variety of operating environments. In some cases, the operating environment may include one or more user computers, computing devices, or processing devices that can be used to operate any of several applications. User or client devices may include: any of several general-purpose personal computers, such as desktop or laptop computers running standard operating systems; and cellular, wireless, and handheld devices running mobile software and capable of supporting several networking and messaging protocols. Such systems may also include several workstations running a variety of commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and / or other devices capable of communicating via a network.

[0114] Most implementations utilize at least one network familiar to those skilled in the art to support communication using any of a variety of widely available protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), File Transfer Protocol (FTP), Universal Plug and Play (UPnP), Network File System (NFS), Public Internet File System (CIFS), Extensible Messaging and Field Protocol (XMPP), AppleTalk, etc. The network may include, for example, a Local Area Network (LAN), a Wide Area Network (WAN), a Virtual Private Network (VPN), the Internet, an intranet, an extranet, a Public Switched Telephone Network (PSTN), an infrared network, a wireless network, and any combination thereof.

[0115] In implementations using a web server, the web server can run any of a variety of server or middleware applications, including HTTP servers, File Transfer Protocol (FTP) servers, Common Gateway Interface (CGI) servers, data servers, Java servers, business application servers, etc. The server can also execute programs or scripts in response to requests from user devices, such as those implemented in any programming language (e.g., ...). One or more web applications are made of one or more scripts or programs written in any scripting language (such as Perl, Python, PHP, or TCL) and combinations thereof. The server may also include a database server, including but not limited to database servers available from Oracle(R), Microsoft(R), Sybase(R), IBM(R), etc. The database server may be relational or non-relational (e.g., "NoSQL"), distributed or non-distributed, etc.

[0116] The environment disclosed herein may include various data storage areas as discussed above, as well as other memories and storage media. These may reside in various locations, such as on storage media local to one or more computers (and / or residing within one or more computers) or on storage media remotely located across a network at any one or all of the computers. In a particular set of embodiments, information may reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to a computer, server, or other network device may be stored locally or remotely, as appropriate. Where the system includes computerized devices, each of these devices may include hardware elements that can be electrically coupled via a bus, including, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touchscreen, or keypad), and / or at least one output device (e.g., display device, printer, or speaker). Such a system may also include one or more storage devices, such as hard disk drives, optical storage devices, and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash memory cards, etc.

[0117] Such devices may also include computer-readable storage medium readers, communication devices (e.g., modems, network interface cards (wireless or wired), infrared communication devices, etc.), and working memory, as discussed above. A computer-readable storage medium reader may be connected to or configured to receive a computer-readable storage medium, which represents a remote, local, fixed, and / or removable storage device, as well as a storage medium for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. Systems and various devices will also typically include multiple software applications, modules, services, or other elements residing within at least one working memory device, including operating systems and applications such as client applications or web browsers. It should be understood that alternative embodiments may have numerous variations different from the embodiments described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. Furthermore, connections to other computing devices, such as network input / output devices, may be employed.

[0118] Storage media and computer-readable media containing code or portions thereof may include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information (e.g., computer-readable instructions, data structures, program modules or other data), including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by system devices. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing various embodiments.

[0119] Various implementation schemes have been described in the foregoing. Specific configurations and details have been elaborated for illustrative purposes to provide a thorough understanding of the implementation schemes. However, those skilled in the art will also understand that implementation schemes can be practiced without specific details. Furthermore, well-known features may have been omitted or simplified to avoid obscuring the described implementation schemes.

[0120] In this document, bracketed text and boxes with dashed borders (e.g., large dashes, small dashes, dotted dashes, and dots) are used to illustrate optional operations that add additional features to some embodiments. However, this notation should not be interpreted as implying that these are the only options or optional operations, and / or that boxes with solid borders in some embodiments are not optional.

[0121] In various embodiments, reference numerals with suffix letters (e.g., 1518A-1518N) can be used to indicate that the referenced entity may have one or more instances, and when multiple instances exist, each instance need not be identical, but may instead share some general characteristics or act according to convention. Furthermore, unless explicitly stated to the contrary, the use of a particular suffix is ​​not intended to imply the existence of a specific number of entities. Therefore, in various embodiments, two entities using the same or different suffix letters may or may not have the same number of instances.

[0122] The references to "an implementation," "implementation," "example implementation," etc., to describe an implementation scheme may include a specific feature, structure, or characteristic, but each implementation scheme may not necessarily include that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same implementation scheme. Additionally, when a specific feature, structure, or characteristic is described in conjunction with an implementation scheme, it should be assumed that, whether explicitly described or not, implementing such a feature, structure, or characteristic in conjunction with other implementation schemes is within the knowledge of those skilled in the art.

[0123] Furthermore, in the various embodiments described above, unless otherwise specifically indicated, the disjunctive language of phrases such as "at least one of A, B, or C" is intended to mean A, B, or C, or any combination thereof (e.g., A, B, and / or C). Therefore, disjunctive language is generally not intended and should not be construed as implying that a given embodiment requires at least one of A, at least one of B, and at least one of C to be present respectively.

[0124] At least some implementations of the disclosed technology may be described according to the following terms:

[0125] 1. A computer-implemented method, comprising:

[0126] At the database agent instance running within the multi-tenant provider network, one or more database statements are received via a first client connection to the first client application;

[0127] It is determined that the first client connection is not fixed to any database connection with the database instance;

[0128] Identify the connection state associated with the first client connection, wherein the connection state is based at least in part on a previous database statement sent by the first client application through the first client connection;

[0129] A first database connection is obtained from the database connection pool between the database proxy instance and the database instance, based at least in part on the connection state.

[0130] Send the one or more database statements via the first database connection;

[0131] Determine that the first client application no longer actively uses the first database connection; and

[0132] The first database connection is designated as available in the database connection pool, even though the first client connection remains open.

[0133] 2. The computer-implemented method as described in Clause 1, wherein obtaining the first database connection from the database connection pool comprises:

[0134] Determine if the connection state associated with the first client connection matches another connection state associated with the first database connection.

[0135] 3. The computer-implemented method as described in any one of clauses 1 to 2, wherein obtaining the first database connection from the database connection pool comprises:

[0136] Send a second or more database statements via the first database connection to make the first database connection conform to the connection state associated with the first client connection, wherein the second or more database statements are selected at least in part based on the connection state.

[0137] 4. A computer-implemented method, comprising:

[0138] At the database proxy instance, one or more database statements are received via a first client connection to the first client application.

[0139] It is determined that the first client connection is not fixed to the database connection with the database instance;

[0140] Identify the connection state associated with the first client connection, wherein the connection state is based at least in part on a previous database statement sent by the first client application through the first client connection;

[0141] At least in part based on the connection state, a first database connection is obtained from the database connection pool between the database proxy instance and the database instance; and

[0142] The one or more database statements are sent via the first database connection.

[0143] 5. The computer-implemented method as described in Clause 4 further includes:

[0144] The database proxy instance determines that the first client connection will be fixed to the first database connection;

[0145] Receive one or more database statements via the first client connection;

[0146] Determine that the first client connection is fixed to the first database connection; and

[0147] Send the second or more database statements via the first database connection.

[0148] 6. The computer-implemented method as described in Clause 5, wherein determining that the first client connection will be pinned to the first database connection is based on analysis of a third or more database statements received via the first client connection prior to receiving a second or more database statements.

[0149] 7. The computer-implemented method as described in any one of Clauses 4 to 6 further includes:

[0150] Determine that the first client application no longer actively uses the first database connection; and

[0151] Specify the first database connection as available in the database connection pool.

[0152] 8. The computer-implemented method as described in Clause 7 further includes:

[0153] Receive a fourth or more database statements via a second client connection; and

[0154] While the first client connection with the first client application is still in place, the fourth or more database statements are sent through the first database connection.

[0155] 9. A computer-implemented method as described in any one of clauses 4 to 8, wherein obtaining the first database connection from the database connection pool comprises:

[0156] It is determined that the connection state associated with the first client connection and another connection state associated with the first database connection do not conflict.

[0157] 10. A computer-implemented method as described in any one of clauses 4 to 9, wherein obtaining the first database connection from the database connection pool comprises:

[0158] Send a fifth or more database statements via the first database connection to make the first database connection conform to the connection state associated with the first client connection, wherein the fifth or more database statements are selected at least in part based on the connection state.

[0159] 11. The computer-implemented method as described in Clause 10, wherein the fifth or more database statements cause the database instance to update at least one of the following:

[0160] System variables, wherein the system variables include one of time zone, session timeout, connection mode, or Structured Query Language (SQL) standard or mode;

[0161] Connection characteristic values, which include one of the following: character set, username, or encryption exploit rate; or

[0162] Database features, which include either temporary tables or prepared statements.

[0163] 12. The computer-implemented method as described in any one of clauses 4 to 11, further comprising:

[0164] At the provider network, one or more request messages initiated by a client device of a user of the provider network are received to configure the database proxy instance within the provider network, the one or more request messages identifying one or more database instances within the provider network, the one or more database instances including the database instance;

[0165] Launch one or more database agent instances within the provider network, the one or more database agent instances including the database agent instance;

[0166] Associate the endpoints within the provider network with the one or more database proxy instances; and

[0167] Connect to the one or more database instances through each of the one or more database proxy instances.

[0168] 13. The computer-implemented method as described in Clause 12 further includes:

[0169] Determine to add another database proxy instance to the one or more database proxy instances to create multiple database proxy instances;

[0170] Start the other database agent instance; and

[0171] Update at least one of the routers or load balancers to send traffic to the plurality of database agent instances.

[0172] 14. The computer-implemented method as described in Clause 13 further includes:

[0173] Receive multiple heartbeat signals initiated by the multiple database agent instances at the router or load balancer.

[0174] 15. The computer-implemented method as described in Clause 14 further includes:

[0175] It was determined that one or more expected heartbeat signals were not received from the database agent instance; and

[0176] For at least some client connections, a failover from one database proxy instance to another is triggered.

[0177] 16. The computer-implemented method as described in Clause 15 further includes:

[0178] The first client connection is maintained during the failover;

[0179] End the failover;

[0180] Receive a sixth or more database statements from the first client application via the first client connection; and

[0181] The sixth or more database statements are sent via the database proxy instance, wherein the failover is not visible to the first client application.

[0182] 17. The computer-implemented method as described in Clause 14, wherein:

[0183] Each of the plurality of heartbeat signals includes a load value associated with the corresponding database proxy instance, wherein the load value is one of resource utilization or the number of client connections; and

[0184] The method further includes: the router or the load balancer selecting a database proxy instance as the receiver of traffic based on analysis of one or more of a plurality of load values.

[0185] 18. A system comprising:

[0186] A first or more electronic devices are used to implement one or more database instances; and

[0187] A second or more electronic device is configured to implement one or more database proxy instances, the one or more database proxy instances including instructions that, when executed, cause the one or more database proxy instances to:

[0188] Receive one or more database statements via a first client connection with the first client application;

[0189] It is determined that the first client connection is not fixed to the database connection with the database instance;

[0190] Identify the connection state associated with the first client connection, wherein the connection state is based at least in part on a previous database statement sent by the first client application through the first client connection;

[0191] At least in part based on the connection state, a first database connection is obtained from the database connection pool between the database proxy instance and the database instance; and

[0192] The one or more database statements are sent via the first database connection.

[0193] 19. The system as described in Clause 18, wherein, in order to obtain the first database connection from the database connection pool, the instruction, upon execution, further causes the one or more database agent instances to:

[0194] It is determined that the connection state associated with the first client connection and another connection state associated with the first database connection do not conflict.

[0195] 20. The system as described in any one of Clauses 18 to 19, wherein, in order to obtain the first database connection from the database connection pool, the instruction, upon execution, further causes the one or more database agent instances to:

[0196] Send a second or more database statements via the first database connection to make the first database connection conform to the connection state associated with the first client connection, wherein the second or more database statements are selected at least in part based on the connection state.

[0197] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, it will be apparent that various modifications and changes may be made thereto without departing from the broader spirit and scope of this disclosure as set forth in the claims.

Claims

1. A computer-implemented method, comprising: At the database proxy instance, one or more database statements are received via a first client connection to the first client application. It is determined that the first client connection is not fixed to the database connection with the database instance; Identify the connection state associated with the first client connection, wherein the connection state is based at least in part on a previous database statement sent by the first client application through the first client connection; A first database connection is obtained from the database connection pool between the database proxy instance and the database instance, based at least in part on the connection state. Send the one or more database statements via the first database connection; The database proxy instance determines that the first client connection will be fixed to the first database connection; Receive one or more database statements via the first client connection; as well as It is determined that the first client connection is fixed to the first database connection; as well as Send the second or more database statements via the first database connection; The determination that the first client connection will be pinned to the first database connection is based on the analysis of a third or more database statements received via the first client connection prior to receiving the second or more database statements.

2. The computer-implemented method as described in claim 1, further comprising: It is determined that the first client application no longer actively uses the first database connection; as well as Specify the first database connection as available in the database connection pool.

3. The computer-implemented method as described in claim 2, further comprising: Receive a fourth or more database statements via a second client connection; as well as While the first client connection with the first client application is still in place, the fourth or more database statements are sent through the first database connection.

4. The computer-implemented method of claim 1, wherein obtaining the first database connection from the database connection pool comprises: It is determined that the connection state associated with the first client connection and another connection state associated with the first database connection do not conflict.

5. The computer-implemented method of claim 1, wherein obtaining the first database connection from the database connection pool comprises: Send a fifth or more database statements via the first database connection to make the first database connection conform to the connection state associated with the first client connection, wherein the fifth or more database statements are selected at least in part based on the connection state.

6. The computer-implemented method of claim 5, wherein the fifth or more database statements cause the database instance to update at least one of the following: System variables, wherein the system variables include one of time zone, session timeout, connection mode, or Structured Query Language (SQL) standard or mode; Connection characteristic values, which include one of the following: character set, username, or encryption exploit rate; or Database features, which include either temporary tables or prepared statements.

7. The computer-implemented method as described in claim 1, further comprising: At the provider network, one or more request messages initiated by a client device of a user of the provider network are received to configure the database proxy instance within the provider network, the one or more request messages identifying one or more database instances within the provider network, the one or more database instances including the database instance; Launch one or more database agent instances within the provider network, the one or more database agent instances including the database agent instance; Associate the endpoints within the provider network with the one or more database proxy instances; as well as Connect to the one or more database instances through each of the one or more database proxy instances.

8. The computer-implemented method of claim 7, further comprising: Determine to add another database proxy instance to the one or more database proxy instances to create multiple database proxy instances; Start the other database agent instance; as well as Update at least one of the routers or load balancers to send traffic to the plurality of database agent instances.

9. The computer-implemented method as described in claim 8, further comprising: Receive multiple heartbeat signals initiated by the multiple database agent instances at the router or load balancer.

10. The computer-implemented method of claim 9, further comprising: It was determined that one or more expected heartbeat signals were not received from the database agent instance; as well as For at least some client connections, a failover from one database proxy instance to another is triggered.

11. The computer-implemented method of claim 10, further comprising: The first client connection is maintained during the failover; End the failover; Receive a sixth or more database statements from the first client application via the first client connection; as well as The sixth or more database statements are sent via the database proxy instance, wherein the failover is not visible to the first client application.

12. The computer-implemented method as described in claim 9, wherein: Each of the plurality of heartbeat signals includes a load value associated with the corresponding database agent instance, wherein the load value is one of resource utilization or the number of client connections; and The method further includes: the router or the load balancer selecting a database proxy instance as the receiver of traffic based on analysis of one or more of a plurality of load values.

13. A system comprising: A first or more electronic devices are used to implement one or more database instances; as well as A second or more electronic device is configured to implement one or more database proxy instances, the one or more database proxy instances including instructions that, when executed, cause the one or more database proxy instances to: Receive one or more database statements via a first client connection with the first client application; It is determined that the first client connection is not fixed to the database connection with the database instance; Identify the connection state associated with the first client connection, wherein the connection state is based at least in part on a previous database statement sent by the first client application through the first client connection; A first database connection is obtained from the database connection pool between the database proxy instance and the database instance, based at least in part on the connection state. as well as Send the one or more database statements via the first database connection; The database proxy instance determines that the first client connection will be fixed to the first database connection; Receive one or more database statements via the first client connection; as well as It is determined that the first client connection is fixed to the first database connection; as well as Send the second or more database statements via the first database connection; The determination that the first client connection will be pinned to the first database connection is based on the analysis of a third or more database statements received via the first client connection prior to receiving the second or more database statements.

Images