使用基于提示的路由在数据库系统中的工作负载切换的制作方法

本文所述的主题涉及数据库系统，更具体地，涉及采用主数据库和辅助热待机数据库的数据库系统。

背景技术：

数据库系统包括数据库和数据库管理系统(DBMS)。数据库是有组织的数据集合。DBMS包括在一个或多个处理器上运行并与用户、其他应用和数据库进行交互以捕获和分析数据的计算机软件。DBMS可以使能数据库的定义、创建、查询、更新和管理。

技术实现要素：

计算机系统被配置为提供数据库系统。计算机系统包括一个或多个处理器、由一个或多个处理器实现的主数据库系统、以及由一个或多个处理器实现的辅助数据库系统。辅助数据库系统被配置为主数据库系统的热备份系统。辅助数据库系统能够在主数据库系统中断期间提供至少最小量的主数据库系统的基本功能。主数据库系统通过可在计算机系统上运行的编程指令来配置，以使得一个或多个处理器从来自客户端应用的导向主数据库系统的查询请求，确定来自查询的工作负载能够被切换到辅助数据库系统，并指令客户端应用导向(direct)辅助数据库系统运行查询。

这些方面和其他实施例可以包括以下特征中的一个或多个。被配置为使得一个或多个处理器从来自客户端应用的导向主数据库系统的查询请求，确定来自查询的工作负载能够被切换到辅助数据库系统的编程指令，可以包括编程指令以使得一个或多个处理器确定查询请求中的路由提示指示来自查询的工作负载能够被切换到辅助数据库系统，并确定查询不涉及写入数据。被配置为使得一个或多个处理器指令客户端应用导向辅助数据库系统运行查询的编程指令，可以包括使得一个或多个处理器向客户端应用提供辅助数据库系统的标识的编程指令。

辅助数据库系统可以由在计算机系统上可运行的编程指令来配置，以使得一个或多个处理器响应于接收到来自客户端应用的查询，而从查询中检索复制延迟参数，其中，复制延迟参数指示响应于查询的数据的最大可接受的复制延迟。辅助数据库系统还可以由在计算机系统上可运行的编程指令配置，以检索响应于查询的数据的实际数据滞后，比较实际数据滞后和复制延迟参数，并且当实际数据滞后不超过复制延迟参数时，向客户端应用提供响应于查询的数据。

辅助数据库系统还可以由在计算机系统上可运行的指令来配置，以使得一个或多个处理器在实际数据滞后超过复制延迟参数时向客户端应用提供将查询路由到主数据库系统的指示。辅助数据库系统还可以由在计算机系统上可运行的编程指令来配置，以使得一个或多个处理器在实际数据滞后超过复制延迟参数时，向客户端应用提供响应于查询的数据和回退指示。辅助数据库系统还可以由在计算机系统上可运行的编程指令来配置，以使得一个或多个处理器当实际数据滞后超过复制延迟参数时，向客户端应用提供回退指示，并且不提供响应于查询的数据。

在另一个实施例中，提供了计算机系统中的计算机实现的方法。计算机系统包括主数据库系统和辅助数据库系统。辅助数据库系统被配置为主数据库系统的备份系统，并且能够在主数据库系统中断期间提供至少最小量的主数据库系统的基本功能。该方法包括：在接收查询之前，由主数据库系统接收来自客户端应用的查询请求，由主数据库系统确定查询请求中的路由提示指示来自查询的工作负载能够被切换到辅助数据库系统，确定查询的运行不涉及写入数据，由主数据库系统确定以指令客户端应用将查询路由到辅助数据库系统，并且由主数据库系统指令客户端应用将查询路由到辅助数据库系统。

这些方面和其他实施例可以包括以下特征中的一个或多个。指令客户端应用将查询路由到辅助数据库系统可以包括向客户端应用提供辅助数据库系统的标识。该方法还可以包括在处于热备用操作模式的同时，在辅助数据库系统处接收来自客户端应用的请求数据检索的查询。该方法还可以包括由辅助数据库系统检索来自查询的复制延迟参数，其中复制延迟参数指示响应于查询的数据的最大可接受的复制延迟。该方法还可以包括：由辅助数据库系统检索响应于查询的数据的实际数据滞后；由辅助数据库系统比较实际数据滞后和复制延迟参数；并且当实际数据滞后不超过复制延迟参数时，辅助数据库系统提供响应于查询的数据。该方法还可以包括当实际数据滞后超过复制延迟参数时，由辅助数据库系统向客户端应用提供将查询路由到主数据库系统的指示。该方法还可以包括当所述实际数据滞后超过所述复制延迟参数时，由辅助数据库系统向客户端应用提供响应于查询的数据和回退指示。该方法还可以包括当实际数据滞后超过复制延迟参数时，由辅助数据库系统向客户端应用提供回退指示。

在另一实施例中，提供了一种实施用于执行方法的编程指令的非暂时计算机可读存储介质。该方法包括：在接收查询之前，由主数据库系统接收来自客户端应用的查询请求，由主数据库系统确定查询请求中的路由提示指示来自查询的工作负载能够被切换到辅助数据库系统，其中辅助数据库系统被配置为用于主数据库系统的备份系统，其能够在主数据库系统中断期间提供至少最小量的主数据库系统的基本功能，确定查询的运行不涉及写入数据，由主数据库系统确定指令客户端应用将查询路由到辅助数据库系统，并且由主数据库系统指令客户端应用将查询路由到辅助数据库系统。

