技术领域
[0001] 本发明实施例涉及计算机技术领域，尤其涉及一种数据库服务器的资源配置方法、装置、计算设备及计算机可读存储介质。
相关背景技术
[0002] 为了提高数据库服务器的资源利用率，目前都是采用在单个数据库服务器上部署多个数据库的方案。数据库云平台管理多个数据库服务器，用户向数据库云平台申请一定资源的数据库系统，数据库云平台根据用户的申请将任意数据库服务器的相应资源的数据库分配给用户。数据库系统是用户申请的一个或多个数据库的统称，例如数据库系统可以仅包括一个数据库，或者包括一个主数据库和一个备数据库，或者包括一个主数据库和多个备数据库。备数据库是为了保障数据安全和业务连续性，例如当主数据库所在的数据库服务器故障时，备数据库立即接管主数据库上的业务，以此来缩短数据库系统的不可用时间，满足高可用的需求。
[0003] 图1a示出了一种可能的应用场景，数据库云平台管理多个数据库服务器(如图中所示的数据库服务器100、数据库服务器200和数据库服务器300)，为了方便描述，假定每个数据库服务器具有48核的中央处理器(Central Processing Unit，CPU)资源。用户A对自身所需的CPU资源进行评估后，向数据库云平台申请数据库系统，该数据库系统包括CPU资源为8核的主数据库和CPU资源为8核的备数据库。数据库云平台确定数据库服务器100能够满足8核的CPU资源的请求时，在数据库服务器100中为用户A部署一个主数据库；确定数据库服务器200能够满足8核的CPU资源的请求时，在数据库服务器200中为用户A部署一个备数据库(为了保证高可用，主数据库和备数据库一般不位于同一个数据库服务器)。至此，用户A申请的数据库系统部署完毕。图1b中示意出了一种可能的数据库服务器100的数据库部署情况，为了简化描述，假定数据库服务器100具有48核的CPU资源，各用户均向数据库云平台申请8核的CPU资源的数据库。数据库服务器100为用户A部署一个CPU资源为8核的主数据库；为用户B部署一个CPU资源为8核的主数据库；为用户C部署一个CPU资源为8核的主数据库；为用户D部署一个CPU资源为8核的备数据库；为用户E部署一个CPU资源为8核的备数据库；一般来说，数据库服务器会预留20％左右的资源用于给当前的各数据库扩容使用，因此剩余8核的CPU资源不再进行分配。
[0004] 然而上述方法不可避免地会造成数据库服务器的资源利用率低。主要体现在：1、用户不能准确预估实际的资源使用需求，为了保证能够满足高峰时期的数据库使用需求，在申请数据库系统时，倾向于申请更高规格的数据库系统，造成数据库服务器的资源浪费。例如，对于用户A，大部分时间使用4核的CPU资源的数据库即可满足需求，极个别高峰时间需要8核的CPU资源，因此用户A会向云数据库平台申请8核的CPU资源的数据库。2、大多数用户对数据安全和业务连续性保障都有很高的要求，因此会额外申请一个或多个备数据库。
当主数据库发生故障或出现其他情况时，切换为备数据库提供对外服务。为了保证切换后备数据库提供的能力不降级，即便备数据库还尚未提供对外服务，备数据库也需要配置和主数据库相同的资源，进一步造成了数据库服务器的资源浪费。例如图1b中，数据库服务器
100中可能当前仅有3个主数据库提供对外服务，其余的2个备数据库并未提供对外服务，但仍然占用着相当数量的CPU资源。
具体实施方式
[0079] 为使本申请的目的、实施方式和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。
[0080] 基于本申请描述的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请所附权利要求保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。
[0081] 需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
[0082] 本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明(Unless otherwise indicated)。应该理解这样使用的用语在适当情况下可以互换，例如能够根据本申请实施例图示或描述中给出那些以外的顺序实施。
[0083] 此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
[0084] 本发明实施例提供以下两种数据库服务器的资源配置方法，用以提高数据库服务器的资源利用率。
[0085] 方式1、预测法：通过学习任一用户的数据库资源的历史使用规律对该用户未来时间段对数据库资源的使用需求进行预测，根据预测结果对该用户的数据库资源进行动态扩缩容。例如预测出用户A下一个小时的CPU资源使用需求是4核，因此在下一个小时内将数据库服务器100中为用户A分配的主数据库的CPU资源调整为4核，将数据库服务器200中为用户A分配的备数据库的CPU资源也调整为4核。
[0086] 方式2、监控法：通过采集当前时间段任一数据库服务器的各数据库的监控指标，将各数据库的监控指标与同业务类型的其他数据库服务器的数据库的各监控指标进行比较，根据比较结果确定下一时间段是否对该数据库服务器的各数据库的资源进行动态扩缩容。例如，根据当前时间段的比较结果将下一时间段的数据库服务器100中为用户A分配的主数据库的CPU资源调整为4核，将下一时间段的数据库服务器200中为用户A分配的备数据库的CPU资源也调整为4核。
[0087] 采用预测法进行动态扩缩容的方式的缺点是，预测的准确性难以保证。尤其是营销活动、秒杀等随机出现并且短时间需要大量资源的场景中，预测法很难根据规律来正确预测资源需求，无法实现提前进行扩容。采用监控法进行动态扩缩容的方式的缺点是，实时性差。通过采集当前时间段的监控指标来制定下一时间段的扩缩容方案，容易出现滞后性；且不能满足随机出现并且短时间需要大量资源的场景。
[0088] 综上，以上两种方式都有资源扩缩容不及时或者不准确导致无法满足用户的使用需求的缺点，只能应用在某些特定的业务场景里，例如用户的资源需求较平稳的场景。
[0089] 本发明实施例提供另一种数据库服务器的资源配置方法，对主数据库和备数据库不再同时进行动态扩缩容，仅对备数据库进行动态扩缩容。且对备数据库的动态扩缩容也不是基于对用户的资源使用需求进行预测或监控进行的，因而不存在资源扩缩容不及时或者不准确的问题，提高了数据库服务器的资源利用率的同时，能够满足各种类型的使用场景，适用性强。
[0090] 图2示出了本发明实施例提供的一种数据库服务器的资源配置方法，该方法用于将用户申请的数据库系统中备数据库的备资源配置量设置为最低配置量。包括：
[0091] 步骤201，基于针对所述第一数据库系统的共享触发行为，获取使用所述第一数据库系统的各账户的账户模式；所述共享触发行为为用户对所述第一数据库系统的申请行为或所述第一数据库系统的新增账户行为。
[0092] 步骤202，根据各账户模式确定所述第一数据库系统不存在主数据库和备数据库同时提供服务的服务需求。
[0093] 步骤203，将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量。
[0094] 在步骤201中，用户向数据库云平台申请数据库系统，数据库系统可以是仅包括一个主数据库，也可以包括一个主数据库和一个备数据库，或者包括一个主数据库和多个备数据库，在此不做限制。若数据库系统不包括备数据库，则不存在将备数据库的备资源配置量设置为最低配置量的情况，直接按照用户的需求设置主数据库的主资源配置量即可。因此本发明实施例的第一数据库系统专指包括一个或多个备数据库的数据库系统。
[0095] 一种可能的场景，当用户向数据库云平台申请第一数据库系统后，数据库云平台获取使用该第一数据库系统的各账户的账户模式。账户是指以后会使用该第一数据库系统进行查询、修改等操作的账户，因此账户可能是一个或多个。
[0096] 例如，用户A向数据库云平台申请第一数据库系统，包括CPU资源为8核的主数据库和CPU资源为8核的备数据库；数据库云平台获取该第一数据库系统对应的各账户的账户模式。这里各账户的账户模式可能是用户A在申请第一数据库系统时提交，也可以是数据库云平台主动调取，也可以为其他方式。在此不做限制。
[0097] 另一种可能的场景，用户已经申请到了第一数据库系统，且已经有一个或多个账户在使用该第一数据库系统了。当有新增的账户使用该第一数据库系统时，数据库云平台也会获取使用该第一数据库系统的各账户的账户模式，这里各账户的账户模式包括新增的账户的账户模式。
[0098] 例如，用户A已经申请到了第一数据库系统，该第一数据库系统中的主数据库部署在数据库服务器100，备数据库部署在数据库服务器200。已经有账户zhangsan、账户lisi在使用该第一数据库系统。当有新增账户wangwu时，数据库云平台也会获取使用该第一数据库系统的各账户的账户模式，即，获取账户zhangsan、账户lisi和账户wangwu的账户模式。
[0099] 在步骤202中，根据各账户模式确定所述第一数据库系统不存在主数据库和备数据库同时提供服务的服务需求。
[0100] 在使用该第一数据库系统的各账户中，可能存在需要主数据库和备数据库同时提供服务的服务需求，通过各账户的账户模式可以进行确定。例如，若确定各账户模式中存在读写分离模式和/或只读从库模式，则说明该第一数据库系统存在主数据库和备数据库同时进行服务的服务需求，该第一数据库系统的备数据库的备资源配置量不能为最低配置量，而应和主数据库的主资源配置量一致。
[0101] 例如，确定主数据库的主资源配置量为8核，确定备数据库的备资源配置量也为8核。
[0102] 若确定各账户模式中不存在读写分离模式和只读从库模式，则该第一数据库系统的备数据库的备资源配置量可以为最低配置量，将其设置为最低配置量不影响第一数据库系统的正常服务。
[0103] 在步骤203中，将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量。
[0104] 一种可能的情况，在步骤203之前，尚未将备数据库部署在任一数据库服务器中。因此当确定第一数据库系统不存在主数据库和备数据库同时提供服务的服务需求后，再将备数据库部署在任一数据库服务器中。图3示出了一种可能的部署方式，包括如下步骤：
[0105] 步骤301，获取用户申请的所述第一数据库系统的备资源需求量。
[0106] 例如，用户申请第一数据库系统为CPU资源为8核的主数据库和CPU资源为8核的备数据库。数据库云平台获取用户申请的备资源需求量为8核。
[0107] 步骤302，选择任一数据库服务器，判断所述数据库服务器的共享资源配置量是否大于等于所述备资源需求量，若大于等于所述备资源需求量，则在所述数据库服务器中部署所述第一数据库系统的备数据库，并将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量。
[0108] 对于任一数据库服务器的资源，设置已用资源配置量和共享资源配置量两个部分，已用资源配置量是分配给主数据库的资源配置量的和；共享资源配置量是为各备数据库准备的资源量，用于使各备数据库进行共享。共享资源配置量可以是固定的，也可以是动态调整的。例如，数据库服务器100共有48核的CPU资源，其中有24核的CPU资源分配给主数据库，每个主数据库配置有8核，则数据库服务器100的已用资源配置量为24核。若共享资源配置量为固定的10核，则在数据库服务器100中部署的各备数据库共享这10核的CPU资源，其中任一备数据库的备资源配置量不大于10核。当再有2个CPU资源需求均为8核的主数据库部署在该数据库服务器100上、1个CPU资源需求为10核的主数据库部署在该数据库服务器100上时，已用资源配置量为32核，共享资源配置量依然为10核。当前数据库服务器100还可接受多个备数据库部署在其上，只要这些备数据库对应的备资源需求量不大于10核。
[0109] 若共享资源配置量为动态调整的，则可以是如下调整方式：例如，数据库服务器100共有48核的CPU资源，其中有24核的CPU资源分配给主数据库，每个主数据库配置有8核，则数据库服务器100的已用资源配置量为24核，共享资源配置量为0核。当备数据库a部署在数据库服务器100上，用户申请的备数据库a的对应的备资源需求量为8核，那么共享资源配置量就是8核。当备数据库b部署在数据库服务器100上，用户申请的备数据库b对应的备资源需求量为10核，那么共享资源配置量更新为10核。当主数据库c部署在数据库服务器100上，用户申请的主数据库c的对应的主资源需求量为14核，那么已用资源配置量就是38核。
[0110] 举个例子，当接收到第一数据库系统的备资源需求量为8核时，选择数据库服务器100，判断数据库服务器100的共享资源配置量是否大于等于备资源需求量8核，若大于等于备资源需求量8核，则在数据库服务器100中部署第一数据库系统的备数据库，并将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量。这里的最低配置量可以为0核、1核等能满足最低需求的配置量。也就是说，共享配置量并不真正完全提供给备数据库。
[0111] 步骤303，若不大于等于所述备资源需求量，则判断所述数据库服务器的剩余资源配置量是否大于等于所述备资源需求量，若大于等于所述备资源需求量，则在所述数据库服务器中部署所述第一数据库系统的备数据库，并将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量，将所述数据库服务器的共享资源配置量更新为所述备资源需求量；若不大于等于所述备资源需求量，则不在所述数据库服务器中部署所述第一数据库系统的备数据库。
[0112] 剩余配置量为数据库服务器的总资源配置量减去已用配置量后剩余的配置量。
[0113] 举个例子，若数据库服务器的共享资源配置量为8核，备资源需求量为10核，共享资源配置量不大于等于备资源需求量，因此判断剩余资源配置量是否大于等于所述备资源需求量，若剩余资源配置量为10核，则满足，剩余资源配置量大于等于所述备资源需求量的条件，因此依然在数据库服务器中部署该备数据库，将备数据库的备资源配置量设置为最低配置量，例如0核，将所述数据库服务器的共享资源配置量更新为10核。
[0114] 图4示出了一种可能的数据库服务器的已用资源配置量、共享资源配置量和剩余资源配置量的示意图。其中，两个备数据库的备资源配置量均为0核，两个备数据库共享8核的共享资源配置量。
[0115] 步骤203的另外一种可能的情况，在步骤203之前，已经将第一数据库系统的主数据库和备数据库按照各自的资源需求量部署在了数据库服务器中。例如用户申请第一数据库系统，包括8核的CPU资源的主数据库和8核的CPU资源的备数据库，数据库云平台将主数据库部署在了数据库服务器100上，为其分配8核的CPU资源，将备数据库部署在了数据库服务器200上，为其分配8核的CPU资源。这种配置方式无需对原始的部署数据库的代码逻辑进行更改，当接收到用户的数据库系统的申请请求后，针对主数据库，只需将任一数据库服务器的剩余资源配置量与主数据库的主资源需求量进行对比，若大于等于主数据库的主资源需求量，则在该数据库服务器中部署主数据库；若不大于等于主数据库的主资源需求量，则更换下一个数据库服务器进行判断，直至在某一数据库服务器中部署了该主数据库。针对备数据库，将任一数据库服务器的剩余资源配置量与备数据库的备资源需求量进行对比，若大于等于备数据库的备资源需求量，则在该数据库服务器中部署备数据库；若不大于等于备数据库的备资源需求量，则更换下一个数据库服务器进行判断，直至在某一数据库服务器中部署了该备数据库。
[0116] 在进行了以上部署后，数据库云平台再获取备数据库的备资源配置量，将备资源配置量更改为最低配置量。
[0117] 例如将8核的备资源配置量，更改为0核的最低配置量。
[0118] 以上方式无需更改原始的部署逻辑，也无需将资源需求量与共享资源量和剩余资源量均进行比较。在按照备资源需求量部署备数据库时，就可保证等到以后主备切换时，部署的数据库服务器能够支撑备数据库的资源需求。例如在主备切换时，备数据库的备资源配置量由0更新为8核，备数据库的宿主服务器的剩余资源配置量是一定可以满足这样的更新的。
[0119] 图5a示出了未采用本发明实施例提供的方法进行部署的数据库服务器；图5b示出了采用了本发明实施例提供的方法进行部署的数据库服务器。如图所示，未采用本发明实施例提供的方法时，数据库服务器中仅可以部署5个数据库，因为每个备数据库也需要为其分配8核的CPU资源，即便该备数据库并未对外提供服务。采用了本发明实施例提供的方法后，各备数据库共享8核的CPU资源，数据库服务器中可以部署5个以上的数据库，例如图中示意的9个。数据库服务器中部署的数据库的数量增加了，数据库服务器的资源利用率进而增加。
[0120] 在上述部署方式中，多个备数据库共享数据库服务器剩余未分配的CPU资源，例如图5b中，共享8核的CPU资源。备数据库之间的资源隔离性虽然变差了，但是由于这些备数据库并未对外提供服务，对外提供服务的是数据库系统的主数据库，因此资源隔离性变差并不影响该数据库系统的正常运行。
[0121] 在上述技术方案中，在用户新申请第一数据库系统时，或者在第一数据库系统新增账户时，获取使用该第一数据库系统的各账户的账户模式，根据各账户模式确定所述第一数据库系统不存在主数据库和备数据库同时进行服务的服务需求，因此就可将备数据库的备资源配置量设置为最低配置量。如此，通过账户模式进行了判断，防止在需要主数据库和备数据库同时进行服务的情况中，将备数据库的备资源配置量设置为最低配置量的问题发生。若第一数据库系统需要主数据库和备数据库同时进行服务，而将备数据库的备资源配置量设置为最低配置量，则第一数据库服务无法对外提供用户所需的服务。
[0122] 在一些实施例中，针对任一数据库服务器，采用容器的方式部署各数据库。容器(DOCKER)是一种虚拟化技术，是一种基于进程容器的轻量级虚拟化解决方案。与虚拟机(Virtual Machine，VM)技术不同，容器技术通过隔离资源与进程，实现轻量级虚拟化，性能损耗几乎可以忽略不计。每个数据库都部署在数据库服务器上的一个独立容器中，并且为容器配置专用IP地址，CPU和内存以及独立的文件系统作为表空间和日志空间。
[0123] 经过上述部署后，备数据库的资源配置量为最低配置量。下面介绍，如何恢复备数据库的资源配置量的方法。
[0124] 图6示出了本发明实施例提供的数据库服务器的资源配置方法，包括：
[0125] 步骤601，响应于针对任一第一数据库系统的主备切换指令，获取所述第一数据库系统中主数据库的主资源配置量；所述主备切换指令用于指示所述第一数据库系统的备数据库替代主数据库提供服务；资源配置量为数据库的宿主服务器为所述数据库配置的中央处理器CPU的量；
[0126] 步骤602，将所述第一数据库系统中备数据库的备资源配置量更新为所述主资源配置量；所述备资源配置量是在所述第一数据库系统的备数据库无服务需求的情况下设置为最低配置量的；所述第一数据库系统的备数据库的宿主服务器的共享资源配置量大于等于所述主资源配置量；所述共享资源配置量由所述宿主服务器中部署的各备数据库共享；
[0127] 步骤603，将所述第一数据库系统的备数据库更新为所述第一数据库系统的主数据库，以使更新后的主数据库基于更新后的所述主资源配置量提供服务。
[0128] 在步骤601中，第一数据库系统的主数据库由于一些原因需要切换为备数据库。主备切换的原因可以是主数据库的宿主服务器发生故障，或者运维人员出于测试需求需要切换等。本发明实施例对此不作限制。
[0129] 在接收到主备切换指令后，数据库云平台获取第一数据库系统中的主数据库的主资源配置量。例如，数据库云平台获取到主数据库的主资源配置量为6核。
[0130] 在步骤602中，获取该第一数据库系统的备数据库的宿主服务器，将该备数据库在宿主服务器中的备资源配置量更新为主资源配置量，例如，从0核更新为6核。
[0131] 该宿主服务器中部署了一个或多个备数据库，各备数据库共享一部分资源配置量，共享资源配置量大于等于主资源配置量。如图5b所示，4个备数据库共享数据库服务器100中的8核的CPU资源。
[0132] 在步骤603中，将所述第一数据库系统的备数据库更新为所述第一数据库系统的主数据库，那么，更新后的主数据库就能够基于更新后的所述主资源配置量提供服务。
[0133] 在第一数据库系统中的备数据库无服务需求时，将备数据库的备资源配置量设置为最低配置量，仅通过主数据库的主资源配置量提供服务；当第一数据库系统需要进行主备切换时，将备数据库的备资源配置量更新为主资源配置量，从而可使更新后的主数据库基于更新后的所述主资源配置量提供服务。上述方案中，备数据库在不提供服务时，不占用服务器资源，从而为备数据库的宿主服务器节省下更多的资源来部署其他主数据库，提高了服务器的资源利用率。相较于预测法和监控法等方法，本发明实施例提供的方法不是对正在服务的主数据库和不进行服务的备数据库同时进行动态扩缩容。而是对正在服务的主数据库不作资源配置的任何改变，将备数据库的资源配置设置为最低配置量。仅在接收到主备切换指令后，将备数据库的备资源配置量设置为与主数据库相同的主资源配置量。由于主数据库提供服务时是基于主资源配置量进行的，主资源配置量是用户根据自身业务需求申请的足够支撑业务运行的量，因此无需进行动态扩缩容，能够满足业务突增等极端情况，不存在动态扩缩容导致的不准确和滞后性问题，可以满足各种类型的使用场景，适用性强。
[0134] 由于用户在申请数据库系统时，会按照自身的最大需求进行申请，例如一天内只有1个小时需要8核的CPU，其余23个小时需要4核的CPU即可，那么用户会申请8核的主数据库和8核的备数据库。本发明实施例提供的方法不对主数据库的资源配置量进行动态扩缩容，一直采用8核的CPU提供服务，因此一定可以支撑业务运行。所以不存在动态扩缩容导致的不准确和滞后性问题。只对备数据库的资源配置量进行动态扩缩容，且是基于主备切换进行动态扩缩容的，和预测法、监控法等方法进行动态扩缩容的场景、方法不同，解决问题的角度不同。
[0135] 在一些实施例中，将第一数据库系统的备数据库更新为所述第一数据库系统的主数据库之后，还包括：将所述第一数据库系统的初始主数据库更新为备数据库，并将更新后的备数据库的备资源配置量更新为最低配置量。
[0136] 为了能快速进行主备切换，因此设置在主备切换之后再将原来的主数据库更新为备数据库，并将更新后的备数据库的备资源配置量更新为最低配置量。如此，自动将无服务需求的备数据库的备资源配置量设置为最低配置量，尽量少地占用服务器资源。提高服务器资源利用率。
[0137] 在一些实施例中，将所述第一数据库系统的初始主数据库更新为备数据库后，并不直接将更新后的备数据库的备资源配置量更新为最低配置量。而是采用周期性检查的方式检查出没有设置成最低配置量的备数据库，将其设置为最低配置量。
[0138] 具体为，周期性获取运行在各服务器的多个第二数据库系统；判断任一第二数据库系统中是否存在任一备数据库的备资源配置量不是最低配置量；若是，则针对所述第二数据库系统，获取使用所述第二数据库系统的各账户的账户模式；根据各账户模式确定所述第二数据库系统不存在主数据库和备数据库同时进行服务的服务需求；将所述第二数据库系统的备数据库的备资源配置量设置为最低配置量。
[0139] 为了能快速进行主备切换，因此在主备切换之前，仅将备数据库的备资源配置量更新为主资源配置量。在主备切换之后，再将所述数据库系统的初始主数据库更新为备数据库。为了能及时将各备数据库的资源配置量设置为最低配置量，因此周期性地获取运行在各服务器的多个第二数据库系统，对任一第二数据库系统进行检查，若不存在主数据库和备数据库同时进行服务的服务需求，则将所述第二数据库系统的备数据库的备资源配置量设置为最低配置量。如此无需在每个初始主数据库更新为备数据库后，就将该备数据库的资源配置量设置为最低配置量，而是周期性发现，统一更新，更加简单。实现了对各第二数据库系统的备数据库的备资源配置量的统一更新。
[0140] 进行主备切换之前将备数据库的备资源配置量进行更改，耗时在毫秒级，这对数据库系统对外提供服务的影响几乎可以忽略。
[0141] 由于数据库云平台管理的服务器的数量较为庞大，因此在任一数据库服务器中，同时有多个备数据库被切换为主数据库的可能性较低。例如图5b中，各备数据库对应的主数据库很可能分布在其他不同的数据库服务器上，这些数据库服务器同时故障的可能性很小。若同时故障了，则这些备数据库均切换成为主数据库，这些主数据库共享8核的CPU资源对外提供服务。因此牺牲了一定的资源隔离性。
[0142] 因此在一些实施例中，可以对任一数据库服务器中参与共享的备数据库的数量进行限制，即任一数据库服务器中参与共享的备数据库的数量大于第一阈值且小于第二阈值，例如大于2且小于5。设置第一阈值是为了提高服务器的资源利用率，设置第二阈值是为了减小牺牲资源隔离性的概率。
[0143] 为了更好的解释本发明实施例，下面将在具体实施场景下来描述上述数据库服务器的资源配置的方法。
[0144] 本发明实施例在数据库云平台中设置共享单元、重配置单元和周期性检查单元。
[0145] 共享单元可以基于3个场景被触发：1、用户申请数据库系统，则共享单元会获取该数据库系统；2、数据库系统中有新增账户，则共享单元会获取该数据库系统；3、周期性检查单元检查出存在没有设置为最低配置量的备数据库，则共享单元会获取该备数据库对应的数据库系统。
[0146] 下面对共享单元的执行流程进行介绍，如图7所示，包括：
[0147] 步骤701，接收第一数据库系统，判断第一数据库系统的各备数据库所位于的数据库服务器是否允许将备数据库的备资源配置量设置为最低配置量的行为。
[0148] 这里的第一数据库系统就是以上3个场景中的任一场景触发后获取的数据库系统。
[0149] 若不允许，则记录到日志中，结束流程。
[0150] 由于用户存在一些业务对处理速度要求很高，例如交易处理，那么这些业务对应的备数据库可以被部署在特定的数据库服务器，特定的数据库服务器不允许将在其上部署的任一备数据库的备资源配置量设置为最低配置量，因为如果这样做的话，在主备切换时，需要将最低配置量恢复为主资源配置量，几毫秒的延时也是不允许的。
[0151] 步骤702，获取第一数据库系统的部署架构信息。
[0152] 部署架构信息包括第一数据库系统包含的各数据库名称、CPU个数、内存数量、IP地址、端口、状态、角色以及所在数据库服务器相关信息。例如获取第一数据库系统包含3个数据库，以及这3个数据库的名称、CPU个数、内存数量、IP地址、端口、状态、角色以及所在数据库服务器等。
[0153] 步骤703，解析数据库的角色。
[0154] 确定第一数据库系统中包含的主数据库和备数据库。例如确定第一数据库系统中包含一个主数据库和2个备数据库。
[0155] 步骤704，获取主数据库的CPU资源配置量。
[0156] 步骤705，获取使用第一数据库系统的账户信息。
[0157] 调用平台提供的数据库用户查询接口，获取第一数据库服务中配置的账户信息，包括账户名称、账户模式、黑白名单、连接数以及权限信息。
[0158] 步骤706，解析第一数据库系统的各账户模式，判断是否有读写分离和只读从库的账户模式。
[0159] 这两种模式是指将部分查询的SQL请求路由到备数据库上，降低主数据库上查询的压力，满足写少读多的业务场景。在此场景下，跟主数据库一样，备数据库也直接对外提供服务，只是提供的查询服务，不提供数据写入、更新和删除服务。
[0160] 步骤707，将各备数据库的备资源配置量设置为最低配置量。
[0161] 具体为，针对任一备数据库，在该备数据库的宿主服务器上执行备资源配置量设置为最低配置量的命令。
[0162] 步骤708，将各备数据库的备资源配置量设置为和主资源配置量相同。
[0163] 具体为，针对任一备数据库，在该备数据库的宿主服务器上执行备资源配置量设置为和主资源配置量相同的命令。
[0164] 以上任一步骤执行失败，则将异常情况记录到日志中，以备管理人员查看。
[0165] 下面对重配置单元的执行流程进行介绍，如图8所示，包括：
[0166] 步骤801，响应于针对第一数据库系统的主备切换指令，获取第一数据库系统的部署架构信息。
[0167] 部署架构信息包括第一数据库系统包含的各数据库名称、CPU个数、内存数量、IP地址、端口、状态、角色以及所在数据库服务器相关信息。例如获取第一数据库系统包含3个数据库，以及这3个数据库的名称、CPU个数、内存数量、IP地址、端口、状态、角色以及所在数据库服务器等。
[0168] 步骤802，获取第一数据库系统中主数据库的主资源配置量。
[0169] 步骤803，获取第一数据库系统备数据库所位于的容器的名称和宿主服务器信息。
[0170] 步骤804，在宿主服务器上，执行将备数据库所位于的容器的资源配置量更新为所述主资源配置量的命令。
[0171] 若无法确定之后会将哪个备数据库更新为主数据库，则将各备数据库均执行上述更新命令。若能够确定之后会将哪个备数据库更新为主数据库，则只将之后会更新为主数据库的备数据库执行上述更新命令。
[0172] 以上任一步骤执行失败，则将异常情况记录到日志中，以备管理人员查看。
[0173] 下面对周期性检查单元的执行流程进行介绍，如图9所示，包括：
[0174] 步骤901，判断当前时刻是否需要发起周期性检查。
[0175] 步骤902，获取运行在各服务器的各数据库系统。
[0176] 步骤903，等待1分钟后，返回步骤901。
[0177] 步骤904，针对任一数据库系统，确定该数据库系统的部署架构信息。
[0178] 调用数据库云平台接口查询这个数据库系统的部署架构信息，包括数据库名称、CPU个数、内存数量、IP地址、端口、状态、角色以及所在物理服务器相关信息。
[0179] 步骤905，针对该数据库系统中任一备数据库，判断该备数据库的CPU个数是否为0。若是，则进入步骤907。若否，则进入步骤906。
[0180] 步骤906，调用共享单元。
[0181] 步骤907，对下一个备数据库执行步骤905。
[0182] 在主备切换中，重配置单元只负责将备数据库的备资源配置量恢复为主资源配置量，这样是为了减少操作时间，在恢复为主资源配置量后尽可能快的进行主备切换。在之前的方案中有提到，若有多个备数据库的话，因为无法确定之后哪个备数据库会被切换为主数据库，因此各备数据库的备资源配置量会都恢复为主资源配置量。例如3个备数据库都从0核恢复为8核。然后进行主备切换。并且初始主数据库已经更新为备数据库了，不提供服务了，但是资源配置量却依然为8核。
[0183] 那么以上情况都可以通过周期性检查单元检查出来，周期性检查单元会检查出已经更新为备数据库的初始主数据库、备资源配置量被恢复的备数据库，将这些备数据库所对应的数据库系统发送至共享单元进行处理。
[0184] 基于相同的技术构思，图10示例性的示出了本发明实施例提供的一种数据库服务器的资源配置装置的结构，该结构可以执行数据库服务器的资源配置的流程。
[0185] 如图10所示，该装置具体包括：
[0186] 获取单元1001，用于响应于针对任一第一数据库系统的主备切换指令，获取所述第一数据库系统中主数据库的主资源配置量；所述主备切换指令用于指示所述第一数据库系统的备数据库替代主数据库提供服务；资源配置量为数据库的宿主服务器为所述数据库配置的中央处理器CPU的量；
[0187] 处理单元1002，用于：
[0188] 将所述第一数据库系统中备数据库的备资源配置量更新为所述主资源配置量；所述备资源配置量是在所述第一数据库系统的备数据库无服务需求的情况下设置为最低配置量的；所述第一数据库系统的备数据库的宿主服务器的共享资源配置量大于等于所述主资源配置量；所述共享资源配置量由所述宿主服务器中部署的各备数据库共享；
[0189] 将所述第一数据库系统的备数据库更新为所述第一数据库系统的主数据库，以使更新后的主数据库基于更新后的所述主资源配置量提供服务。
[0190] 在一些实施例中，所述处理单元1002具体用于：
[0191] 基于针对所述第一数据库系统的共享触发行为，获取使用所述第一数据库系统的各账户的账户模式；所述共享触发行为为用户对所述第一数据库系统的申请行为或所述第一数据库系统的新增账户行为；
[0192] 根据各账户模式确定所述第一数据库系统不存在主数据库和备数据库同时提供服务的服务需求；
[0193] 将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量。
[0194] 在一些实施例中，所述处理单元1002具体用于：
[0195] 获取用户申请的所述第一数据库系统的备资源需求量；
[0196] 选择任一数据库服务器，判断所述数据库服务器的共享资源配置量是否大于等于所述备资源需求量，若大于等于所述备资源需求量，则在所述数据库服务器中部署所述第一数据库系统的备数据库，并将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量；
[0197] 若不大于等于所述备资源需求量，则判断所述数据库服务器的剩余资源配置量是否大于等于所述备资源需求量，若大于等于所述备资源需求量，则在所述数据库服务器中部署所述第一数据库系统的备数据库，并将所述第一数据库系统的备数据库的备资源配置量设置为最低配置量，将所述数据库服务器的共享资源配置量更新为所述备资源需求量；若不大于等于所述备资源需求量，则不在所述数据库服务器中部署所述第一数据库系统的备数据库。
[0198] 在一些实施例中，所述处理单元1002还用于：
[0199] 若根据各账户模式确定所述第一数据库系统存在主数据库和备数据库同时进行服务的服务需求，则将所述第一数据库系统的备数据库的备资源配置量设置为所述主资源配置量。
[0200] 在一些实施例中，所述处理单元1002具体用于：
[0201] 若各账户模式中不存在读写分离和只读备数据库的账户模式，则确定所述第一数据库系统不存在主数据库和备数据库同时进行服务的服务需求。
[0202] 在一些实施例中，所述处理单元1002还用于：
[0203] 将所述第一数据库系统的初始主数据库更新为备数据库，并将更新后的备数据库的备资源配置量更新为最低配置量。
[0204] 在一些实施例中，所述处理单元1002还用于：
[0205] 将所述第一数据库系统的初始主数据库更新为备数据库；
[0206] 周期性获取运行在各服务器的多个第二数据库系统；判断任一第二数据库系统中是否存在任一备数据库的备资源配置量不是最低配置量；
[0207] 若是，则针对所述第二数据库系统，获取使用所述第二数据库系统的各账户的账户模式；
[0208] 根据各账户模式确定所述第二数据库系统不存在主数据库和备数据库同时进行服务的服务需求；
[0209] 将所述第二数据库系统的备数据库的备资源配置量设置为最低配置量。
[0210] 基于相同的技术构思，本申请实施例提供了一种计算机设备，如图11所示，包括至少一个处理器1101，以及与至少一个处理器连接的存储器1102，本申请实施例中不限定处理器1101与存储器1102之间的具体连接介质，图11中处理器1101和存储器1102之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。
[0211] 在本申请实施例中，存储器1102存储有可被至少一个处理器1101执行的指令，至少一个处理器1101通过执行存储器1102存储的指令，可以执行上述数据库服务器的资源配置方法的步骤。
[0212] 其中，处理器1101是计算机设备的控制中心，可以利用各种接口和线路连接计算机设备的各个部分，通过运行或执行存储在存储器1102内的指令以及调用存储在存储器1102内的数据，从而进行数据库服务器的资源配置。在一些实施例中，处理器1101可包括一个或多个处理单元，处理器1101可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1101中。在一些实施例中，处理器1101和存储器1102可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
[0213] 处理器1101可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0214] 存储器1102作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1102可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random Access Memory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read‑Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1102是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1102还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
[0215] 基于相同的技术构思，本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行程序，计算机可执行程序用于使计算机执行上述任一方式所列的数据库服务器的资源配置的方法。
[0216] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD‑ROM、光学存储器等)上实施的计算机程序产品的形式。
[0217] 本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0218] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0219] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0220] 显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
