一种数据库服务器的故障处理方法和装置

技术领域

本申请涉及数据库技术领域，尤其涉及一种数据库服务器的故障处理方法和装置。

背景技术

在一些极端异常的情况下，数据库服务器可能会出现Raid(Redundant Arrays ofIndependent Disks，独立磁盘冗余阵列)故障或者网卡故障等硬件故障，但软件系统运行正常，进而导致数据库服务器出现了系统夯死。这种情况下，一般的高可用组件是无法探知到异常的，进而无法对出现故障的数据库服务器进行自动隔离。

为了避免故障的数据库服务器对业务连续性造成影响，当出现上述情况时，一般需要人为参与进行故障隔离。然而人为操作往往风险较高，隔离效率低下，且容易对实际业务造成不可控风险。

发明内容

本申请实施例提供了一种数据库服务器的故障处理方法和装置，以降低操作风险，提高故障隔离效率。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种数据库服务器的故障处理方法，由数据库服务器执行，其中，所述方法包括：

检测数据库服务器上部署的数据库的读写状态；

在所述数据库的读写状态为不可写状态的情况下，检测所述数据库服务器上的操作系统的状态；

在所述操作系统的状态为存活状态的情况下，采用预设故障处理策略对所述数据库服务器进行故障处理。

可选地，所述检测数据库服务器上部署的数据库的读写状态包括：

利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据；

根据所述数据库中的时间戳数据确定所述数据库的读写状态。

可选地，所述根据所述数据库中的时间戳数据确定所述数据库的读写状态包括：

确定所述数据库中的时间戳数据是否有更新；

若有，则确定所述数据库的读写状态为可写状态。

可选地，所述根据所述数据库中的时间戳数据确定所述数据库的读写状态还包括：

在所述数据库中的时间戳数据没有更新的情况下，继续执行利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据的步骤；

在所述数据库中的时间戳数据没有更新的次数达到预设次数阈值的情况下，确定所述数据库的读写状态为不可写状态。

可选地，所述检测所述数据库服务器上的操作系统的状态包括：

向所述操作系统发送通信请求；

根据所述操作系统对所述通信请求的响应结果确定所述操作系统的状态。

可选地，所述检测数据库服务器上部署的数据库的读写状态之后，所述方法还包括：

在所述数据库的读写状态为不可写状态的情况下，向业务平台发送故障隔离请求，以使所述业务平台对所述数据库服务器进行故障隔离。

可选地，所述采用预设故障处理策略对所述数据库服务器进行故障处理包括：

调用带外管理平台接口对所述数据库服务器进行关闭，以使所述数据库服务器上的操作系统的状态进入不存活状态；

根据所述不存活状态，触发对所述数据库服务器上部署的数据库按照数据库的角色进行的故障处理。

可选地，所述按照数据库的角色进行的故障处理包括以下至少一种：

在所述数据库的角色为主数据库的情况下，所述按照数据库的角色进行的故障处理为将所述主数据库对应的本地备用数据库切换为新的主数据库，以使新的主数据库接收业务数据；

在所述数据库的角色为本地备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述主数据库进行降级处理，以使降级处理后的主数据库直接向所述本地备用数据库对应的同城备用数据库同步数据；

在所述数据库的角色为同城备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述同城备用数据库对应的本地备用数据库进行降级处理，以使降级处理后的本地备用数据库直接向所述同城备用数据库对应的异地备用数据库同步数据；

在所述数据库的角色为异地备用数据库的情况下，所述按照数据库的角色进行的故障处理为直接关闭所述异地备用数据库所在的数据库服务器。

第二方面，本申请实施例还提供一种数据库服务器的故障处理装置，应用于数据库服务器，其中，所述装置用于实现前述之任一所述方法。

第三方面，本申请实施例还提供一种电子设备，包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行前述之任一所述方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例的数据库服务器的故障处理方法可以由各数据库服务器执行，在对数据库服务器进行故障处理时，可以先检测数据库服务器上部署的数据库的读写状态，如果数据库的读写状态为不可写状态，则进一步检测数据库服务器上的操作系统的状态，如果操作系统的状态为存活状态，说明数据库服务器发生了系统夯死的情况，需要采用预设故障处理策略对数据库服务器进行故障处理。本申请实施例的数据库服务器的故障处理方法能够通过自动检测数据库的可写状态和操作系统的存活状态来探知数据库服务器的软件运行状况，进而可以确定数据库服务器是否出现了系统夯死的故障情况，且在出现系统夯死时能够采用预设故障处理策略快速进行故障处理，并及时将故障的数据库服务器进行隔离，大大提高了故障处理效率，且该过程无需人工干预，降低了人为操作失误的风险。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例中一种分布式数据中心的架构示意图；

