管理数据库的方法和相应的装置、计算机可读存储介质与流程

本公开涉及数据库领域，具体地，涉及一种用于管理数据库的方法和相应的装置、计算机可读存储介质。

背景技术：

数据库作为存储数据的基础设施，广泛应用于互联网领域的各种产品。对于具有数据量大、对响应延时要求高、业务复杂等特性的产品，为了支撑产品业务的负载，尤其是瞬时的超高负载，已经提出了使用数据库集群。数据库集群可以包括一个主数据库和一个或多个从数据库，其中主数据库负责数据的写入，从数据库负责数据的读取，并且从数据库可以从主数据库备份数据(或者也可以称为同步数据或复制数据)。在数据库集群中，当主数据库发生故障时，可以将从数据库提升为主数据库，以减少业务的停工时间，保持数据库服务的高度可用性。

为了保证数据库集群中各个数据库的数据一致性，提高数据库集群的可运维性，已经提出了一些通用的数据库管理系统。例如，目前使用广泛的数据库管理系统包括keepalived系统、云数据库系统和主数据库高可用系统(masterhighavailability，mha)。然而，这些已有的数据库管理系统存在各种缺陷，例如，不能支持从数据库的扩展以满足超高负载的读写需求、自愈能力不强而无法管理大量的数据库集群、存在安全性问题无法满足金融场景的合规要求等。

技术实现要素：

为此，本公开提供了一种用于管理数据库的方法和相应的装置、计算机可读存储介质。

根据本公开的一个方面，提供了一种用于管理数据库的方法。所述方法包括：接收主数据库的运行状态信息；根据所述主数据库的运行状态信息确定所述主数据库的运行状态；当确定所述主数据库的运行状态为所述主数据库发生故障时，从至少两个从数据库中选择一个从数据库作为新的主数据库；以及向分别与所述至少两个从数据库中的其他从数据库对应的管理服务器代理模块发送关于新的主数据库的信息，通过与所述其他从数据库对应的管理服务器代理模块控制所述其他从数据库从新的主数据库备份数据。

根据本公开的另一方面，提供了一种用于管理数据库的装置。所述装置包括：接收单元，被配置为接收主数据库的运行状态信息；确定单元，被配置为根据所述主数据库的运行状态信息确定所述主数据库的运行状态；选择单元，被配置为当所述确定单元确定所述主数据库的运行状态为所述主数据库发生故障时，从至少两个从数据库中选择一个从数据库作为新的主数据库；以及发送单元，被配置为向分别与所述至少两个从数据库中的其他从数据库对应的管理服务器代理模块发送关于新的主数据库的信息，通过与所述其他从数据库对应的管理服务器代理模块控制所述其他从数据库从新的主数据库备份数据。

根据本公开的一个示例，接收单元被配置为从与所述主数据库对应的管理服务器代理模块接收所述主数据库的运行状态信息。

根据本公开的一个示例，接收单元被配置为从与所述至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收所述主数据库的运行状态信息。

根据本公开的一个示例，选择单元被配置为从所述至少两个从数据库确定候选的从数据库；以及从所述候选的从数据库中选择一个从数据库作为新的主数据库。

根据本公开的一个示例，选择单元被配置为确定所述至少两个从数据库中其事务标识被管理服务器获取的从数据库，其中所述管理服务器用于管理所述主数据库和所述至少两个从数据库；判断所确定的从数据库的数量是否大于所述至少两个从数据库的数量的预定比例；当所确定的从数据库的数量大于所述至少两个从数据库的数量的预定比例时，将所确定的从数据库确定为候选的从数据库；以及从所述候选的从数据库中选择一个从数据库作为新的主数据库。

根据本公开的一个示例，每个从数据库具有其充当主数据库的优先级；选择单元被配置为至少根据所述候选的从数据库中的每个从数据库的优先级，从所述候选的从数据库中选择一个从数据库作为新的主数据库。

根据本公开的一个示例，选择单元被配置为根据所述候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择一个从数据库作为新的主数据库。

根据本公开的一个示例，选择单元被配置为判断所述候选的从数据库中具有最高优先级的从数据库是否具有最大事务标识；以及当具有最高优先级的从数据库具有最大事务标识时，将具有最高优先级的从数据库作为新的主数据库。

根据本公开的一个示例，选择单元被配置为当具有最高优先级的从数据库不具有最大事务标识时，通过与具有最高优先级的从数据库对应的管理服务器代理模块，控制具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据，以使得具有最高优先级的从数据库具有最大事务标识；以及将具有最高优先级的从数据库作为新的主数据库。

根据本公开的一个示例，发送单元被配置为向与所述新的主数据库对应的管理服务器代理模块发送配置信息，其中所述配置信息指示所述新的主数据库与所述其他从数据库之间的复制机制，以便与所述新的主数据库对应的管理服务器代理模块控制所述新的主数据库采用所述复制机制。

根据本公开的一个示例，发送单元被配置为向与所述主数据库对应的管理服务器代理模块发送修复信息，以便与所述主数据库对应的管理服务器代理模块修复所述主数据库。

根据本公开的另一方面，提供了一种用于管理数据库的装置。所述管理服务器包括处理器；以及存储器，其中，所述存储器中存储有计算机可读代码，所述计算机可读代码当由所述处理器运行时，执行上述方法。

根据本公开的另一方面，提供了一种计算机可读存储介质，其上存储有指令，所述指令在被处理器运行时，使得所述处理器执行上述方法。

通过本公开的方法和相应的装置、计算机可读存储介质，当主数据库发生故障时，可以从多个从数据库中选择一个作为新的主数据库，以保障数据库服务的高可用。此外，通过本公开的方法和相应的装置、计算机可读存储介质，管理服务器通过管理服务器代理模块对数据库进行操作，避免了依赖ssh对数据库进行操作，满足了金融场景的合规性要求。

附图说明

通过结合附图对本公开实施例进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显。附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与本公开实施例一起用于解释本公开，并不构成对本公开的限制。在附图中，相同的参考标号通常代表相同部件或步骤。

图1示出了keepalived系统的架构示意图。

图2示出了云数据库系统的架构示意图。

图3示出了mha系统的架构示意图。

图4a是根据本公开实施例的数据库管理系统的架构示意图。

图4b是根据本公开实施例的数据库管理系统中的数据库的示意图。

图5是根据本公开实施例的由管理服务器执行的方法的流程图。

图6是根据本公开实施例的应用图4a所示的架构的一个示例性的具体流程。

图7是根据本公开实施例的实现管理服务器高可用和系统库高可用的架构示意图。

图8示出了根据本公开实施例的管理服务器的结构示意图。

图9示出了根据本公开实施例的计算机设备的架构。

具体实施方式

为了使得本公开的目的、技术方案和优点更为明显，下面将参照附图详细描述根据本公开的示例实施例。在附图中，相同的参考标号自始至终表示相同的元件。应当理解：这里描述的实施例仅仅是说明性的，而不应被解释为限制本公开的范围。

首先，参照图1-3来分别描述已有的keepalived系统、云数据库系统和mha系统。图1示出了keepalived系统的架构示意图。如图1所示，keepalived系统包括一个主数据库110和一个从数据库120。当主数据库110发生故障时，从数据库120可以被提升为新的主数据库。由于keepalived系统只支持一主一从，无法对从数据库进行扩展，因此，不适合数据库实例较多或数据库负载较多的应用场景。此外，在keepalived系统中，当主数据库发生故障时，主数据库不具备任何的自愈能力。

云数据库系统相对于keepalived系统具有较多优势。具体地，云数据库系统在一主一从的基础上，增加了一个或多个只读从数据库，从而实现了对从数据库进行扩展，提供了更好的读扩展能力。此外，在云数据库系统中，设计了一套复杂的数据库自愈组件，以便在主数据库发生故障时使主数据库自愈。