这些方面和其他实施例可以包括以下特征中的一个或多个。指令客户端应用将查询路由到辅助数据库系统可以包括向客户端应用提供辅助数据库系统的标识。由非暂时计算机可读存储介质中实施的编程指令提供的方法还可以包括：在处于热备用操作模式的同时，在辅助数据库系统处接收来自客户端应用的请求数据检索的查询。该方法还可以包括由辅助数据库系统检索来自查询的复制延迟参数，其中复制延迟参数指示响应于查询的数据的最大可接受的复制延迟；由辅助数据库系统检索响应于查询的数据的实际数据滞后；由辅助数据库系统比较实际数据滞后和复制延迟参数；并且当实际数据滞后不超过复制延迟参数时，辅助数据库系统提供响应于查询的数据。该方法还可以包括当实际数据滞后超过复制延迟参数时，由辅助数据库系统向客户端应用提供将查询路由到主数据库系统的指示。该方法还可以包括当所述实际数据滞后超过所述复制延迟参数时，由辅助数据库系统向客户端应用提供响应于所述查询的数据和回退指示。

还描述了非暂时性的计算机程序产品(即，物理实施计算机程序的产品)，其存储指令，当指令由一个或多个计算系统的一个或多个数据处理器运行时，使得至少一个数据处理器执行本文的操作。类似地，还描述了可以包括一个或多个数据处理器和耦合到一个或多个数据处理器的存储器的计算机系统。存储器可以临时或持久地存储使得至少一个处理器执行本文所述的一个或多个操作的指令。此外，方法可以由单个计算系统内的或分布在两个或更多个计算系统之间一个或多个数据处理器实现。这样的计算系统可以经由一个或多个连接，包括但不限于通过网络(例如，因特网，无线广域网，本地区域网络，广域网，有线网络等)的连接，经由多个计算系统中的一个或多个之间的直接连接等连接以及可以交换数据和/或命令或其他指令等。

本文所述的主题提供了许多技术优点。作为示例性，本文所描述的主题可以在高工作负载期间为数据库系统提供增加的平均吞吐量，以降低对数据库系统数据的请求可能被排队、缓冲或拒绝的可能性，直到足够的系统资源可用于完成请求。

本文所描述的主题的一个或多个变体的细节在附图和下面的描述中阐述。本文描述的主题的其它特征和优点将从描述和附图以及权利要求书中变得显而易见。

附图说明

图1是示出了与当前主题结合使用的示例性数据库系统的系统图。

图2是示出了与当前主题结合使用的，用于可扩展性和/或可用性目的，可以支持跨多个主机分发服务器组件的示例性数据库系统的系统图。

图3是示出了与当前主题结合使用的索引服务器的架构的图。

图4是示出了与当前主题结合使用的，用于支持主数据库系统和辅助数据库系统之间的负载均衡，用作主数据库系统的热备用的架构的功能流程图。

图5描绘了在HA/DR系统中管理负载均衡的一个示例性解决方案。

图6描绘了在HA/DR系统中管理负载均衡的另一个示例性解决方案。

图7描绘了用于实现基于HINT的路由的示例性体系结构图。

图8描绘了当响应于查询的数据的数据滞后超过复制延迟参数时HA/DR系统的示例性操作。

图9描绘了用于维持辅助系统和客户端应用之间的认证会话的示例性过程的流程图。

各附图中的相似附图标记表示相同的元件。

具体实施方式

本文描述的主题公开了可以在高工作负载期间为数据库系统提供增加的平均吞吐量能力的装置、系统、技术和物品(article)，以降低对数据库系统数据的请求可能被排队、缓冲或拒绝的可能性，直到有足够的系统资源可用来完成请求。在一些示例性中，本文公开的装置、系统、技术和物品利用辅助备份数据库系统来运行查询以减少主数据库系统的工作量。在一些示例性中，本文中公开的系统和方法利用来自应用的查询请求中的提示来识别可能是由辅助数据库系统运行的候选的查询。

图1是示出了可以用于实现当前主题的各方面的数据库系统105的图100。例如，数据库系统105可以是其中所有相关数据保存在主存(main memory)中的内存中数据库，使得可以在没有磁盘I/O的情况下运行读取操作，并且其中需要磁盘存储器以进行任何可持续的改变。数据库系统105可以包括多个服务器，包括例如索引服务器110、名称服务器115和/或应用服务器120中的一个或多个。数据库系统105还可以包括扩展存储服务器125、数据库部署基础设施(DDI)服务器130、数据提供服务器135和/或流集群140中的一个或多个。数据库系统105可以由多个远程客户端145、150经由诸如SQL/MDX(通过索引服务器110)和/或诸如HTTP之类的基于web的协议(通过应用服务器120)之类的不同协议访问。

索引服务器110可以包含用于处理数据的内存中数据存储和引擎。索引服务器110还可以由可以提供各种开发环境和管理工具的远程工具(经由例如SQL查询)来访问。关于索引服务器110的示例实现的附加细节将结合图3的图300来描述和示出。

名称服务器115可以拥有关于数据库系统105的拓扑的信息。在分布式数据库系统中，名称服务器115可以知道各个组件正在运行的位置以及哪个数据位于哪个服务器上。在具有多个数据库容器的数据库系统105中，名称服务器115可以具有关于现有数据库容器的信息，并且它还可以托管系统数据库。例如，名称服务器115可以管理有关现有租户数据库的信息。与单个容器系统中的名称服务器115不同，在具有多个数据库容器的数据库系统105中的名称服务器115不存储诸如分布式数据库中的表的位置的拓扑信息。在多容器数据库系统105中，这样的数据库级拓扑信息可以作为租户数据库的目录的一部分被存储。

应用服务器120可以启用由一个或多个经由诸如HTTP的web协议访问数据库系统105的远程客户端150使用的本地web应用。应用服务器120可以允许开发者编写和运行各种数据库应用，而不需要运行附加的应用服务器。应用服务器120还可以用于运行基于web的工具155用于监管、生命周期管理和开发。其他监管和开发工具160可以例如经由SQL和其他协议直接访问索引服务器110。