图2为本申请实施例一种数据库服务器的故障处理方法的流程示意图；

图3为本申请实施例一种数据库服务器的故障处理流程示意图；

图4为本申请实施例一种数据库服务器的故障处理装置的结构示意图；

图5为本申请实施例中一种电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实际业务场景下，当数据库服务器出现系统夯死的情况时，一般的高可用组件无法探知到异常，进而无法自动触发对故障的数据库服务器进行隔离的操作，而如果未对故障的数据库服务器及时进行隔离，会导致当前以及后续大量的业务请求无法被有效处理，进而出现业务处理中断、处理失败等情况，导致整个数据库服务器集群的稳定性和业务连续性受到极大影响。

基于此，本申请实施例提供了一种数据库服务器的故障处理方法，由数据库服务器执行，本申请实施例的数据库服务器适用于分布式数据中心架构下的任意一个数据库服务器，这里以图1为例说明本申请实施例的一种应用场景。如图1所示，提供了本申请实施例中一种分布式数据中心的架构示意图。在分布式数据中心架构下部署有多个数据中心，一般包括主数据中心、同城数据中心和异地数据中心，主数据中心部署有主数据库和本地备用数据库，同城数据中心与主数据中心位于同一城市，其中部署有同城备用数据库，异地数据中心与主数据中心位于不同的城市，其中部署有异地备用数据库。

在对外提供服务时，主数据中心、同城数据中心和异地数据中心中的数据库服务器都可以接收上层应用的业务请求，主数据中心中的数据库服务器在接收到业务请求后，能够对业务请求直接进行处理，通过访问主数据中心所连接的主数据库进行数据的读写操作，并将数据实时同步给与自己位于同一数据中心的本地备用数据库。同城数据中心和异地数据中心的数据库服务器在接收到业务请求后，不能直接对业务请求进行处理，而需要将业务请求转发至主数据中心，由主数据中心进行业务处理，之后主数据中心的本地备用数据库通过异步的方式将主数据库的数据同步给同城数据中心的同城备用数据库，同城备用数据库再通过异步方式将数据同步给异地数据中心的异地备用数据库，从而保证整个数据中心架构下的数据完整性。

如图2所示，提供了本申请实施例一种数据库服务器的故障处理方法的流程示意图，所述方法至少包括如下的步骤S210至步骤S230：

步骤S210，检测数据库服务器上部署的数据库的读写状态。

本申请实施例的数据库服务器可以理解为是部署有数据库的机器，实际业务场景下，通常会涉及到多台数据库服务器，每台数据库服务器都可以用来执行本申请实施例提供的数据库服务器的故障处理方法。当然，除了可以由数据库自己所在的数据库服务器来执行，也可以单独部署独立的服务器来执行本申请实施例提供的数据库服务器的故障处理方法。

为了确定数据库服务器是否出现了系统夯死的情况，可以先确定数据库服务器的硬件运行状况，例如判断数据库服务器是否发生了Raid故障或者网卡故障等硬件故障情况。具体可以通过检测数据库服务器上部署的数据库的读写状态来判断，这里的数据库的读写状态是指数据库是否可写的状态，即判断数据库服务器是否能够将数据写入到自己的硬盘中，进而可以根据数据库是否可写的状态来确定数据库服务器的硬件运行状况是否正常。

数据库状态的检测频率可以是每隔一段时间例如每3秒进行一次，也可以是实时检测。当然，具体如何设定检测频率，本领域技术人员可根据实际需求灵活设置，在此不作具体限定。

步骤S220，在所述数据库的读写状态为不可写状态的情况下，检测所述数据库服务器上的操作系统的状态。

在数据库的读写状态为不可写状态的情况下，说明此时数据库服务器无法将数据写入到硬盘中，该情况可能是软件层面导致的，也可能是硬件层面导致的系统夯死，例如数据库服务器可能发生了Raid故障或者网卡故障等硬件故障。为了进一步确定数据库服务器是否出现了系统夯死的情况，还需要进一步检测数据库服务器的软件运行状况，具体可以通过检测数据库服务器上运行的操作系统的状态来判断。