图2示出了云数据库系统的架构示意图。如图2所示，云数据库系统包括一个主数据库210、一个从数据库220以及三个只读从数据库230、240和250(即在图2中以虚线与主数据库210连接的数据库)。当主数据库210发生故障时，仅从数据库220可以被提升为主数据库。此外，当主数据库210发生故障时，主数据库210可以自愈，并且在自愈后，主数据库210可以作为从数据库220的从数据库而从从数据库220备份数据。

虽然云数据库系统克服了keepalived系统的缺陷，但是它本质上还是一个一主一从的数据库高可用系统。云数据库系统存在某些缺陷。例如，如果云数据库系统中的主数据库和从数据库同时发生故障时，无法保障数据库服务的高可用。另外，由于云数据库系统的强制限制，因此，云数据库系统中的只读从数据库的数量受限，从而无法根据需求对从数据库进行扩展。另外，在云数据库系统中，无法定制只读从数据库所处的机房，从而无法满足某些业务对机房的地理位置的个性化需求。

主数据库高可用系统(masterhighavailability，mha)是真正的一主多从的数据库高可用系统。图3示出了已有的mha系统的架构示意图。如图3所示，mha系统包括一个主数据库310、四个从数据库320、330、340和350。当主数据库310发生故障时，从数据库320、330、340和350中的任何一个可以被提升为主数据库。

然而，mha系统是通过脚本实现的，而脚本无法支持数据库自愈的一系列复杂操作，因此，mha系统中的数据库不具备自愈能力。此外，在mha系统中，配置了用于管理数据库的管理装置。该管理装置通过安全外壳协议(secureshellprotocol，ssh)对数据库进行操作。例如，该管理装置可以通过ssh定时探测集群中的主数据库，以及当探测到主数据库发生故障时，该管理装置可以从多个从数据库中选择一个并将其提升为主数据库，并且通过ssh指示剩余的从数据库从新的主数据库备份数据。然而，ssh在安全方面具有缺陷，例如ssh可能遭受“中间人”攻击，因此，在金融场景下禁止使用ssh。

鉴于已有的数据库管理系统存在各种各样的问题，本公开提出了一种针对一主多从的数据库管理系统，具体地，提出了一种用于管理一主多从中的数据库的方法和相应的服务器、计算机可读存储介质。通过本公开的数据库管理系统，克服了已有的数据库管理系统的缺陷。

下面，参照图4a-4b来描述本公开的数据库管理系统的架构。图4a是根据本公开实施例的数据库管理系统的架构示意图。如图4a所示，该数据库管理系统包括管理服务器410、主数据库420、从数据库430至450、与主数据库420对应的管理服务器代理模块410-2、与从数据库430对应的管理服务器代理模块410-3、与从数据库440对应的管理服务器代理模块410-4、以及与从数据库450对应的管理服务器代理模块410-5。

在图4a所示的架构中，各个数据库可以以应用程序的方式部署在某个节点处，例如，部署在某个服务器上。例如，各个数据库可以以已有的mysql的方式部署在一个服务器上。此外，与各个数据库对应的管理服务器代理模块也可以以应用程序的方式部署在某个节点处。此外，每个数据库和与每个数据库对应的管理服务器代理模块可以部署在相同节点处，也可以部署在不同节点处。此外，主数据库420和从数据库430至450可以部署在彼此不同的节点处。

此外，在图4a所示的架构中，管理服务器410分别通过管理服务器代理模块410-2至410-5对主数据库420和从数据库430至450进行操作，以实现对数据库420和从数据库430至450的管理。具体地，管理服务器410用于控制要对数据库进行的操作。当管理服务器410要对某数据库进行操作时，管理服务器410可以向与该数据库对应的管理服务器代理模块发送指令，然后，与该数据库对应的管理服务器代理模块根据接收到的指令对该数据库进行操作。例如，与该数据库对应的管理服务器代理模块可以根据接收到的指令、通过sql语言对该数据库进行操作。这里的“操作”可以包括数据库的切换、修改、创建、删除、安装、重启、卸载、启动复制、设置复制机制等中的一个或多个。通过图4a所示的架构，当主数据库发生故障时，可以从多个从数据库中选择一个作为新的主数据库，以保障数据库服务的高可用。此外，通过这种架构，当主数据库发生故障时，该主数据库具备自愈能力，从而能够有效地减少人工操作的次数，提高运维效率。此外，通过这种架构，避免了依赖ssh对数据库进行操作，满足了金融场景的合规性要求。

此外，图4a所示的数据库管理系统还可以包括系统库410-1，以便管理服务器410存储实例元数据，从而持久化实例的信息。

此外，图4a所示的数据库管理系统还可以包括一个或多个只读从数据库，以实现对从数据库的扩展，从而提供更好的读扩展能力。图4a示出了该数据库管理系统包括一个只读从数据库，即从数据库460。此外，该架构还可以包括与从数据库460对应的管理服务器代理模块410-6。

此外，在图4a所示的架构中，各个从数据库可以位于不同的地理位置。例如，从数据库430至450可以位于第一城市，从数据库460可以位于第二城市。这样部署的好处在于，第二城市的业务要读取数据库集群的数据时，只需读取第二城市的从数据库，而不需读取第一城市的从数据库，从而避免了业务读取数据库时的跨城访问，减少了从第二城市至第一城市的跨城网络延迟。

图4b是根据本公开实施例的数据库管理系统中的数据库的示意图。如图4b所示，该数据库管理系统具有五个数据库，分别为主数据库420、从数据库430至450和只读从数据库460，其中从数据库430至450位于第一城市(如图4b中的白色框所示)，只读从数据库460位于第二城市(如图4b中的灰色框所示)。主数据库420负责数据的写入，从数据库430、440、450和只读从数据库460负责数据的读取，并且从数据库430、440、450和只读从数据库460可以从主数据库420备份数据。当主数据库420发生故障时，从数据库430、440和450中的任何一个可以被提升为主数据库，而只读从数据库460不能被提升为主数据库。例如，当主数据库420发生故障时，从数据库440被提升为主数据库，则从数据库440负责数据的写入，从数据库430、450和只读从数据库460负责数据的读取，并且从数据库430、450和只读从数据库460可以从从数据库440备份数据。

需要认识到，尽管在图4a和4b中示出了一个管理服务器、一个系统库、一个主数据库和四个从数据库，但这只是示意性的。该架构可以包括更多个管理服务器、和/或更多个系统库、和/或更多个主数据库、和/或更少或更多个从数据库。

下面将结合图5来描述由图4a所示的管理服务器执行的方法。具体地，将结合图5来描述由图4a所示的管理服务器执行的主从数据库切换的方法。图5是根据本公开实施例的由管理服务器执行的方法500的流程图。在方法500中，管理服务器用于管理一个主数据库和至少两个从数据库。这里的“至少两个从数据库”可以不包括只读从数据库。例如，在图4a的示例中，“至少两个从数据库”可以包括从数据库430至450。

如图5所示，在步骤s501中，管理服务器接收主数据库的运行状态信息。主数据库的运行状态信息可以指示主数据库的运行状态。主数据库的运行状态可以为主数据库未发生故障。可替换地，主数据库的运行状态还可以为主数据库发生故障。

根据本公开的一个示例，当部署主数据库和与主数据库对应的管理服务器代理模块的节点未发生故障时，管理服务器可以从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。在该示例中，管理服务器可以周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。可替换地，管理服务器可以非周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。

在管理服务器周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，管理服务器可以周期性地从与主数据库对应的管理服务器代理模块接收主数据库的心跳信息，其中该主数据库的心跳信息包括主数据库的运行状态信息。