扩展存储服务器125可以是动态分层选项的一部分，其可以包括用于在高达PB(petabyte)级及更高级的非常大的数据的基于高性能的基于磁盘的列存储。较不频繁访问的数据(在主存中为其维护索引服务器110不是最佳的)可以被放入扩展存储服务器125。扩展存储服务器125的动态分层允许可以托管非常大的数据库，与传统布置相比，具有降低的所有权成本。

DDI服务器130可以是作为数据库部署基础设施(DDI)的一部分的单独的服务器进程。DDI可以是使用声明性设计时间工件来简化数据库对象的部署的数据库系统105的层。DDI可以例如通过保证基于依赖关系以正确的顺序部署多个对象，并通过实现事务性全做或全不做部署，以确保一致的部署。

数据提供服务器135可以提供企业信息管理和使能例如实时和批量模式的数据提供、实时数据转换、数据质量功能、各种类型的远程源的适配器、以及用于开发附加适配器的适配器SDK的功能。

流集群140允许数据库系统105利用各种类型的数据流(即，数据馈送等)。流集群140允许消耗数据流和复杂事件处理两者。

图2是示出了用于可扩展性和/或可用性目的，可以支持跨多个主机分发服务器组件的数据库系统105的变体的图200。例如，该数据库系统105可以由单个系统ID(SID)识别，并且从可以安装、更新、启动、关闭或整体备份系统管理员的角度来看，其可以被认为是一个单元。数据库系统105的不同组件可以共享相同的元数据，并且如果需要，来自客户端应用230的请求可以被透明地分派到系统中的不同服务器110_1-3、120_1-3。

如图2所示，分布式数据库系统105可以安装在多于一个主机210_1-3上。每个主机210_1-3是可以包括至少一个数据处理器(例如，CPU等)、内存、存储器、网络接口和运行数据库系统105的一部分的操作系统。每个主机210_1-3可以执行数据库实例220_1-3，其包括安装在一个主机210_1-3上的分布式数据库系统105的一组组件。图2显示了具有三个主机的分布式系统，每个主机运行名称服务器110_1-3、索引服务器120_1-3等(为了简化说明省略了其他组件)。

图3是示出了索引服务器110的架构的图300(如上所述，其可以是许多实例之一)。连接和会话管理组件302可以创建和管理客户端应用145的会话和连接。对于每个会话，可以维护一组参数，例如会话变量、自动提交设置或当前事务隔离级别。

可以通过请求处理和运行控制组件310来处理和执行来自客户端应用145的请求。数据库系统105提供丰富的编程能力，用于在数据库系统内运行应用特定的计算。除了SQL、MDX和WIPE之外，数据库系统105可以为不同的用例提供不同的编程语言。SQLScript可用于编写可以在SQL语句中使用的数据库过程和用户定义的函数。L语言是一种命令式语言，其可用于实现可由SQLScript过程调用的操作逻辑以及用于编写用户定义的函数。

一旦建立会话，客户端应用145通常使用SQL语句与索引服务器110通信，SQL语句可以由请求处理和运行控制组件310内的SQL处理器312处理。分析应用可以经由MDX处理器322使用多维查询语言MDX(多维eXpressions)。对于图形数据，应用可以经由GEM处理器316使用GEM(图形查询和操作)，其是图形查询和操作语言。可以使用相同的网络通信协议，通过与客户端应用145的相同连接来发送SQL语句和MDX查询。可以使用内置的SQL系统过程发送GEM语句。

索引服务器110可以包括当建立与客户端应用145的新连接时可以调用的认证组件304。用户可以通过数据库系统105本身进行认证(用户和密码登录)，或者可以将认证委托给外部认证提供者。授权管理器306可以由数据库系统105的其他组件调用，以检查用户是否具有运行所请求的操作所需的特权。

可以在事务的上下文中处理每个语句。新会话可以隐式地分配给新的事务。索引服务器110可以包括协调事务、控制事务隔离、并且跟踪运行和关闭的事务的事务管理器344。当事务被提交或回滚时，事务管理器344可以通知涉及的引擎关于该事件，使得它们可以运行必要的动作。事务管理器344可以提供各种类型的并发控制，并且它可以与持久层346配合以实现原子和持久的事务。

SQL处理器312可以接收来自客户端应用145的传入的SQL请求。数据操作语句可以由SQL处理器312本身运行。可以将其他类型的请求委托给相应的组件。数据定义语句可以被分派到元数据管理器308，事务控制语句可以转发到事务管理器344，规划命令可以被路由到规划引擎318，并且任务相关的命令可以被转发到任务管理器324(其可以是更大的任务网络的一部分)。可以将传入的MDX请求委托给MDX处理器322。过程调用可以转发到过程处理器314，过程处理器314进一步将调用分派到计算引擎326、GEM处理器316、存储库330或DDI代理328。

索引服务器110还可以包括规划引擎318，其允许规划应用(例如财务规划)在数据库层中运行基本规划操作。一个这样的基本操作是在应用过滤器和转换的同时创建一个新版本的数据集作为现有的副本。例如，可以创建新一年的规划数据为上一年的数据的副本。规划操作的另一个示例是基于分布函数将目标值从较高聚合级别分配到低聚合级别的分解操作。

SQL处理器312可以包括可以形成更大平台的一部分的企业性能管理(EPM)运行时组件320，其提供用于在数据库系统105上开发和运行企业性能管理应用的基础设施。虽然规划引擎318可以提供基本的规划操作，但是EPM平台基于由数据库系统105中管理的应用特定的规划模型为完整的规划应用提供了基础。