步骤S230，在所述操作系统的状态为存活状态的情况下，采用预设故障处理策略对所述数据库服务器进行故障处理。

在操作系统的状态为存活状态的情况下，说明操作系统能够正常运行，也即数据库服务器在软件层面上的运行状况是正常的，因此可以确定数据库服务器此时发生了系统夯死的情况，需要采取预设故障处理策略对数据库服务器进行故障处理，以避免对业务连续性造成影响。

本申请实施例的数据库服务器的故障处理方法能够通过自动检测数据库的可写状态和操作系统的存活状态来探知数据库服务器的软件运行状况，进而可以确定数据库服务器是否出现了系统夯死的故障情况，在出现系统夯死时能够采用预设故障处理策略快速进行故障处理，并及时将故障的数据库服务器进行隔离，大大提高了故障处理效率，且该过程无需人工干预，降低了人为操作失误的风险。

在本申请的一个实施例中，所述检测数据库服务器上部署的数据库的读写状态包括：利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据；根据所述数据库中的时间戳数据确定所述数据库的读写状态。

本申请实施例在检测数据库服务器上部署的数据库的读写状态时，可以利用数据库服务器上部署的高可用(High Availability，简称HA)组件来进行判断，高可用组件一般部署在主备模式的数据库服务器上，主要用于保障主数据库出现故障时，能够自动完成故障转移，并将虚拟IP漂移到备用数据库。如果备用数据库故障的情况下，高可用组件则负责将主数据库由半同步配置改为异步配置，以确保主数据库可写。

在本申请实施例中，利用高可用组件可以探测到数据库是否可写，具体可以通过向数据库中写入时间戳数据，时间戳数据可以看作是一个时间字段，根据时间戳数据的写入结果来确定数据库的读写状态是可写状态还是不可写状态。

需要说明的是，由于本申请需要检测的是数据库服务器是否出现Raid故障等硬件故障情况，因此本申请实施例在探测数据库是否可写时是指是否能够将时间戳数据写入到数据库服务器的硬盘中。

在本申请的一个实施例中，所述根据所述数据库中的时间戳数据确定所述数据库的读写状态包括：确定所述数据库中的时间戳数据是否有更新；若有，则确定所述数据库的读写状态为可写状态。

在根据数据库中的时间戳数据确定数据库的读写状态时，可以根据数据库中的时间戳数据是否有更新来确定，如果数据库中的时间戳数据有更新，说明时间戳数据写入成功，此时数据库的读写状态为可写状态，数据库服务器的硬件运行状况正常，因此可以结束本次检测，进行下一次检测。

举例说明，假设数据库中当前存储的时间戳数据为“2021年1月1日11点01分01秒”，在向数据库中执行一个写入时间戳数据的操作后，数据库中当前存储的时间戳数据变为“2021年1月1日11点01分04秒”，可以看出时间戳数据有更新，说明写入时间戳数据的操作成功，数据库的读写状态为可写状态。

在本申请的一个实施例中，所述根据所述数据库中的时间戳数据确定所述数据库的读写状态还包括：在所述数据库中的时间戳数据没有更新的情况下，继续执行利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据的步骤；在所述数据库中的时间戳数据没有更新的次数达到预设次数阈值的情况下，确定所述数据库的读写状态为不可写状态。

在向数据库中写入时间戳数据后，如果数据库中的时间戳数据没有更新，说明此时写入失败。然而在实际业务场景下，当并发的业务请求较高时，数据库服务器面临的压力也较高，可能也会出现短暂的响应延迟或者失败的情况，而实际上数据库服务器此时可能并未出现故障情况。

因此本申请实施例考虑到上述这种特殊情况，在一次写入失败后，还可以再执行一次到多次的写入操作，具体执行写入操作的次数本领域技术人员可根据实际情况灵活设定。如果一定时间内连续写入失败的次数触发了预设的次数阈值，说明此时数据库服务器无法将数据写入到硬盘中，该情况可能是软件层面导致的，也可能是硬件层面导致的系统夯死，后续可以进一步结合操作系统的存活状态来判断。本申请实施例通过多次执行写操作来判断数据库服务器的可写状态，保证了检测结果的准确性。

在本申请的一个实施例中，所述检测所述数据库服务器上的操作系统的状态包括：向所述操作系统发送通信请求；根据所述操作系统对所述通信请求的响应结果确定所述操作系统的状态。