例如，可以预先设置管理服务器和主数据库之间的心跳机制。在该心跳机制下，主数据库可以作为管理服务器的客户端而周期性地向管理服务器上报主数据库的心跳信息，并且该主数据库的心跳信息包括主数据库的运行状态信息。具体地，主数据库可以根据自身的运行状态周期性地生成主数据库的运行状态信息，并将主数据库的运行状态信息包含在主数据库的心跳信息中。然后，与主数据库对应的管理服务器代理模块可以向管理服务器发送主数据库的心跳信息。相应地，管理服务器可以从与主数据库对应的管理服务器代理模块接收主数据库的心跳信息，以接收主数据库的运行状态信息。

在管理服务器非周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，管理服务器可以向与主数据库对应的管理服务器代理模块轮询主数据库的运行状态信息。

然而，当部署主数据库和与主数据库对应的管理服务器代理模块的节点发生故障时，管理服务器可能无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。因此，管理服务器可以预先设置等待时间(例如，24秒)，作为当管理服务器无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息时管理服务器要等待的时间。当在等待时间内管理服务器仍无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息时，可以确定部署主数据库和与主数据库对应的管理服务器代理模块的节点发生了故障，则管理服务器可以借助从数据库来接收主数据库的运行状态信息。反之，当在等待时间内管理服务器从与主数据库对应的管理服务器代理模块接收到了主数据库的运行状态信息时，管理服务器没必要借助从数据库来接收主数据库的运行状态信息。

下面将描述管理服务器借助从数据库来接收主数据库的运行状态信息的示例。根据本公开的一个示例，管理服务器可以从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。在该示例中，管理服务器可以周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。可替换地，管理服务器可以非周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。

在管理服务器周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，管理服务器可以周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收至少一个从数据库的心跳信息，其中该至少一个从数据库的心跳信息包括主数据库的运行状态信息。

例如，可以预先设置管理服务器和从数据库之间的心跳机制。在该心跳机制下，从数据库可以作为管理服务器的客户端而周期性地向管理服务器上报从数据库的心跳信息，并且该从数据库的心跳信息包括主数据库的运行状态信息。具体地，从数据库可以周期性地检测主数据库的运行状态，然后根据主数据库的运行状态生成主数据库的运行状态信息，并将主数据库的运行状态信息包含在从数据库的心跳信息中。然后，与从数据库对应的管理服务器代理模块可以向管理服务器发送从数据库的心跳信息。相应地，管理服务器可以从与从数据库对应的管理服务器代理模块接收从数据库的心跳信息，以接收主数据库的运行状态信息。

此外，从数据库的心跳信息还可以包括从数据库的运行状态信息。具体地，从数据库可以根据自身的运行状态周期性地生成从数据库的运行状态信息，并将从数据库的运行状态信息包含在从数据库的心跳信息中。然后，与从数据库对应的管理服务器代理模块可以向管理服务器发送从数据库的心跳信息。相应地，管理服务器可以从与从数据库对应的管理服务器代理模块接收从数据库的心跳信息，以接收从数据库的运行状态信息。

在管理服务器非周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，管理服务器可以向与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块轮询主数据库的运行状态信息。例如，管理服务器可以向与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块请求主数据库的运行状态信息。然后，从数据库可以响应于该请求而检测主数据库的运行状态，然后根据主数据库的运行状态生成主教据库的运行状态信息。然后，与从数据库对应的管理服务器代理模块可以向管理服务器发送主数据库的运行状态信息。

返回图5，在步骤s502中，管理服务器根据所述主数据库的运行状态信息确定所述主数据库的运行状态。当主数据库的运行状态信息指示主数据库未发生故障时，管理服务器可以确定主数据库的运行状态为主数据库未发生故障。可替换地，当主数据库的运行状态信息指示主数据库发生故障时，管理服务器可以确定主数据库的运行状态为主数据库发生故障。

然后，在步骤s503中，当管理服务器确定所述主数据库的运行状态为所述主数据库发生故障时，管理服务器从所述至少两个从数据库中选择一个从数据库作为新的主数据库。例如，管理服务器可以从至少两个从数据库确定候选的从数据库，然后从所述候选的从数据库中选择一个从数据库作为新的主数据库。这里的“候选的从数据库”可以是一个或多个从数据库。

下面将描述管理服务器从至少两个从数据库确定候选的从数据库的一个示例性流程。

根据本公开的一个示例，首先，管理服务器可以确定至少两个从数据库中其事务标识被所述管理服务器获取的从数据库。具体地，管理服务器可以预先设置获取事务标识的超时时间(例如，5秒)。管理服务器可以确定至少两个从数据库中其事务标识在该超时时间内被所述管理服务器获取的从数据库。

例如，在图4a的示例中，管理服务器在超时时间内获取到了从数据库430的事务标识以及从数据库440的事务标识而没有获取到从数据库450的事务标识，则管理服务器可以确定其事务标识在该超时时间内被所述管理服务器获取的从数据库为从数据库430和从数据库440。

上面所描述的“事务标识”可以包括主数据库执行过的事务的标识信息和从数据库执行过的事务的标识信息。例如，事务标识可以是全局事务标识符(globaltransactionidentifiers，gtid)。管理服务器可以根据从数据库的事务标识确定主数据库执行过的事务以及从数据库执行过的事务，从而确定该从数据库的数据与主数据库的数据的一致性(或称为重合度)。例如，当主数据库执行过的事务和从数据库执行过的事务完全相同时，管理服务器可以确定该从数据库的数据与主数据库的数据相同。当主数据库执行过的事务和从数据库执行过的事务部分相同时，管理服务器可以确定该从数据库的数据与主数据库的数据部分相同。

此外，对于至少两个从数据库中其事务标识没有被管理服务器获取的从数据库，管理服务器可以从数据库集群删除这些从数据库，例如，将这些从数据库踢出数据库集群。例如，在图4a的示例中，管理服务器在超时时间内获取到了从数据库430的事务标识以及从数据库440的事务标识而没有获取到从数据库450的事务标识，则管理服务器可以将从数据库450踢出数据库集群。

在管理服务器确定了至少两个从数据库中其事务标识被所述管理服务器获取的从数据库之后，管理服务器可以判断所确定的从数据库的数量是否大于所述至少两个从数据库的数量的预定比例(例如，二分之一)。当所确定的从数据库的数量大于所述至少两个从数据库的数量的预定比例时，管理服务器可以将所确定的从数据库确定为候选的从数据库。当所确定的从数据库的数量小于所述至少两个从数据库的数量的预定比例时，管理服务器不会将所确定的从数据库确定为候选的从数据库。

例如，在图4a的示例中，管理服务器所确定的从数据库为从数据库430和从数据库440。由于管理服务器所确定的从数据库的数量为2，至少两个从数据库的数量为3，并且所确定的从数据库的数量大于至少两个从数据库的数量的二分之一，则管理服务器可以将从数据库430和从数据库440确定为候选的从数据库。

又例如，在图4a的示例中，管理服务器所确定的从数据库为从数据库430。由于管理服务器所确定的从数据库的数量为1，至少两个从数据库的数量为3，并且所确定的从数据库的数量小于至少两个从数据库的数量的二分之一，则管理服务器不会将从数据库430确定为候选的从数据库。

在管理服务器从至少两个从数据库确定候选的从数据库之后，管理服务器可以从所述候选的从数据库中选择一个从数据库作为新的主数据库。根据本公开的一个示例，每个从数据库可以具有其充当主数据库的优先级。例如，管理服务器可以预先给每个从数据库设置其充当主数据库的优先级。例如，在图4a的示例中，管理服务器可以预先给从数据库430设置其充当主数据库的优先级为1，给从数据库440设置其充当主数据库的优先级为2，以及给从数据库450设置其充当主数据库的优先级为3。

在该示例中，管理服务器可以至少根据所述候选的从数据库中的每个从数据库的优先级，从所述候选的从数据库中选择一个从数据库作为新的主数据库。例如，管理服务器可以根据候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择一个从数据库作为新的主数据库。