计算引擎326可以提供实现诸如SQLScript、MDX、GEM、任务和规划操作之类的各种特征的公共基础设施。SQL处理器312、MDX处理器322、规划引擎318、任务管理器324和GEM处理器316可以将不同的编程语言、查询语言和模型转换成由计算引擎326优化和执行的公共表示。计算引擎326可以使用可以部分地基于关系存储332内的数据的临时结果340来实现这些特征。

可以经由元数据管理器组件308来访问元数据。在这种上下文中，元数据可以包括各种对象，诸如关系表、列、视图、索引和过程的定义。所有这些类型的元数据可以存储在用于所有存储(stores)的一个公共数据库目录中。数据库目录可以存储在形成一组关系存储332的一部分的行存储器336中的表中。包括例如支持多版本并发控制的数据库系统105的其他方面也可以用于元数据管理。在分布式系统中，中央元数据跨服务器共享，元数据管理器308可以协调或以其他方式管理这种共享。

关系存储332形成索引服务器110的不同数据管理组件，并且这些关系存储器可以例如将数据存储在主存中。行存储336、列存储338和联合组件334都是关系数据存储器，其可以提供对组织在关系表中的数据的访问。列存储338可以逐列地存储关系表(即，以列为导向的方式等)。列存储338还可以包括文本搜索和分析功能，对空间数据的支持，以及用于图形结构数据的操作和存储。关于图形结构数据，从应用的角度来看，列存储338可以被视为用于图形结构数据的非关系的和模式灵活的内存中数据存储。然而，在技术上这样的图形存储不是单独的物理数据存储。相反，它使用列存储338构建，它可以具有专用的图形API。

行存储器336可以逐行存储关系表。创建表时，创建者可以指定是否应该是基于行或者基于列。可以在两种存储格式之间迁移表。虽然某些SQL扩展仅适用于一种表(例如，列表的“合并”命令)，但标准SQL可用于所有的表。索引服务器110还提供在一个语句(join、sub query、union)中组合两种表的功能。

联合组件334可被视为虚拟关系数据存储。联合组件334可以通过虚拟表提供对外部数据源系统354中的远程数据的访问，虚拟表可以以类似于正常表的方式在SQL查询中使用。

数据库系统105可以包括非关系数据存储器342到索引服务器110中的集成。例如，非关系数据存储器342可以具有表示为C++对象的网络的数据，其可以被持久化到磁盘。非关系数据存储器342可以用于例如对例如在供应链管理中的数据对象的大型网络上操作的优化和规划任务。与行存储器336和列存储器338不同，非关系数据存储器342不使用关系表；相反，对象可以直接存储在由持久层346提供的容器中。固定大小的条目容器可以用于存储一个类的对象。持久化对象可以经由它们的持久化对象ID来加载，其也可以用于持久化对象之间的引用。此外，还支持经由内存中索引进行访问。在这种情况下，对象需要包含搜索键。内存中搜索索引在第一次访问时创建。非关系数据存储器342可以与事务管理器344集成以扩展具有子事务的事务管理，并且还提供不同的锁定协议和多版本并发控制的实现。

扩展存储是可以被使用或以其他方式形成数据库系统105的一部分的另一个关系存储。扩展存储可以例如是优化为管理非常大的表的基于磁盘的列存储，可能不期望将它保持在内存中(如关系存储332那样)。扩展存储可以在与索引服务器110分离的扩展存储服务器125中运行。索引服务器110可以使用联合组件334将SQL语句发送到扩展存储服务器125。

持久层346负责事务的持久性和原子性。持久层346可以确保在重新启动之后数据库系统105恢复到最近的提交状态，并且事务被完全运行或完全撤销。为了以有效的方式实现该目标，持久层346可以使用预写日志、影子分页和保存点的组合。持久层346可以提供用于写入和读取持久化数据的接口，并且还可以包含管理事务日志的记录器组件。事务日志条目可以通过使用日志接口显式编写或使用虚拟文件抽象来隐式编写。

持久层236将数据存储在持久磁盘存储器348中，持久性磁盘存储器348又可以包括可以以页组织的数据卷350和/或事务日志卷352。可以支持不同的页大小，例如4k到16M之间。可以从磁盘存储器348加载数据，并将其以页格式存储到磁盘。对于读写访问，页可以加载到内存中的页缓冲区中。页缓冲区不需要具有最小或最大尺寸，而是，所有未被他用的可用内存都可用于页缓冲区。如果在其他地方需要内存，最近最少使用的页可以从缓存中删除。如果选择要删除修改的页，则页首先需要被持久化到磁盘存储器348。当页和页缓冲器由持久层346管理时，内存中存储(即，关系存储332)可以访问所加载的页中的数据。

在许多应用中，可能需要数据系统来以24/7的时间表来支持操作，并且可能需要数据系统提供商来保证最大停机时间，即系统不能完全支持正在进行中的操作的时间。当需要一个系统来确保达成商定的操作性能水平时，它可能被称为高可用性系统(“HA”)。保证大量持续的正常运行时间，而不需要或很少的停机时间的一个解决方案是维持一个或多个热备用系统。热备用系统或备份系统是在中断导致主操作数据系统的一个或多个功能故障的情况下可以被快速激活的系统。这种中断可能被称为灾难，将数据系统恢复到完全操作的过程可以称为灾难恢复(“DR”)。