本申请实施例的整体流程具体可以由内置在数据库服务器上的独立的程序或组件来执行，因此在检测数据服务器上运行的操作系统的状态时，可以通过尝试与操作系统建立通信连接的方式来确定。例如，可以向操作系统发送通信请求，这里的通信请求可以采用Ping命令来实现，Ping命令主要用于测试互联网协议网络上主机的可达性，通过向目标主机发送因特网信报控制协议(ICMP)回显请求数据包并等待ICMP回显回复来实现，Ping命令能够报告错误、数据包丢失和结果的统计摘要，通常包括往返时间的最小值、最大值、平均值以及平均值的标准差等参数。当然除了采用Ping命令，也可以采用SSH(Secure Shell)命令，具体采用何种形式的通信命令，本领域技术人员可根据实际需求灵活设置。

举例说明，以Ping命令为例，操作系统在接收到通信请求后，会返回一个应答包，作为对通信请求的响应结果，如果应答包中的参数值不为0，说明此时能够与操作系统建立通信连接，操作系统处于存活状态。如果应答包中的参数值均为0，说明此时无法与操作系统建立通信连接，操作系统处于非存活状态，即出现了软件层面的故障。

当然，对于上述应答包中的参数值的设置和判断，本领域技术人员可以根据实际需求灵活设置，例如也可以设置为当某一具体参数值超过预设阈值时，认为操作系统处于存活状态，而当某一具体参数值未超过预设阈值时，认为操作系统处于非存活状态等等。

需要说明的是，当数据库的读写状态处于不可写状态且操作系统处于非存活状态时，说明数据服务器无论是硬件层面还是软件层面都发生了故障，这种情况下高可用组件是可以直接探知到异常的，即使不执行上述检测流程，也能够自动触发后续的主备切换操作，因此需要明确该种情况与系统夯死情况的区别。

在本申请的一个实施例中，所述检测数据库服务器上部署的数据库的读写状态之后，所述方法还包括：在所述数据库的读写状态为不可写状态的情况下，向业务平台发送故障隔离请求，以使所述业务平台对所述数据库服务器进行故障隔离。

在检测到数据库服务器上部署的数据库处于不可写状态后，说明数据库服务器已经发生了故障，为了避免对业务连续性造成过多影响，可以将故障的数据库服务器进行隔离，以保证整个数据库集群提供服务的稳定性。

具体地，当检测到数据库服务器上部署的数据库处于不可写状态后，可以调用业务平台的业务隔离接口，向业务平台发送故障隔离请求，使得业务平台能够及时对故障的数据库服务器进行隔离。

在本申请的一个实施例中，所述采用预设故障处理策略对所述数据库服务器进行故障处理包括：调用带外管理平台接口对所述数据库服务器进行关闭，以使所述数据库服务器上的操作系统的状态进入不存活状态；根据所述不存活状态，触发对所述数据库服务器上部署的数据库按照数据库的角色进行的故障处理。

在实际业务场景下，数据库服务器上的数据库一般采用主备模式进行部署，本申请实施例中具体可以包括依次建立通信连接的主数据库、备用数据库、同城备用数据库和异地备用数据库，不同角色的数据库发挥的功能不同，因此当数据库服务器上的数据库发生故障时，可以触发对数据库服务器上部署的数据库按照数据库的角色进行相应的处理，以便于后续数据库管理人员进行故障修复。

然而现有的业务逻辑通常是在高可用组件探测到数据库服务器在软件层面的故障，也即操作系统处于非存活状态时，才会自动触发数据库的故障处理操作，而在系统夯死的情况下，仅仅是硬件层面的故障，软件层面运行正常，导致高可用组件无法探知到异常，进而也就无法自动触发数据库的故障处理操作。

考虑到上述情况，本申请实施例通过调用带外管理平台接口来关闭故障的数据库服务器，由于数据库服务器关闭后会导致操作系统进入非存活状态，而本申请实施例的操作系统存活状态的探测频率一般为几秒，因此在进行下一次的操作系统存活状态的探测时，就会探测到操作系统处于非存活状态，从而可以自动触发对数据库服务器上部署的数据库按照数据库的角色进行相应的处理。

带外管理平台上统一管理和维护着多台硬件设备，在调用带外管理平台的接口时，可以将需要进行关闭的数据库服务器的参数信息如用户名、密码、序列号等传递给带外管理平台，以使带外管理平台根据上述参数信息能够确定对哪台数据库服务器进行关闭。