管理服务器在选择新的主数据库时考虑了从数据库的优先级和事务标识二者，是有必要的。这是由于，在理想情况下，具有最高优先级的从数据库可能具有最大事务标识，即具有最高优先级的从数据库的数据与主数据库的数据的重合度是最高的。因此，当管理服务器将具有最高优先级的从数据库作为新的主数据库时，其他从数据库可以从具有最高优先级的从数据库备份数据，从而保证数据库集群的数据一致性。然而，在非理想情况下，具有最高优先级的从数据库可能不具有最大事务标识，即具有最高优先级的从数据库的数据与主数据库的数据的重合度不是最高的。因此，当管理服务器将具有最高优先级的从数据库作为新的主数据库时，虽然其他从数据库可以从具有最高优先级的从数据库备份数据，但是并不能保证数据库集群的数据一致性。因此，管理服务器可以根据所述候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择具有最高优先级的从数据库作为新的主数据库，从而保证数据库集群的数据一致性。

下面将描述管理服务器根据候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择一个从数据库作为新的主数据库的一个示例性流程。

管理服务器可以判断候选的从数据库中具有最高优先级的从数据库是否具有最大事务标识。根据本公开的一个示例，当具有最高优先级的从数据库具有最大事务标识时，管理服务器可以将具有最高优先级的从数据库作为新的主数据库。

例如，在图4a的示例中，候选的从数据库为从数据库430和从数据库440，并且从数据库430充当主数据库的优先级为1，从数据库440充当主数据库的优先级为2，从数据库440具有最大事务标识，则管理服务器可以将从数据库440作为新的主数据库。

根据本公开的另一示例，当具有最高优先级的从数据库不具有最大事务标识时，管理服务器可以控制具有最高优先级的从数据库具有最大事务标识，然后将具有最高优先级的从数据库作为新的主数据库，从而保证数据库集群的数据一致性。

具体地，当具有最高优先级的从数据库不具有最大事务标识时，管理服务器可以通过与具有最高优先级的从数据库对应的管理服务器代理模块，控制具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据，以使得具有最高优先级的从数据库具有最大事务标识。例如，当具有最高优先级的从数据库不具有最大事务标识时，管理服务器可以向与具有最高优先级的从数据库对应的管理服务器代理模块发送关于具有最大事务标识的从数据库的信息，以便与具有最高优先级的从数据库对应的管理服务器代理模块控制具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据。当具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据之后，具有最高优先级的从数据库能够具有最大事务标识，则管理服务器将具有最高优先级的从数据库作为新的主数据库。

例如，在图4a的示例中，候选的从数据库为从数据库430和从数据库440，并且从数据库430充当主数据库的优先级为1，从数据库440充当主数据库的优先级为2，从数据库430具有最大事务标识，则管理服务器可以向与从数据库440对应的管理服务器代理模块410-4发送关于从数据库430的信息，以便管理服务器代理模块410-4控制从数据库440从从数据库430备份数据。当从数据库440从从数据库430备份数据之后，从数据库440能够具有最大事务标识，则管理服务器可以将备份数据后的从数据库440作为新的主数据库。

此外，正如上文所描述的，主数据库负责数据的写入，从数据库负责数据的读取，并且从数据库可以从主数据库复制数据。为了禁止向从数据库写入数据，管理服务器可以给从数据库设置复制属性(例如超级只读(superreadonly)选项)，以限制对从数据库执行写入操作。例如，在图4a的示例中，管理服务器410可以给从数据库430至450均设置superreadonly选项。

在本公开中，当管理服务器要将某个从数据库作为新的主数据库时，可以先去除从数据库的复制属性。例如，在图4a的示例中，当管理服务器要将从数据库440作为新的主数据库时，可以先去除从数据库440的superreadonly选项。

返回图5，在步骤s504中，管理服务器向分别与所述至少两个从数据库中的其他从数据库对应的管理服务器代理模块发送关于新的主数据库的信息，通过与所述其他从数据库对应的管理服务器代理模块控制所述其他从数据库从新的主数据库备份数据。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，管理服务器可以向与从数据库430对应的管理服务器代理模块410-3、与从数据库450对应的管理服务器代理模块410-5发送关于从数据库440的信息。管理服务器通过管理服务器代理模块410-3可以控制从数据库430从从数据库440备份数据以及管理服务器代理模块410-5控制从数据库450从从数据库440备份数据。

上面所描述的“关于新的主数据库的信息”可以为新的主数据库的标识信息，例如，新的主数据库的静态ip地址(或者固定ip地址)。从数据库可以通过新的主数据库的静态ip地址，从新的主数据库备份数据。例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，从数据库430和从数据库450可以通过从数据库440的静态ip地址，从从数据库440备份数据。

在步骤s504之后，方法500还可以包括步骤s505：管理服务器可以向与所述新的主数据库对应的管理服务器代理模块发送配置信息，其中所述配置信息指示所述新的主数据库与所述其他从数据库之间的复制机制，以便与所述新的主数据库对应的管理服务器代理模块控制所述新的主数据库采用所述复制机制。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，管理服务器可以向与从数据库440对应的管理服务器代理模块410-4发送配置信息，其中该配置信息指示作为新的主数据库的从数据库440与从数据库430、从数据库450之间的复制机制，以便管理服务器代理模块410-4控制作为新的主数据库的从数据库440采用该复制机制。

上面所描述的“复制机制”可以包括全同步复制机制、异步复制机制、或半同步复制机制等中的任何一种。在主数据库采用全同步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待所有的从数据库从主数据库备份数据后再向用户返回确认消息。在主数据库采用异步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，立刻向用户返回确认消息，而无需等待从数据库从主数据库备份数据后再向用户返回确认消息。在主数据库采用半同步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待部分从数据库(可通过参数ackcount设置从数据库的数量)从主数据库备份数据后再向用户返回确认消息。

在本公开中，在新的主数据库与从数据库之间的复制机制为半同步复制机制的情形中，新的主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待一个或多个从数据库从新的主数据库备份数据后再向用户返回确认消息，从而保证新的数据库集群的数据一致性。通过采用半同步复制机制，即使新的数据库集群再次遭受打击，例如新的数据库集群中的主数据库宕机，但由于新的数据库集群中的从数据库与主数据库的数据保持一致，因此，新的数据库集群中的从数据库仍能保证数据库的高可用。因此，通过采用半同步复制机制，可以赋予数据库集群抗二次打击的能力。

此外，在本公开中，管理服务器可以给每个数据库集群配置动态ip(例如，浮动ip)，以便将该动态ip作为数据库集群对外提供服务的统一ip。用户可以通过该动态ip访问数据库集群，例如通过该动态ip向数据库集群写入数据。在这种情形中，在步骤s505之后，方法500还可以包括步骤s506：管理服务器可以将数据库集群的动态ip绑定到新的主数据库。通过这种方式，用户可以通过动态ip向数据库集群写入数据，而无需知道数据库集群中的哪个数据库为主数据库，从而提高了用户的体验度。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之前，管理服务器可以将数据库集群的浮动ip绑定到主数据库410。在管理服务器将从数据库440作为新的主数据库之后，在步骤s506中，管理服务器可以将数据库集群的浮动ip绑定到从数据库440。

通过上述由管理服务器执行的方法，在数据库集群中的主数据库宕机后，管理服务器可以将某个从数据库提升为新的主数据库，从而使得数据库集群恢复为服务可用状态，以继续为用户提供服务。然而，本公开不限于此。管理服务器还可以修复宕机的主数据库。根据本公开的一个示例，在步骤s506之后，方法500还可以包括步骤s507：管理服务器可以向与所述主数据库对应的管理服务器代理模块发送修复信息，以便与所述主数据库对应的管理服务器代理模块修复所述主数据库。这里的“修复信息”可以包括数据库的重启指令以及关于新的主数据库的信息。