热备用系统可以是能够提供由主操作系统提供的所有功能的主操作系统的精确副本，或者热备用系统可以是在恢复主要操作数据系统所需的时间内能够提供最小量的基本功能的系统。恢复数据系统的全部或最小功能(例如将热备用上线)所需的时间称为恢复时间。为了尽量减少恢复时间，从而最大程度地减少停机时间，热备用系统通常处于刚完全运行的状态。例如，可以实现系统架构，其中热备用的所有功能系统都是活动的和可操作的，并且在主操作系统和热备份中所有系统和数据的更改或更新都完全同时发生。在这种情况下，两个系统的唯一区别可能在于，主系统被配置为响应用户请求，而热备份系统不是。在其他热备用系统中，可以禁用一个或多个功能，直到观察到热备用的关键系统正常运行为止，此时剩余的功能可以上线。

在许多应用中，可能需要数据系统来对依赖于由数据系统管理的数据的用户和应用提供迅速的响应。数据系统的供应商和设计人员可能需要保证随时间的平均最小吞吐量或平均最大响应时间。数据系统响应来自用户或应用的请求的速度可能取决于许多因素，但是所有系统在给定时间段内可以处理的请求数量受到限制。当数据系统管理相对大量的数据并且支持相对大量的用户或应用时，在高工作负载期间，可能排队、缓冲或拒绝请求，直到有足够的系统资源可用于完成请求。当这种情况发生时，平均吞吐量下降，平均响应时间上升。这种问题的一个解决方案是，在多个处理系统之间分配工作负载。这被称为负载均衡。

HA系统中的负载均衡的一个缺点是，负载均衡可能需要额外的处理系统，其又具有高成本。通常情况下，某些数据系统支持组织的关键功能，需要额外的系统才能执行负载均衡和HA功能两者，以有效支持连续操作。鉴于DR系统的冗余性质，除非发生灾难，否则热备份系统通常不受干扰。因此，在某些情况下，期望实施并维护具有负载均衡的高可用性/灾难恢复(HA/DR)系统的组合，其包括主操作系统和热备用系统，以及可能的一个或多个三级系统。这样的组合系统允许在主操作系统和热备用系统两者的处理系统之间的工作负载的负载均衡，而不会破坏热备用系统在发生灾难时承担主系统功能的能力。

图4是示出了用于支持在主数据库系统或主系统405a和用作主系统405a的热备用的辅助数据库系统或辅助系统405b之间的负载均衡的架构400的功能流程图。主系统405a和辅助系统405b中的每一个可以是与图1中所描绘的数据库系统105类似的单个实例系统，或者每个可以是图2中所描绘的数据库系统105的分布式变体。这种架构400可能在高可用性数据系统或灾难恢复系统或组合HA/DR系统中是有用的。

主系统405a和辅助系统405b中的每一个可以包括负载均衡功能。这种负载均衡功能可以例如被包含在不同的负载均衡服务器470a或470b内。但是，这样的负载均衡功能可以由任何合适的处理系统来管理。例如，主系统的应用服务器120还可以管理发出到主系统405a的应用服务器的请求的负载均衡，根据需要向辅助系统405b发送请求以维护良好分布的工作负载。

如图4所描绘的，主系统405a和辅助系统405b中的每一个包括负载均衡服务器470a和470b，其分别接收来自用户应用的导向主系统405a或辅助系统405b的请求。这样的请求可以来自管理工具460或基于web的工具450，或任何其他用户应用。在接收到请求时，负载均衡服务器，例如470a，确定如何分配工作量。如所描绘的，负载均衡服务器470a将来自管理工具460的SQL请求465路由到主系统405a的索引服务器110，同时将来自基于web的工具450的HTTP请求455路由到辅助系统405b的应用服务器120。

在主系统405a和辅助系统405b之间的资源的负载均衡可能引起许多复杂的问题。例如，如果请求455、465中的任一个需要写入一个或多个数据表或修改数据表，则两个系统405a，405b将分歧。在主系统405a和辅助系统405b之间分发写入请求的许多实例之后，两个系统将是显著不同的，并且可能不可用。在另一示例性中，应用请求，例如465，可以执行随后是例如455的读取事务的写入事务。如果将写入请求分配给主系统405a，则根据是由主系统405a还是由辅助系统405b执行后续读取事务，读取请求将获得不同的结果。

通过将主数据系统的工作负载的一部分分配到热备用或备份系统的HA/DR系统中的负载均衡必须以不干扰备份系统的主要目的的方式进行，这是为了通过使能快速有效地恢复操作来大幅消除高可用性系统中的停机时间。换句话说，通常情况下，负载均衡不能破坏热备份。鉴于此主要目的，任何能够在主系统和备份系统之间实现负载均衡工作负载的解决方案必须将备份系统保持在与主系统相同或几乎相同的状态。这种解决方案还应该避免或禁止可能导致备份系统状态与主系统状态发生重大分歧的任何动作。以这种方式，在由于灾难导致主系统部分或全部故障的情况下，备份系统可以容错转移到主系统模式，对客户端应用影响最小或没有影响。

图5描绘了在HA/DR系统500中管理负载均衡的一个示例性解决方案。HA/DR系统500包括主系统505和辅助系统510，并且能够在主系统505和辅助系统510之间进行负载均衡，而不会干扰辅助系统510的热备用功能。主系统505和辅助系统510中的每一个可以是类似于图1中所描述的数据库系统105的单个的实例数据库系统，或者如图2所描绘的数据库系统105的分布式变体。此外，主系统505和辅助系统510中的每一个可以包括归属于索引服务器110、300、名称服务器115、应用服务器120、扩展存储服务器125、DDI服务器130、数据提供服务器135以及流集群140的更少、更多或全部的功能。但是为了简化说明，通过仅区分每个相应系统505、510的处理控制555、560和持久层565、570来简化HA/DR系统500以突出某些功能。

