对复制型数据库的访问进行负载平衡的制作方法
【技术领域】
[0001]本发明设计跨管理分布式副本的系统提供服务，并且更具体地，涉及用于管理到这些系统的连接和这些系统中的负载平衡的全局数据服务框架，以及涉及跨这些副本管理服务的故障转移。
【背景技术】
[0002]由于各种原因，许多商业维护相同数据的多个拷贝。例如，国际化公司可能跨位于世界各地的许多数据库复制关键数据。维护相同数据的多个副本的原因包括，但不限于:
[0003]商业连续性和灾难恢复；
[0004]为本地客户的性能优化；
[0005]内容本地化和高速缓存；
[0006]遵守当地法律 '及
[0007]集成通过并购获得的数据中心。
[0008]虽然维护相同数据的若干个副本可以提供多种好处，但是如果不能有效地管理，这也会成为麻烦。因此，已经开发了提供“数据库服务”并允许跨属于同一集群网格的数据库服务器实例进行服务级别工作负载管理的数据库系统。
[0009]遗憾的是，跨属于集群网格的数据库服务器实例管理工作负载没有考虑在那个网格之外维护的潜在的大量副本。分布式环境通常比集群支持更高程度的异质性。例如，在分布式环境中，跨其维护副本的各种系统可以具有不同的硬件系统架构、不同的操作系统、甚至不同类型的数据库系统。与集群不同，分布式环境中的数据库不能访问用于保持状态的共享存储。因此，通过其可以高效地管理相同数据的多个分布式副本的机制将是所期望的。
[0010]在本节中描述的方法是可以实行的方法，但不一定是先前已被构想或实行的方法。因此，除非另外指出，否则不应当假设本节中描述的任何方法仅仅因为它们被包括在本节中就有资格作为现有技术。
【附图说明】
[0011]附图中:
[0012]图1是根据本发明实施例的由全局数据服务框架管理的分布式复制系统的框图；
[0013]图2是根据本发明实施例的其中各种数据库系统被分成区域的图1的分布式复制系统的框图；
[0014]图3是根据本发明实施例的说明如何响应连接请求的流程图；以及
[0015]图4是其上可以实现本发明实施例的计算机系统的框图。
【具体实施方式】
[0016]在以下描述中，为了解释的目的，阐述了众多具体的细节，以便提供对本发明的透彻理解。但是，很显然，也可以在没有这些具体细节的情况下实践本发明。在其它情况下，众所周知的结构和设备以框图形式示出，以避免不必要地混淆本发明。
[0017]总体概述
[0018]本文描述的技术允许用户定义跨多个复制型数据库提供的全局服务。数据库客户端连接到全局服务并使用该全局服务，就像它们当前在单个数据库上使用一般服务那样。在接收到连接请求时，在本文被统称为全局数据服务框架(GDS框架)的一组组件自动地选择连接客户端的最佳数据库服务器实例。一旦那些连接被建立，客户端就至少部分地基于由GDS框架发送给客户端的建议消息确定向它们连接到的那些数据库服务器实例中的哪个数据库服务器实例发送请求。
[0019]根据一种实施例，⑶S框架基于从数据库自身推送的信息生成负载/性能信息。这与必须查看外部可测量行为的外部箱不同。因此，不是客户端通过查看数据库的外部行为试图推断它们应该做什么，而是数据库通过GDS框架告诉客户端它们应该做什么。因此，GDS可以是更主动和预测性的。例如，如果数据库将要达到过载、将要启动大的批处理作业、或者如果数据库将要经历计划中的关闭，则GSM可以建议客户端将工作从数据库中移出。
[0020]在一种实现中，GDS框架提供了单一、中央的工具来添加、去除、修改和重新定位全局服务并且查看它们在特定实例上的状态。该工具也可以用于配置⑶S框架和管理其组件。
[0021]很明显，GDS框架可以利用异构数据库环境来实现。例如，由GDS框架使用的数据库集合(本文统称为“数据库云”)可以包括通过任何类型的复制技术链接在一起的来自任何数量的供应商的集群数据库和来自任何数量的供应商的单个实例数据库。此外，可以跨在不同硬件/软件平台上运行的数据库建立GDS框架。
[0022]根据一种实施例，虽然GSM提供了负载平衡/故障转移功能，但是该GSM只在连接建立期间和在告诉客户端连接池具有的连接的相对“适合度”时才参与其中。在这种实施例中，GSM不在请求路径中，因此每次客户端-服务器的往返(SQL调用)并不具有额外的一跳(hop)ο
[0023]示例性分布式复制系统
[0024]参考图1，它是分布式复制系统的框图。具体而言，图1说明了包括四个数据库系统130、131、132和134的数据库云。数据库系统130是集群的数据库系统，其中多个数据库实例102、104和106访问同一共享的存储122。另一方面，数据库系统131、133和134是分别包括数据库服务器实例107、108和110的单实例数据库系统。数据库服务器实例107管理存储123上的数据。数据库服务器实例108管理存储124上的数据。数据库服务器实例110管理存储126上的数据。
[0025]在示出的实施例中，各种数据集在数据库系统130中被复制。具体而言，数据集A的副本由所有四个系统130、131、132和134进行管理。数据集B的副本由系统130、131和132进行管理。数据集C的副本由系统132和134进行管理。最后，数据集D由系统130唯一地进行管理。
[0026]因为数据库服务器实例102、104和106属于同一集群，因此所有的数据库服务实例102、104和106都能够直接访问在存储122上存储的数据集A、B和D的副本。但是，数据库服务器实例102、104和106不能直接访问由数据库服务器实例107、108和110管理的数据，因为数据库服务器实例107、108和110不属于系统130的集群。类似地，数据库服务器实例107只能直接访问系统131中的副本。数据库服务器实例108只能直接访问系统132中的副本。数据库服务器实例110只能直接访问系统134中的副本。
[0027]在示出的实施例中，五个客户端152、154、156、158和160都与系统130相关联。客户端160还与系统131相关联，其说明客户端和系统之间不必是一对一的关系。系统132与一个客户端162相关联，并且系统134与两个客户端164和166相关联。如将在以下更详细描述的，不是向与它们相关联的系统内的数据库服务器实例直接发连接请求，而是客户端配置为向全局数据服务框架100发连接请求。GDS框架100又确定与哪个系统中的哪个数据库服务器实例连接每个客户端。
[0028]此外，GDS框架100向客户端发送建议消息，以向客户端指示客户端应该将用于任何给定全局服务的请求提交给哪个数据库服务器实例。例如，在一种实施例中，GDS框架100发送建议消息，该建议消息包含指定用于特定全局服务的要发送到特定数据库服务器实例的请求比例的百分比集合。这种建议消息可以以规则的时间间隔和/或响应于要求客户端请求要被适当地重新分布的实例负载变化而产生。随着时间的推移，用于给定服务的那些百分比会基于各种因素改变，诸如每个系统当前正经受的工作负载。响应于这种改变，GDS框架100将改变在发送给客户端的建议消息中的为该服务推荐的那个或那些数据库服务器实例和/或百分比。
[0029]很明显，系统130、131、132和134可以在相同的位置、在靠近彼此的不同位置、跨国家分布或跨世界分布。本文描述的技术可以与其中数据集的副本分布在不同数据库系统中的任何系统工作，而与那些数据库系统彼此间的地理接近程度无关。但是，如将在以下更详细描述的，每个数据库系统的位置可能是全局数据服务框架100确定哪个数据库服务器实例应该服务于任何给定请求的因素。
[0030]全局服务管理器和区域
[0031]在一种实施例中，全局服务框架100利用一组全局服务管理器(GSMS)来实现，如在图2中所示出的。全局服务管理器中的一个或多个管理器对于由全局服务框架100管理的每个数据库系统是可用的。逻辑上，全局服务管理器与它们所交互的数据库服务器系统相分离。因此，全局服务管理器可以与数据库服务器实例在同一机器上执行，或者可以在与执行同全局服务管理器交互的数据库服务器实例的机器不同的机器上执行。
[0032]根据一种实施例，全局服务管理器被分组成区域。每个区域可以包括一个或多个全局服务管理器，并且与和全局服务框架100交互的数据库系统中的一个或多个数据库系统相关联。为了说明的目的，将假设全局服务管理器202和204属于区域X，其包括数据库系统130和131。全局服务管理器206和208属于区域Y，其包括数据库系统132，并且全局服务管理器210属于区域Z，其包括系统134。
[0033]在这个例子中，区域X与两个数据库系统相关联，并且区域Y和Z各自与单个的数据库系统相关联。但是，如上面提到的，每个区域可以与任何数量的数据库系统相关联。在一种实施例中，当数据库服务器彼此具有某种形式的密切关系(affinity)时，这些数据库系统与同一区域相关联。例如，当数据库系统地理上彼此靠近，或者当它们经高速互连彼此连接时，它们可以与同一区域相关联。优选地，在每个区域中被分组在一起的数据库系统是那些从数据库系统分配到的区域中的客户端的角度看具有相似延时的系统。因此，系统130和131从客户端152至160的角度看具有相似的延时。
[0034]驻留在与给定客户端在同一区域中的全局服务管理器被称为相对于那个客户端的“本地全局服务管理器”。例如，参考图2，全局服务管理器202和204驻留在区域X中，并因此对于客户端152、154、156、158和160以及数据库服务器实例102、104、106和107是本地的。全局服务管理器206和208驻留在区域Y中，并对客户端162和数据库服务器实例108是本地的。全局服务管理器210驻留在区域Z中，并对客户端164和166及数据库服务器实例110是本地的。
[0035]每个全局服务管理器充当由客户端使用以连接到全局服务的区域监听者。根据一种实施例，客户端连接请求在所有的区域GSM中是随机分布的。每个GMS还测量其自己的区域和所有其它区域之间的网络延时和带宽，并且与其它区域中的GSM交换这个信息。
[0036]如将在下文更详细描述的，每个GSM通过将客户端连接导向到最合适的数据库实例来执行连接负载平衡。实例是基于GSM从所有实例接收到的度量、估计的网络延时/带宽以及服务的区域密切关系确定的。
[0037]根据另一个方面，每个GSM通过启动、停止以及在实例和数据库之间移动全局服务来管理全局服务的基数(cardinality)和故障转移。GSM也可以向客户端发送建议消息，来推荐客户端应该使用连接池中每个连接的程度以获得特定服务。
[0038]根据一种实施例，每个GSM还监视数据库实例，当实例、数据库或网络不能用时生成并发布事件。GSM还根据它从云中所有实例接收到的性能度量为本地区域中的客户端生成和发布事件，并将它们与估计的网络延时集成。当区域中所有的GSM都停用时，来自伙伴(buddy)区域的GSM接管该区域的事件生成。好友区域将在以下进行更详细的描述。
[0039]数据库池
[0040]在一种实现中，在数据库云中包括的数据库可以被分组为数据库池。数据库池是数据库云中的数据库集合，其提供了唯一的全局服务集合并且属于特定管理域，例如HR