例如，在图4a的示例中，在主数据库420宕机之后，管理服务器可以向与主数据库420相对应的管理服务器代理模块410-2发送修复信息，使得管理服务器代理模块410-2控制主数据库420关闭并重启以及控制重启成功后的主数据库420从新的主数据库备份数据，以便管理服务器代理模块410-2修复主数据库420。

在该示例中，管理服务器可以将修复后的主数据库加入数据库集群。例如，管理服务器可以将修复后的主数据库420作为从数据库440(已被提升为主数据库)的从数据库而加入数据库集群。可替换地，管理服务器可以将修复后的主数据库从数据库集群中删除。

此外，在该示例中，管理服务器可以对修复后的主数据库进行数据一致性的校验，即进行二次检查，以保证数据库集群的数据一致性。此外，管理服务器还可以将数据库实例设置为可用状态，以便提供数据库服务。

此外，在本公开中，管理服务器可以向管理服务器的操作者显示通知信息，以便管理服务器的操作者获知数据库集群的运行状态。例如，在图4a的示例中，当主数据库420宕机时，管理服务器可以向管理服务器的操作者显示报警信息，以便管理服务器的操作者获知主数据库420宕机。又例如，当数据库集群中的主数据库宕机且管理服务器无法把从数据库提升为新的主数据库时，管理服务器可以向管理服务器的操作者显示报警信息，以便向管理服务器的操作者通知无法进行主从切换，从而将数据库集群设置为维护状态。又例如，在图4a的示例中，在主数据库420宕机后且被修复后，管理服务器可以向管理服务器的操作者显示报警信息，以便管理服务器的操作者获知主数据库420已被修复。

通过本公开实施例的方法，当主数据库发生故障时，可以从多个从数据库中选择一个作为新的主数据库，以保障数据库服务的高可用。此外，通过本公开实施例的方法，管理服务器通过管理服务器代理模块对数据库进行操作，避免了依赖ssh对数据库进行操作，满足了金融场景的合规性要求。此外，通过本公开实施例的方法，实现了对从数据库的扩展，从而提供更好的读扩展能力。

下面，将结合图6来描述应用图4a所示的架构的一个示例性的具体流程。图6是根据本公开实施例的应用图4a所示的架构的一个示例性的具体流程。如图6所示，在步骤s1中，管理服务器通过主数据库和从数据库上报的心跳发现主数据库宕机(在一主三从的情况下一定是先发现主数据库宕机)。然后，在步骤s2中，管理服务器尝试从所有的从数据库获取gtid。然后，在步骤s3中，管理服务器确定是否正确获取了一半以上的从数据库的gtid，并且可以将没有正确获取其gtid的从数据库踢出数据库集群。然后，在步骤s4中，管理服务器判断具有最高优先级的从数据库是否具有最大的gtid。当具有最高优先级的从数据库具有最大的gtid时，在步骤s5中，管理服务器将具有最高优先级的从数据库提升为主数据库，并去除该从数据库的superreadonly选项。当具有最高优先级的从数据库不具有最大的gtid时，在步骤s12中，管理服务器控制具有最高优先级的从数据库连上具有最大gtid的从数据库以复制数据，并在复制完成后执行步骤s5。然后，在步骤s6中，管理服务器控制其他从数据库连上新的主数据库进行复制。然后，在步骤s7中，管理服务器可以将该高可用数据库转为同步复制，并将浮动ip绑定到新的主数据库，以使得数据库服务恢复可用。然后，在步骤s8中，管理服务器可以修复旧的主数据库，具体地，通过kill指令和重启指令重启旧的主数据库，使旧的主数据库成功重启。然后，在步骤s9中，管理服务器控制旧的主数据库连上新的主数据库以复制数据。然后，在步骤s10中，如果需要的话，管理服务器可以修改ackcount参数。然后，在步骤s11中，管理服务器可以将数据库实例设置为可用状态。

此外，在图6中，当管理服务器未能成功执行步骤s3～s7时，管理服务器可以报警，以将数据库设置为维护状态。此外，在图6中，当管理服务器执行步骤s9～s10后，如果数据库集群为一主一从，则管理服务器可以报警并将数据库设置为维护状态，否则，管理服务器也可以报警并将旧的主数据库踢出数据集群后将旧的主数据库设置为维护状态，以防止二次打击。

上文所描述的实施例是管理服务器管理数据库集群中的主数据库和/或从数据库以实现数据库高可用的实施例。然而本公开不限于此。根据本公开的另一实施例，可以实现管理服务器的高可用。在该实施例中，可以部署多个管理服务器。虽然部署了多个管理服务器，但是，在某一时刻，仅一个管理服务器用于管理数据库集群中的主数据库和/或从数据库。在本公开中，可以将在当前时刻管理数据库集群中的主数据库和/或从数据库的管理服务器称为工作管理服务器。

根据本公开的一个示例，当工作管理服务器发生故障时，其他管理服务器可以充当工作管理服务器。具体地，可以部署用于管理多个管理服务器的管理模块。其他管理服务器可以借助于管理模块来充当工作管理服务器。这里的“管理模块”可以是已有的zookeeper应用程序。

例如，当工作管理服务器发生故障时，管理模块可以从其他管理服务器中选择一个来充当工作管理服务器。具体地，管理服务器可以根据各个管理服务器的标识(例如，id)，从多个管理服务器中选择一个来充当工作管理服务器。例如，管理服务器可以从多个管理服务器中选择具有最小id的管理服务器来充当工作管理服务器。在该示例中，当工作管理服务器发生故障时，管理模块可以从剩余管理服务器中选择具有最小id的管理服务器来充当工作管理服务器。

又例如，当工作管理服务器发生故障时，可以不由管理模块来选择一个管理服务器来充当工作管理服务器，而是其他管理服务器自主地尝试充当工作管理服务器。具体地，管理模块可以将工作管理服务器发生故障通知给其他管理服务器，然后，其他管理服务器可以尝试充当工作管理服务器。例如，管理模块可以检测工作管理服务器的运行状态，并且当工作管理服务器发生故障时，该管理模块可以将工作管理服务器发生故障通知给其他管理服务器，然后，其他管理服务器可以尝试充当工作管理服务器。在其他管理服务器尝试成为工作管理服务器时，其他管理服务器中的各个管理服务器可以通过各自的标识信息确定自身是否可以充当工作管理服务器。例如，其他管理服务器中的一个管理服务器可以判断自身的id是否小于其他管理服务器中的剩余管理服务器的id，如果是，则该管理服务器可以充当工作管理服务器。

通过该实施例，在工作管理服务器发生故障时，可以由另一个管理服务器充当工作管理服务器，以继续管理数据库集群中的主数据库和/或从数据库，从而实现了管理服务器的高可用。

根据本公开的又一实施例，可以实现系统库的高可用。在该实施例中，可以配置多个系统库。虽然配置了多个系统库，但是，在某一时刻，管理服务器只使用多个系统库中的一个系统库。

根据本公开的一个示例，可以给多个系统库中的各个系统库配置ip地址。在这种情形中，管理服务器可以根据各个系统库的ip地址，从多个系统库中选择一个系统库来使用。例如，管理服务器可以从多个系统库中选择具有最小ip地址的系统库来使用。在该示例中，当管理服务器使用的当前系统库发生故障时，管理服务器可以从剩余系统库中选择具有最小ip地址的系统库来使用。

通过该实施例，在当前的系统库发生故障时，管理服务器可以使用另一个系统库来存储实例元数据，从而实现了系统库的高可用。