客户端的集合可以各自维护与主系统505和辅助系统525两者的开放连接。例如，客户端515维持到主系统505的读/写连接520以及到辅助系统510的只读连接525。或者，客户端515可以维护与主系统505和辅助系统510中的每一个的读/写连接，而，辅助系统510本身中的过程在它处于备份模式时禁止在辅助系统上运行需要写入事务的任何请求。由在客户端515运行的客户端应用所需的工作负载的负载均衡管理可以由客户端515应用本身管理。或者，客户端515应用可以向主系统505提交查询请求。然后，在处理器545上运行的控制负载均衡过程的过程555然后可以确定应该运行该查询的位置并且向客户端515回复用于识别客户端515应该将查询发往的系统的指令。

主系统505可以包括内存中数据库，其中基本上所有活动使用的数据可以在主存535中保持和维护，使得可以在没有需要访问磁盘存储的磁盘I/O的情况下运行操作。处理控制555内的应用的活动操作可能导致处理器545将数据读取和写入主存535或持久层565中的磁盘。处理控制555应用还使处理器545生成用于捕获在数据库上的数据事务的事务日志，处理器545然后将数据持久化到日志卷585。因此，基本上所有活动使用的数据可能驻留在存储器中，因此处理控制555可以主要与保存在主存中的数据进行交互，而仅使用数据卷575来检索和写入较少使用的数据。处理控制555中的附加处理可由处理器545运行，以确保内存中数据在持久层565中被持久化，使得数据在重新启动或恢复时可用。

主系统505可以是用于提供为支持组织的24/7操作所需的各种功能的主要操作系统。辅助系统510可以是热备用的，准备好以最少的恢复时间上线，以便最小化停机时间。辅助系统510可以是与主系统505相同的物理系统，并且可以以基本相同的方式配置，以便使辅助系统510能够提供与主系统505全部相同的功能。例如，处理控制560可以包括与处理控制555全部相同的应用和功能，并且持久层570可以包括以与数据卷575和日志卷585相同的方式配置的数据卷580和日志卷590。辅助系统510还可以包括主要在主存540中保存和维持的内存中数据。

主系统505和辅助系统510的不同之处在于，来自客户端515或其他的需要写入事务的所有请求仅在主系统505中运行。主系统505和辅助系统510进一步不同之处在于，所有到持久性对象的写入事务都被辅助系统510禁止。为了将从数据或底层架构的改变从主系统505传播到辅助系统510，处理器545还将事务日志530直接复制到辅助系统的过程控制560。过程控制560包括，使处理器550然后重放从主系统505复制的事务日志的一个或多个应用，从而在辅助系统510处重放事务。当事务日志被重放时，在主系统中运行的各种事务反映在辅助系统510中。为了确保HA功能和负载均衡功能两者，在辅助系统上的事务日志的重放将数据放置在主存540中，并且还将在主系统中提交的任何数据都持久化到存储层570以由数据卷580存储。在辅助系统上重放事务日志510还可能导致事务日志在日志卷590中被持久化。

可以以不同的方式复制事务日志。在其中将备用系统维持在与主系统相同的状态是一个重要因素的情况下，可以同步复制日志，这意味着主系统将不会在辅助系统成功响应日志复制之前提交事务。人们理解，这将会降低主要系统的性能。相反，当主系统的性能是优先因素时，可以异步地复制日志，在这种情况下，主操作继续提交事务而不等待响应。可以在这两种情况之间进行各种权衡，以确保合适的性能水平，同时确保关键数据的复制。

从上面的详细描述可以理解，诸如辅助系统510的待机模式中的这种辅助系统只能与其最近重放的事务日志一样新。只有在主系统505中的事务运行之后，事务日志才在辅助系统510被复制和重放。因此，辅助系统510总是稍微落在相关联的主系统515之后。而且，不能保证为了负载均衡路由到主系统的查询将在特定事务日志重放之前、期间或之后运行。因此，主系统505的状态和辅助系统的状态将很少相同。但是，通过解决某些问题，辅助系统510可以保持在与主系统505基本上接近于相同状态的状态，使得许多操作所需的工作量可以由辅助系统510支持。这些只是为了在HA/DR架构中提供稳健的负载均衡实现，其中热备份系统也承载一部分工作负载的几个要解决的问题。现在介绍图5中所描绘的由负载均衡解决方案引起的问题的一个或多个解决方案。

图6描绘了用于管理HA/DR系统600中的负载均衡的另一示例性解决方案。HA/DR系统600包括主数据库系统605、辅助数据库系统610以及用于从主系统605到辅助系统610传播事务日志和数据或底层模式的改变的通信通道655。HA/DR系统600能够在主系统605和辅助系统610之间进行负载均衡，而不会干扰辅助系统610的热备用功能。主系统605和辅助系统610中的每一个可以是与图1中所描绘的数据库系统105相似的单一实例数据库系统，或如图2中所描绘的数据库系统105的分布式变体。此外，主系统605和辅助系统610中的每一个可以包括归属于主系统505和辅助系统510、索引服务器110、300、名称服务器115、应用服务器120、扩展存储服务器125、D DI服务器130，数据提供服务器135和流群集140的更少、更多或全部的功能。但是，为了简化说明，通过仅区分每个相应的系统605、610的索引服务器615、620和会话服务625、630来简化HA/DR系统600，以突出某些功能。此外，索引服务器615、620中的每一个可以包括归属于索引服务器110、300的较少、更多或全部的的功能，并且会话服务625、630中的每一个可以包括归属于连接和会话管理组件302的更少、更多或全部的功能。