上述实施例可以理解为是在系统夯死的情况下，通过调用带外管理平台接口关闭数据库服务器，强制使数据库服务器的操作系统进入非存活状态，以自动触发故障处理操作。

在本申请的一个实施例中，所述按照数据库的角色进行的故障处理包括以下至少一种：在所述数据库的角色为主数据库的情况下，所述按照数据库的角色进行的故障处理为将所述主数据库对应的本地备用数据库切换为新的主数据库，以使新的主数据库接收业务数据；在所述数据库的角色为本地备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述主数据库进行降级处理，以使降级处理后的主数据库直接向所述本地备用数据库对应的同城备用数据库同步数据；在所述数据库的角色为同城备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述同城备用数据库对应的本地备用数据库进行降级处理，以使降级处理后的本地备用数据库直接向所述同城备用数据库对应的异地备用数据库同步数据；在所述数据库的角色为异地备用数据库的情况下，所述按照数据库的角色进行的故障处理为直接关闭所述异地备用数据库所在的数据库服务器。

如前所述，本申请实施例的数据库的角色可以包括主数据库、本地备用数据库、同城备用数据库和异地备用数据库，主数据库负责数据的读写并向备用数据库同步数据，本地备用数据库负责数据的读取并向同城备用数据库同步数据，同城备用数据库负责数据的读取并向异地备用数据库同步数据，而异地备用数据库主要负责数据的读取。

基于此，本申请实施例的对于不同角色的数据库所采用的具体的故障处理逻辑不同。对于主数据库来说，当主数据库所在的服务器出现系统夯死的情况时，可以将该主数据库对应的备用数据库切换为新的主数据库，以通过新的主数据库继续对外提供服务。

对于本地备用数据库来说，当本地备用数据库的服务器出现系统夯死的情况时，本地备用数据库的的数据将无法发送给本地备用数据库所连接的同城备用数据库，主数据库的服务器也无法将数据同步给备用数据库，此时可以对本地备用数据库所连接的主数据库进行降级处理，使得降级处理后的主数据库能够接替故障的本地备用数据库，直接向本地备用数据库所连接的同城备用数据库同步数据，从而保证数据同步的正确性和及时性。

同理，对于同城备用数据库来说，当同城备用数据库的服务器出现系统夯死的情况时，同城备用数据库的数据将无法发送给同城备用数据库所连接的异地备用数据库，本地备用数据库的服务器也无法将数据同步给同城备用数据库，此时可以对同城备用数据库所连接的本地备用数据库进行降级处理，使得降级处理后的本地备用数据库能够接替故障的同城备用数据库，直接向同城备用数据库所连接的异地备用数据库同步数据，从而保证数据同步的正确性和及时性。

对于异地备用数据库来说，由于其只负责接收同城备用数据库同步过来的数据，因此当异地备用数据库出现故障时，直接关闭该异地备用数据库所在服务器即可。

需要说明的是，上述实施例中的隔离过程和按照数据库的角色进行的故障处理过程并不存在相互作用关系。因为实际业务场景下，隔离操作所耗费的时间通常较大，一般3秒以内就可以完成隔离操作，而按照数据库的角色进行的故障处理逻辑较为复杂，耗时也较长，一般需要十几分钟才可以完成，如果等待该流程完成再进行隔离操作，会导致故障的数据库服务器在短时间内无法被隔离，进而会对实际业务造成严重影响。

因此本申请实施例的隔离操作独立于后续的按照数据库的角色进行的故障处理操作，只要检测到数据库处于不可写状态，就可以直接触发隔离操作，以降低对实际业务造成的影响。

如图3所示，提供了本申请实施例一种数据库服务器的故障处理流程示意图。首先，检测数据库服务器上部署的数据库是否可写，如果可写，则结束本次检测，如果不可写，则记为1次写入失败，然后再执行检测数据库服务器上部署的数据库是否可写的步骤，以此循环，直到连续多次如连续3次检测到数据库不可写，则确定数据库的读写状态为不可写的状态，说明数据库服务器出现了故障。此时可以直接调用业务平台的业务隔离接口发送业务隔离请求，使得业务平台能够及时对数据库服务器进行隔离。

此外，为了确定数据库服务器的故障是否是系统夯死的情况，还需要进一步检查数据库服务器上运行的操作系统的状态，如果操作系统为存活状态，证明数据库服务器发生了系统夯死，由于在系统夯死情况下，高可用组件无法探测到异常，进而无法触发主备切换等故障处理操作，因此这时可以调用带外管理平台接口对数据库服务器进行关闭，强制操作系统进入非存活状态，进而可以自动触发后续的故障处理操作，从而实现对数据库服务器的故障处理。