下面，将结合图7来描述实现管理服务器高可用和系统库高可用的架构示意图。图7是根据本公开实施例的实现管理服务器高可用和系统库高可用的架构示意图。如图7所示，可以部署五个管理服务器，分别为管理服务器1至5，其中管理服务器1至3可以位于深圳，管理服务器4至5可以位于上海。此外，可以在每个管理服务器上部署zookeeper。此外，可以部署五个系统库，分别为元数据库(matabatabase)1至5。此外，可以部署要被管理服务器管理的数据库集群，该数据库集群包括数据库mysql1至6。此外，可以部署与数据库mysql1至6对应的管理服务器代理模块agent。

如图7所示，管理服务器3使用系统库1来管理数据库mysql1至6。当管理服务器3发生故障时，zookeeper可以检测到管理服务器3发生故障，并且可以将管理服务器3发生故障的消息通知给管理服务器1、2、4和5。然后，管理服务器1、2、4和5中的一个管理服务器可以接替管理服务器3，来管理数据库mysql1至6。此外，当系统库1发生故障时，管理服务器3可以使用系统库2至5中的一个系统库来管理数据库mysql1至6。

此外，在图7中，管理服务器的操作者可以通过网络应用程序编程接口(webapplicationprogramminginterface，webapi)来操作管理服务器。

以下，参照图8来描述根据本公开实施例的用于管理数据库的装置。该装置可以是管理服务器。图8示出了根据本公开实施例的管理服务器800的结构示意图。由于管理服务器800的功能与在上文中参照图5描述的方法的细节相同，因此在这里为了简单起见，省略对相同内容的详细描述。如图8所示，管理服务器800包括：接收单元810，被配置为接收主数据库的运行状态信息；确定单元820，被配置为根据所述主数据库的运行状态信息确定所述主数据库的运行状态；选择单元830，被配置为当所述确定单元确定所述主数据库的运行状态为所述主数据库发生故障时，从至少两个从数据库中选择一个从数据库作为新的主数据库；以及发送单元840，被配置为向分别与所述至少两个从数据库中的其他从数据库对应的管理服务器代理模块发送关于新的主数据库的信息，通过与所述其他从数据库对应的管理服务器代理模块控制所述其他从数据库从新的主数据库备份数据。除了这四个单元以外，管理服务器800还可以包括其他部件，然而，由于这些部件与本公开实施例的内容无关，因此在这里省略其图示和描述。这里的“至少两个从数据库”可以不包括只读从数据库。例如，在图4a的示例中，“至少两个从数据库”可以包括从数据库430至450。

在本公开中，主数据库的运行状态信息可以指示主数据库的运行状态。主数据库的运行状态可以为主数据库未发生故障。可替换地，主数据库的运行状态还可以为主数据库发生故障。

根据本公开的一个示例，当部署主数据库和与主数据库对应的管理服务器代理模块的节点未发生故障时，接收单元810可以从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。在该示例中，接收单元810可以周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。可替换地，接收单元810可以非周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。

在接收单元810周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，接收单元810可以周期性地从与主数据库对应的管理服务器代理模块接收主数据库的心跳信息，其中该主数据库的心跳信息包括主数据库的运行状态信息。

例如，可以预先设置管理服务器和主数据库之间的心跳机制。在该心跳机制下，主数据库可以作为管理服务器的客户端而周期性地向管理服务器上报主数据库的心跳信息，并且该主数据库的心跳信息包括主数据库的运行状态信息。具体地，主数据库可以根据自身的运行状态周期性地生成主数据库的运行状态信息，并将主数据库的运行状态信息包含在主数据库的心跳信息中。然后，与主数据库对应的管理服务器代理模块可以向管理服务器发送主数据库的心跳信息。相应地，接收单元810可以从与主数据库对应的管理服务器代理模块接收主数据库的心跳信息，以接收主数据库的运行状态信息。

在接收单元810非周期性地从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，接收单元810可以向与主数据库对应的管理服务器代理模块轮询主数据库的运行状态信息。

然而，当部署主数据库和与主数据库对应的管理服务器代理模块的节点发生故障时，接收单元810可能无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息。因此，接收单元810可以预先设置等待时间(例如，24秒)，作为当接收单元810无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息时接收单元810要等待的时间。当在等待时间内接收单元810仍无法从与主数据库对应的管理服务器代理模块接收主数据库的运行状态信息时，可以确定部署主数据库和与主数据库对应的管理服务器代理模块的节点发生了故障，则接收单元810可以借助从数据库来接收主数据库的运行状态信息。反之，当在等待时间内接收单元810从与主数据库对应的管理服务器代理模块接收到了主数据库的运行状态信息时，接收单元810没必要借助从数据库来接收主数据库的运行状态信息。

下面将描述接收单元810借助从数据库来接收主数据库的运行状态信息的示例。根据本公开的一个示例，接收单元810可以从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。在该示例中，接收单元810可以周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。可替换地，接收单元810可以非周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息。

在接收单元810周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，接收单元810可以周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收至少一个从数据库的心跳信息，其中该至少一个从数据库的心跳信息包括主数据库的运行状态信息。

例如，可以预先设置管理服务器和从数据库之间的心跳机制。在该心跳机制下，从数据库可以作为管理服务器的客户端而周期性地向管理服务器上报从数据库的心跳信息，并且该从数据库的心跳信息包括主数据库的运行状态信息。具体地，从数据库可以周期性地检测主数据库的运行状态，然后根据主数据库的运行状态生成主数据库的运行状态信息，并将主数据库的运行状态信息包含在从数据库的心跳信息中。然后，与从数据库对应的管理服务器代理模块可以向管理服务器发送从数据库的心跳信息。相应地，接收单元810可以从与从数据库对应的管理服务器代理模块接收从数据库的心跳信息，以接收主数据库的运行状态信息。

此外，从数据库的心跳信息还可以包括从数据库的运行状态信息。具体地，从数据库可以根据自身的运行状态周期性地生成从数据库的运行状态信息，并将从数据库的运行状态信息包含在从数据库的心跳信息中。然后，与从数据库对应的管理服务器代理模块可以向管理服务器发送从数据库的心跳信息。相应地，接收单元810可以从与从数据库对应的管理服务器代理模块接收从数据库的心跳信息，以接收从数据库的运行状态信息。

在接收单元810非周期性地从与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块接收主数据库的运行状态信息的情形中，接收单元810可以向与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块轮询主数据库的运行状态信息。例如，接收单元810可以向与至少两个从数据库中的至少一个从数据库对应的管理服务器代理模块请求主数据库的运行状态信息。然后，从数据库可以响应于该请求而检测主数据库的运行状态，然后根据主数据库的运行状态生成主数据库的运行状态信息。然后，与从数据库对应的管理服务器代理模块可以向接收单元810发送主数据库的运行状态信息。

此外，在本公开中，当主数据库的运行状态信息指示主数据库未发生故障时，确定单元820可以确定主数据库的运行状态为主数据库未发生故障。可替换地，当主数据库的运行状态信息指示主数据库发生故障时，确定单元820可以确定主数据库的运行状态为主数据库发生故障。

此外，在本公开中，当确定单元820确定所述主数据库的运行状态为所述主数据库发生故障时，选择单元830从所述至少两个从数据库中选择一个从数据库作为新的主数据库。例如，选择单元830可以从至少两个从数据库确定候选的从数据库，然后从所述候选的从数据库中选择一个从数据库作为新的主数据库。这里的“候选的从数据库”可以是一个或多个从数据库。

下面将描述选择单元830从至少两个从数据库确定候选的从数据库的一个示例性流程。

根据本公开的一个示例，首先，选择单元830可以确定至少两个从数据库中其事务标识被所述管理服务器获取的从数据库。具体地，选择单元830可以预先设置获取事务标识的超时时间(例如，5秒)。选择单元830可以确定至少两个从数据库中其事务标识在该超时时间内被所述管理服务器获取的从数据库。