客户端应用634可以调用一个或多个客户端库635来建立与主服务器系统605和第二服务器系统610的连接。结果，一个或多个客户端库635可以各自保持与主系统605和辅助系统610的开放连接。例如，客户端库635可以维持对主系统605的读/写连接645和辅助系统610的只读连接650。或者，客户端库635可以维持与主系统605和辅助系统610中的每一个的读/写连接，而辅助系统610本身中的过程在其处于备份模式时禁止运行需要在辅助系统上写入事务的任何请求。

在本示例中，客户端应用634所需的工作负载的负载均衡的管理由客户端库635和主系统605两者管理。客户端库635可以向主系统605的索引服务器615中的会话服务625提交查询请求。客户端应用634可以通过提示在查询请求中指示对于客户端应用634在辅助系统610处运行查询是可接受的(或优选的)。在主系统605中的索引服务器615中的处理器上运行的负载均衡处理可以确定查询应该被运行的位置，并向客户端615回复识别客户端615应该将查询发往的系统的指令。在本示例中，索引服务器615确定应在辅助系统610处运行查询，并且指令客户端库635向辅助系统610发出查询。该提示可以向主系统605指示如果可能，客户端库635的优选是在辅助系统中运行查询。

图7描绘了在HA/DR系统700中管理负载均衡的另一示例性解决方案。HA/DR系统700包括主数据库系统705和辅助数据库系统710，并且能够在主系统705和辅助系统710之间进行负载均衡，而不会干扰辅助系统710的热备用功能。主系统705和辅助系统710中的每一个可以是与图1中所描绘的数据库系统105相似的单个实例数据库系统，或如图2所描绘的数据库系统105的分布式变体。

此外，主系统705和辅助系统710中的每一个可以包括归属于主系统605、505和辅助系统610、510、索引服务器110、300、名称服务器115、应用服务器120、扩展存储服务器125、DDI服务器130、数据提供服务器135和流集群140的更少、更多或全部的功能。但是，为了简化说明，通过仅区分每个相应的系统705、710的索引服务器715、720和系统705的会话和连接服务725、SQL优化器765和名称服务器775来简化HA/DR系统700，以突出某些功能。此外，索引服务器715、720中的每一个可以包括归属于索引服务器110、300的更少、更多的或全部的的功能，会话和连接服务725可以包括归属于连接和会话管理组件302、625的更少、更多或全部的功能，SQL优化器765可以包括归属于SQL处理器312的更少、更多或全部的功能，以及名称服务器775可以包括归属于名称服务器115的更少、更多或全部的功能。

客户端应用734可以调用一个或多个客户端库735来建立与主服务器系统705和第二服务器系统710的连接。结果，一个或多个客户端库735可以各自保持与主系统705和辅助系统710的开放连接。例如，客户端库735可以维持到主系统705的读/写连接745和到辅助系统710的只读连接750。可替换地，客户端库735可以维持与主系统705和辅助系统710中的每一个的读/写连接，辅助系统710本身中的过程在当它处于备份模式时禁止运行需要在辅助系统写入事务的任何请求。

在本示例中，客户端应用734所需的工作负载的负载均衡的管理由客户端库735和主系统705两者管理。客户端库735可以向主系统705的索引服务器715中的会话服务725提交查询请求。客户端应用734可以通过提示在查询请求中指示对于客户端应用734在辅助系统710处运行查询是可接受的(或优选的)。SQL优化器765可以解析查询请求并且识别关于在辅助系统710处的查询运行的提示。在主系统705中的索引服务器715内的处理器上运行的负载均衡过程然后可以确定应该在哪里运行查询并且回复客户端715标识客户端715应该将查询发往的系统的指令。

如果确定应该在辅助系统710处运行查询，则索引服务器715可以经由名称服务器775检索辅助系统的公共名称，并且在回复中将辅助系统的公共名称提供给客户端库735。客户端库735可以利用拓扑高速缓存来存储用于数据的位置信息，并且可能需要扩展其拓扑高速缓存以使得知道辅助系统710。

在本示例中，索引服务器715确定应在辅助系统710处运行查询，并且指令客户端库735向辅助系统710发出查询。该提示可以向主系统705指示如果可能的话，应用734优选在辅助系统中运行查询。

当在辅助站点执行查询时，辅助站点可以返回旧数据，例如，当延迟了增量日志的重放时。客户端应用734可以将数据的复制延迟参数(例如，以秒为单位的时间)指定为可接受的滞后时间，其中滞后时间是在主系统上提交写入事务时和在辅助系统上重放时的差异，并可以通过应用读取。只有当实际数据滞后不超过复制延迟参数时，辅助系统710才响应于查询向客户端库735提供数据。可替换地，当实际数据滞后超过复制延迟参数时，辅助系统710可以指令客户端库735将查询路由到主数据库系统。或者，当实际数据滞后超过复制延迟参数时，辅助系统710可以将响应于查询的数据和回退指示两者提供给客户端应用。

图8描绘了当响应于查询的数据的数据滞后超过复制延迟参数时HA/DR系统800的示例性操作。HA/DR系统800包括主数据库系统805和辅助数据库系统810。主系统805和辅助系统810中的每一个可以是类似于图1中所描绘的数据库系统105的单个实例数据库系统，或如图2中所描绘的数据库系统105的分布式变体。此外，主系统805和辅助系统810中的每一个可以包括归属于主系统705、605、505和辅助系统710、610、510、索引服务器110、300、名称服务器115、应用服务器120、扩展存储服务器125、DDI服务器130、数据提供服务器135和流群集140的更少、更多或全部的功能。但是，为了简化说明，通过仅区分每个相应系统805、810的索引服务器815、820以及会话和连接服务825、事务管理器或持久层870以及查询规划引擎880来简化HA/DR系统800。此外，索引服务器815、820中的每一个可以包括归属于索引服务器110、300、615、715的更少、更多或全部的功能；会话和连接服务825可以包括归属于连接和会话管理组件302、625、725的更少、更多或全部的功能；事务管理器或持久层870可以包括归属于事务管理器344和/或持久层345的更少、更多或全部的功能，并且查询规划引擎880可以包括归属于查询规划引擎318的更少、更多的或全部的功能。