本申请实施例还提供了一种数据库服务器的故障处理装置400，应用于数据库服务器，如图4所示，提供了本申请实施例一种数据库服务器的故障处理装置的结构示意图，所述装置400包括：第一检测单元410、第二检测单元420及故障处理单元430，其中：

第一检测单元410，用于检测数据库服务器上部署的数据库的读写状态；

第二检测单元420，用于在所述数据库的读写状态为不可写状态的情况下，检测所述数据库服务器上的操作系统的状态；

故障处理单元430，用于在所述操作系统的状态为存活状态的情况下，采用预设故障处理策略对所述数据库服务器进行故障处理。

在本申请的一个实施例中，所述第一检测单元410具体用于：利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据；根据所述数据库中的时间戳数据确定所述数据库的读写状态。

在本申请的一个实施例中，所述第一检测单元410具体用于：确定所述数据库中的时间戳数据是否有更新；若有，则确定所述数据库的读写状态为可写状态。

在本申请的一个实施例中，所述第一检测单元410具体用于：在所述数据库中的时间戳数据没有更新的情况下，继续执行利用高可用组件向所述数据库服务器上部署的数据库中写入时间戳数据的步骤；在所述数据库中的时间戳数据没有更新的次数达到预设次数阈值的情况下，确定所述数据库的读写状态为不可写状态。

在本申请的一个实施例中，所述第二检测单元420具体用于：向所述操作系统发送通信请求；根据所述操作系统对所述通信请求的响应结果确定所述操作系统的状态。

在本申请的一个实施例中，所述装置还包括：发送单元，用于在所述数据库的读写状态为不可写状态的情况下，向业务平台发送故障隔离请求，以使所述业务平台对所述数据库服务器进行故障隔离。

在本申请的一个实施例中，所述故障处理单元430具体用于：调用带外管理平台接口对所述数据库服务器进行关闭，以使所述数据库服务器上的操作系统的状态进入不存活状态；根据所述不存活状态，触发对所述数据库服务器上部署的数据库按照数据库的角色进行的故障处理。

在本申请的一个实施例中，所述按照数据库的角色进行的故障处理包括以下至少一种：在所述数据库的角色为主数据库的情况下，所述按照数据库的角色进行的故障处理为将所述主数据库对应的本地备用数据库切换为新的主数据库，以使新的主数据库接收业务数据；在所述数据库的角色为本地备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述主数据库进行降级处理，以使降级处理后的主数据库直接向所述本地备用数据库对应的同城备用数据库同步数据；在所述数据库的角色为同城备用数据库的情况下，所述按照数据库的角色进行的故障处理为对所述同城备用数据库对应的本地备用数据库进行降级处理，以使降级处理后的本地备用数据库直接向所述同城备用数据库对应的异地备用数据库同步数据；在所述数据库的角色为异地备用数据库的情况下，所述按照数据库的角色进行的故障处理为直接关闭所述异地备用数据库所在的数据库服务器。

能够理解，上述数据库服务器的故障处理装置，能够实现前述实施例中提供的由数据库服务器执行的数据库服务器的故障处理方法的各个步骤，关于数据库服务器的故障处理方法的相关阐释均适用于数据库服务器的故障处理装置，此处不再赘述。

图5是本申请的一个实施例电子设备的结构示意图。请参考图5，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成数据库服务器的故障处理装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

检测数据库服务器上部署的数据库的读写状态；

在所述数据库的读写状态为不可写状态的情况下，检测所述数据库服务器上的操作系统的状态；

在所述操作系统的状态为存活状态的情况下，采用预设故障处理策略对所述数据库服务器进行故障处理。

上述如本申请图4所示实施例揭示的数据库服务器的故障处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图4中数据库服务器的故障处理装置执行的方法，并实现数据库服务器的故障处理装置在图4所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的电子设备执行时，能够使该电子设备执行图4所示实施例中数据库服务器的故障处理装置执行的方法，并具体用于执行：

检测数据库服务器上部署的数据库的读写状态；

在所述数据库的读写状态为不可写状态的情况下，检测所述数据库服务器上的操作系统的状态；

在所述操作系统的状态为存活状态的情况下，采用预设故障处理策略对所述数据库服务器进行故障处理。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。