例如，在图4a的示例中，管理服务器在超时时间内获取到了从数据库430的事务标识以及从数据库440的事务标识而没有获取到从数据库450的事务标识，则选择单元830可以确定其事务标识在该超时时间内被所述管理服务器获取的从数据库为从数据库430和从数据库440。

上面所描述的“事务标识”可以包括主数据库执行过的事务的标识信息和从数据库执行过的事务的标识信息。例如，事务标识可以是全局事务标识符(globaltransactionidentifiers，gtid)。管理服务器可以根据从数据库的事务标识确定主数据库执行过的事务以及从数据库执行过的事务，从而确定该从数据库的数据与主数据库的数据的一致性(或称为重合度)。例如，当主数据库执行过的事务和从数据库执行过的事务完全相同时，管理服务器可以确定该从数据库的数据与主数据库的数据相同。当主数据库执行过的事务和从数据库执行过的事务部分相同时，管理服务器可以确定该从数据库的数据与主数据库的数据部分相同。

此外，对于至少两个从数据库中其事务标识没有被管理服务器获取的从数据库，管理服务器可以从数据库集群删除这些从数据库，例如，将这些从数据库踢出数据库集群。例如，在图4a的示例中，管理服务器在超时时间内获取到了从数据库430的事务标识以及从数据库440的事务标识而没有获取到从数据库450的事务标识，则选择单元830可以将从数据库450踢出数据库集群。

在选择单元830确定了至少两个从数据库中其事务标识被所述管理服务器获取的从数据库之后，选择单元830可以判断所确定的从数据库的数量是否大于所述至少两个从数据库的数量的预定比例(例如，二分之一)。当所确定的从数据库的数量大于所述至少两个从数据库的数量的预定比例时，选择单元830可以将所确定的从数据库确定为候选的从数据库。当所确定的从数据库的数量小于所述至少两个从数据库的数量的预定比例时，选择单元830不会将所确定的从数据库确定为候选的从数据库。

例如，在图4a的示例中，管理服务器所确定的从数据库为从数据库430和从数据库440。由于管理服务器所确定的从数据库的数量为2，至少两个从数据库的数量为3，并且所确定的从数据库的数量大于至少两个从数据库的数量的二分之一，则选择单元830可以将从数据库430和从数据库440确定为候选的从数据库。

又例如，在图4a的示例中，管理服务器所确定的从数据库为从数据库430。由于管理服务器所确定的从数据库的数量为1，至少两个从数据库的数量为3，并且所确定的从数据库的数量小于至少两个从数据库的数量的二分之一，则选择单元830不会将从数据库430确定为候选的从数据库。

在选择单元830从至少两个从数据库确定候选的从数据库之后，选择单元830可以从所述候选的从数据库中选择一个从数据库作为新的主数据库。根据本公开的一个示例，每个从数据库可以具有其充当主数据库的优先级。例如，管理服务器可以预先给每个从数据库设置其充当主数据库的优先级。例如，在图4a的示例中，管理服务器可以预先给从数据库430设置其充当主数据库的优先级为1，给从数据库440设置其充当主数据库的优先级为2，以及给从数据库450设置其充当主数据库的优先级为3。

在该示例中，选择单元830可以至少根据所述候选的从数据库中的每个从数据库的优先级，从所述候选的从数据库中选择一个从数据库作为新的主数据库。例如，选择单元830可以根据候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择一个从数据库作为新的主数据库。

管理服务器在选择新的主数据库时考虑了从数据库的优先级和事务标识二者，是有必要的。这是由于，在理想情况下，具有最高优先级的从数据库可能具有最大事务标识，即具有最高优先级的从数据库的数据与主数据库的数据的重合度是最高的。因此，当管理服务器将具有最高优先级的从数据库作为新的主数据库时，其他从数据库可以从具有最高优先级的从数据库备份数据，从而保证数据库集群的数据一致性。然而，在非理想情况下，具有最高优先级的从数据库可能不具有最大事务标识，即具有最高优先级的从数据库的数据与主数据库的数据的重合度不是最高的。因此，当管理服务器将具有最高优先级的从数据库作为新的主数据库时，虽然其他从数据库可以从具有最高优先级的从数据库备份数据，但是并不能保证数据库集群的数据一致性。因此，管理服务器可以根据所述候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择具有最高优先级的从数据库作为新的主数据库，从而保证数据库集群的数据一致性。

下面将描述选择单元830根据候选的从数据库中的每个从数据库的优先级和事务标识，从所述候选的从数据库中选择一个从数据库作为新的主数据库的一个示例性流程。

选择单元830可以判断候选的从数据库中具有最高优先级的从数据库是否具有最大事务标识。根据本公开的一个示例，当具有最高优先级的从数据库具有最大事务标识时，选择单元830可以将具有最高优先级的从数据库作为新的主数据库。

例如，在图4a的示例中，候选的从数据库为从数据库430和从数据库440，并且从数据库430充当主数据库的优先级为1，从数据库440充当主数据库的优先级为2，从数据库440具有最大事务标识，则选择单元830可以将从数据库440作为新的主数据库。

根据本公开的另一示例，当具有最高优先级的从数据库不具有最大事务标识时，选择单元830可以控制具有最高优先级的从数据库具有最大事务标识，然后将具有最高优先级的从数据库作为新的主数据库，从而保证数据库集群的数据一致性。

具体地，当具有最高优先级的从数据库不具有最大事务标识时，选择单元830可以通过与具有最高优先级的从数据库对应的管理服务器代理模块，控制具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据，以使得具有最高优先级的从数据库具有最大事务标识。例如，当具有最高优先级的从数据库不具有最大事务标识时，选择单元830可以向与具有最高优先级的从数据库对应的管理服务器代理模块发送关于具有最大事务标识的从数据库的信息，以便与具有最高优先级的从数据库对应的管理服务器代理模块控制具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据。当具有最高优先级的从数据库从具有最大事务标识的从数据库备份数据之后，具有最高优先级的从数据库能够具有最大事务标识，则选择单元830将具有最高优先级的从数据库作为新的主数据库。

例如，在图4a的示例中，候选的从数据库为从数据库430和从数据库440，并且从数据库430充当主数据库的优先级为1，从数据库440充当主数据库的优先级为2，从数据库430具有最大事务标识，则管理服务器可以向与从数据库440对应的管理服务器代理模块410-4发送关于从数据库430的信息，以便管理服务器代理模块410-4控制从数据库440从从数据库430备份数据。当从数据库440从从数据库430备份数据之后，从数据库440能够具有最大事务标识，则选择单元830可以将备份数据后的从数据库440作为新的主数据库。

此外，正如上文所描述的，主数据库负责数据的写入，从数据库负责数据的读取，并且从数据库可以从主数据库复制数据。为了禁止向从数据库写入数据，管理服务器可以给从数据库设置复制属性(例如超级只读(superreadonly)选项)，以限制对从数据库执行写入操作。例如，在图4a的示例中，管理服务器410可以给从数据库430至450均设置superreadonly选项。

在本公开中，当选择单元830要将某个从数据库作为新的主数据库时，可以先去除从数据库的复制属性。例如，在图4a的示例中，当选择单元830要将从数据库440作为新的主数据库时，可以先去除从数据库440的superreadonly选项。

此外，在本公开中，发送单元840向分别与所述至少两个从数据库中的其他从数据库对应的管理服务器代理模块发送关于新的主数据库的信息，通过与所述其他从数据库对应的管理服务器代理模块控制所述其他从数据库从新的主数据库备份数据。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，发送单元840可以向与从数据库430对应的管理服务器代理模块410-3、与从数据库450对应的管理服务器代理模块410-5发送关于从数据库440的信息。管理服务器可以通过管理服务器代理模块410-3控制从数据库430从从数据库440备份数据以及管理服务器代理模块410-5控制从数据库450从从数据库440备份数据。