在接收到将查询路由到辅助系统810的指令之后，由客户端应用834调用的客户端库835指令辅助系统810运行路由后的查询语句(操作802)。查询规划引擎880从查询中检索指定的滞后(即，复制延迟参数)(操作804)。事务管理器或持久层870检索响应于查询的数据的当前数据滞后(操作806)。会话和连接服务825将指定的滞后与当前数据滞后进行比较，并且决定是否应该向客户端库835提供响应于查询的数据(操作808)。当当前数据滞后超过规定的滞后时，辅助系统将通知客户端库(操作812)。当接收到当前数据滞后超过指定滞后的通知时，客户端库835将查询重新路由到主系统805运行(操作814)。

图9描绘了用于维护辅助系统和客户端库之间的认证会话的示例性过程的流程图。在本示例中，客户端应用901可以调用一个或多个客户端库902来建立与主服务器系统904和第二服务器系统904的连接。结果，客户端库具有与主系统904和辅助系统906的开放认证连接。会话上下文改变由主系统904中的会话管理器908检测。主系统904中的会话管理器908向应用902通知会话上下文改变，并将已经改变的键/值发送到库902，其可以在会话上下文高速缓存910中存储更改值。当工作负载被切换并且查询被路由到辅助系统906时，客户端库902将缓存的会话变量与改变的键/值发送到辅助系统906中的会话管理器912。这允许辅助系统906更新其会话上下文并且维护与客户端库902的认证会话。

本文描述的主题的一个或多个方面或特征可以在数字电子电路、集成电路、特别设计的专用集成电路(ASIC)、现场可编程门阵列(FPGA)计算机硬件、固件、软件、和/或其组合中实现。这些各个方面或特征可以包括在可编程系统上可执行和/或可解释的一个或多个计算机程序中的实现，可编程系统包括至少一个可以是特殊或通用目的的被耦合以从存储系统接收数据和指令，并向存储系统发送数据和指令的可编程处理器，至少一个输入设备和至少一个输出设备。可编程系统或计算系统可以包括客户端和服务器。客户端和服务器通常彼此远离，通常通过通信网络进行交互。客户端和服务器之间的关系是由于在相应的计算机上运行并且彼此之间具有客户端-服务器关系的计算机程序而产生的。

也可以称为程序、软件、软件应用、应用、组件或代码的这些计算机程序包括用于可编程处理器的机器指令，并且可以以高级过程语言、面向对象的编程语言、功能编程语言、逻辑编程语言和/或汇编/机器语言实现。如本文所使用的，术语“机器可读介质”是指用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、装置和/或设备，例如磁盘、光盘、存储器和可编程逻辑器件(PLD)，包括接收机器指令作为机器可读信号的机器可读介质。术语“机器可读信号”是指用于向可编程处理器提供机器指令和/或数据的任何信号。机器可读介质可以非暂时地存储这样的机器指令，例如非瞬态固态存储器或磁性硬盘驱动器或任何等效的存储介质。机器可读介质可以以暂时方式替代地或另外地存储这样的机器指令，例如像与一个或多个物理处理器核相关联的处理器高速缓存或其他随机存取存储器一样。

为了提供与用户的交互，本文所述的主题可以在具有用于向用户显示信息的显示设备(例如，CRT(阴极射线管)或LCD(液晶显示器)监视器)以及通过其用户可以计算机提供输入的键盘和指示设备(例如，鼠标或轨迹球)和/或触摸屏的计算机上实现。也可以使用其他类型的设备来提供与用户的交互；例如，提供给用户的反馈可以是任何形式的感觉反馈(例如，视觉反馈、听觉反馈或触觉反馈)；并且来自用户的输入可以以任何形式来接收，包括声音、语音或触觉输入。

在上述的描述和权利要求中，可以出现诸如“至少一个”或“一个或多个”中的短语，随后是元素或特征的连接列表。术语“和/或”也可以出现在两个或多个元件或特征的列表中。除非在其使用的上下文中隐含地或明确地相冲突，否则这样的短语旨在表示所列出的元件或特征中的个别的任何一个或任何所列举的元件或特征以及任何其它所述的元件或特征的组合。例如，短语“A和B中的至少一个”、“A和B中的一个或多个”和“A和/或B”每个旨在表示“仅A、仅B或A和B一起”。类似的解释也适用于包括三个或更多项目的列表。例如，短语“A、B和C中的至少一个”、“A、B和C中的一个或多个”以及“A、B和/或C”每个旨在表示“仅A、仅B、仅C、A和B一起、A和C一起、B和C一起、或A和B和C在一起”。此外，在上述和权利要求中使用术语“基于”意思是“至少部分地基于”，没有详述的特征或元素也是允许的。

根据所需的配置，本文所述的主题可以体现在系统、装置、方法和/或物品中。在前面的描述中阐述的实现不代表与本文所描述的主题一致的所有实现。相反，它们仅仅是与所述主题相关的方面一致的一些示例。虽然上面已经详细描述了一些变型，但是可以进行其他修改或添加。特别地，除了这里阐述的那些之外，还可以提供进一步的特征和/或变化。例如，上述实现可以针对上述公开的特征的各种组合和子组合和/或上述公开的几个更多的特征的组合和子组合。此外，在附图中描绘的和/或本文描述的逻辑流程并不一定需要所显示的特定顺序或顺序的顺序来实现期望的结果。其他实现可以在所附权利要求的范围内。