上面所描述的“关于新的主数据库的信息”可以为新的主数据库的标识信息，例如，新的主数据库的静态ip地址(或者固定ip地址)。从数据库可以通过新的主数据库的静态ip地址，从新的主数据库备份数据。例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，从数据库430和从数据库450可以通过从数据库440的静态ip地址，从从数据库440备份数据。

此外，发送单元840可以向与所述新的主数据库对应的管理服务器代理模块发送配置信息，其中所述配置信息指示所述新的主数据库与所述其他从数据库之间的复制机制，以便与所述新的主数据库对应的管理服务器代理模块控制所述新的主数据库采用所述复制机制。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之后，发送单元840可以向与从数据库440对应的管理服务器代理模块410-4发送配置信息，其中该配置信息指示作为新的主数据库的从数据库440与从数据库430、从数据库450之间的复制机制，以便管理服务器代理模块410-4控制作为新的主数据库的从数据库440采用该复制机制。

上面所描述的“复制机制”可以包括全同步复制机制、异步复制机制、或半同步复制机制等中的任何一种。在主数据库采用全同步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待所有的从数据库从主数据库备份数据后再向用户返回确认消息。在主数据库采用异步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，立刻向用户返回确认消息，而无需等待从数据库从主数据库备份数据后再向用户返回确认消息。在主数据库采用半同步复制机制的情形中，主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待部分从数据库(可通过参数ackcount设置从数据库的数量)从主数据库备份数据后再向用户返回确认消息。

在本公开中，在新的主数据库与从数据库之间的复制机制为半同步复制机制的情形中，新的主数据库可以根据用户指令执行数据的写入操作，并且在执行完数据的写入操作后，不是立刻向用户返回确认消息，而是等待一个或多个从数据库从新的主数据库备份数据后再向用户返回确认消息，从而保证新的数据库集群的数据一致性。通过采用半同步复制机制，即使新的数据库集群再次遭受打击，例如新的数据库集群中的主数据库宕机，但由于新的数据库集群中的从数据库与主数据库的数据保持一致，因此，新的数据库集群中的从数据库仍能保证数据库的高可用。因此，通过采用半同步复制机制，可以赋予数据库集群抗二次打击的能力。

此外，在本公开中，管理服务器可以给每个数据库集群配置动态ip(例如，浮动ip)，以便将该动态ip作为数据库集群对外提供服务的统一ip。用户可以通过该动态ip访问数据库集群，例如通过该动态ip向数据库集群写入数据。在这种情形中，管理服务器可以将数据库集群的动态ip绑定到新的主数据库。通过这种方式，用户可以通过动态ip向数据库集群写入数据，而无需知道数据库集群中的哪个数据库为主数据库，从而提高了用户的体验度。

例如，在图4a的示例中，在管理服务器将从数据库440作为新的主数据库之前，管理服务器可以将数据库集群的浮动ip绑定到主数据库410。在管理服务器将从数据库440作为新的主数据库之后，在步骤s506中，管理服务器可以将数据库集群的浮动ip绑定到从数据库440。

通过上述由管理服务器执行的方法，在数据库集群中的主数据库宕机后，管理服务器可以将某个从数据库提升为新的主数据库，从而使得数据库集群恢复为服务可用状态，以继续为用户提供服务。然而，本公开不限于此。管理服务器还可以修复宕机的主数据库。根据本公开的一个示例，发送单元840可以向与所述主数据库对应的管理服务器代理模块发送修复信息，以便与所述主数据库对应的管理服务器代理模块修复所述主数据库。这里的“修复信息”可以包括数据库的重启指令以及关于新的主数据库的信息。

例如，在图4a的示例中，在主数据库420宕机之后，管理服务器可以向与主数据库420相对应的管理服务器代理模块410-2发送修复信息，使得管理服务器代理模块410-2控制主数据库420关闭并重启以及控制重启成功后的主数据库420从新的主数据库备份数据，以便管理服务器代理模块410-2修复主数据库420。

在该示例中，管理服务器可以将修复后的主数据库加入数据库集群。例如，管理服务器可以将修复后的主数据库420作为从数据库440(已被提升为主数据库)的从数据库而加入数据库集群。可替换地，管理服务器可以将修复后的主数据库从数据库集群中删除。

此外，在该示例中，管理服务器可以对修复后的主数据库进行数据一致性的校验，即进行二次检查，以保证数据库集群的数据一致性。此外，管理服务器还可以将数据库实例设置为可用状态，以便提供数据库服务。

此外，在本公开中，管理服务器还可以包括通知单元(图中未示出)，以向管理服务器的操作者显示通知信息，以便管理服务器的操作者获知数据库集群的运行状态。例如，在图4a的示例中，当主数据库420宕机时，通知单元可以向管理服务器的操作者显示报警信息，以便管理服务器的操作者获知主数据库420宕机。又例如，当数据库集群中的主数据库宕机且管理服务器无法把从数据库提升为新的主数据库时，通知单元可以向管理服务器的操作者显示报警信息，以便向管理服务器的操作者通知无法进行主从切换，从而将数据库集群设置为维护状态。又例如，在图4a的示例中，在主数据库420宕机后且被修复后，通知单元可以向管理服务器的操作者显示报警信息，以便管理服务器的操作者获知主数据库420已被修复。

通过本公开实施例的管理服务器，当主数据库发生故障时，可以从多个从数据库中选择一个作为新的主数据库，以保障数据库服务的高可用。此外，通过本公开实施例的方法，管理服务器通过管理服务器代理模块对数据库进行操作，避免了依赖ssh对数据库进行操作，满足了金融场景的合规性要求。此外，通过本公开实施例的方法，实现了对从数据库的扩展，从而提供更好的读扩展能力。

此外，根据本公开实施例的管理服务器也可以借助于图9所示的计算设备的架构来实现。图9示出了该计算设备的架构。如图9所示，计算设备900可以包括总线910、一个或多个cpu920、只读存储器(rom)930、随机存取存储器(ram)940、连接到网络的通信端口950、输入/输出组件960、硬盘970等。计算设备900中的存储设备，例如rom930或硬盘970可以存储计算机处理和/或通信使用的各种数据或文件以及cpu所执行的程序指令。计算设备900还可以包括用户界面980。当然，图9所示的架构只是示例性的，在实现不同的设备时，根据实际需要，可以省略图9示出的计算设备中的一个或多个组件。

本公开的实施例也可以被实现为计算机可读存储介质。根据本公开实施例的计算机可读存储介质上存储有计算机可读指令。当所述计算机可读指令由处理器运行时，可以执行参照以上附图描述的根据本公开实施例的方法。所述计算机可读存储介质包括但不限于例如易失性存储器和/或非易失性存储器。所述易失性存储器例如可以包括随机存取存储器(ram)和/或高速缓冲存储器(cache)等。所述非易失性存储器例如可以包括只读存储器(rom)、硬盘、闪存等。

本领域技术人员能够理解，本公开所披露的内容可以出现多种变型和改进。例如，以上所描述的各种设备或组件可以通过硬件实现，也可以通过软件、固件、或者三者中的一些或全部的组合实现。

此外，如本公开和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

此外，本公开中使用了流程图用来说明根据本公开的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

除非另有定义，这里使用的所有术语(包括技术和科学术语)具有与本发明所属领域的普通技术人员共同理解的相同含义。还应当理解，诸如在通常字典里定义的那些术语应当被解释为具有与它们在相关技术的上下文中的含义相一致的含义，而不应用理想化或极度形式化的意义来解释，除非这里明确地这样定义。

以上对本公开进行了详细说明，但对于本领域技术人员而言，显然，本公开并非限定于本说明书中说明的实施方式。本公开在不脱离由权利要求书的记载所确定的本公开的宗旨和范围的前提下，可以作为修改和变更方式来实施。因此，本说明书的记载是以示例说明为目的，对本公开而言并非具有任何限制性的意义。