CN104408059B - 一种故障处理的方法及装置 - Google Patents
一种故障处理的方法及装置 Download PDFInfo
- Publication number
- CN104408059B CN104408059B CN201410594247.0A CN201410594247A CN104408059B CN 104408059 B CN104408059 B CN 104408059B CN 201410594247 A CN201410594247 A CN 201410594247A CN 104408059 B CN104408059 B CN 104408059B
- Authority
- CN
- China
- Prior art keywords
- database
- state
- delay machine
- result
- detection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明实施例提供一种故障处理的方法及装置，该方法包括：获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态；当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库；当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。本发明实施例能够实现自动检测故障并从故障状态中恢复，提高数据库的处理效率和可用性。
Description
技术领域
本发明涉及数据处理技术领域，具体涉及一种故障处理的方法及装置。
背景技术
Informix数据库是一个在线联机交易处理系统的专业的关系型数据产品，因其具有简单、高效和易扩展等特性，被广泛应用于开放平台交易系统。但是一旦其发生故障就会严重影响数据库的运行速度，甚至会出现实例宕机的情况，并且自身无法预测故障及恢复，需要人工操作去查找故障原因并恢复，这样就浪费了大量的时间，降低了数据库的可用性。
发明内容
本发明实施例提供一种故障处理的方法及装置，能够自动检测故障并恢复，提高数据库的处理效率和可用性。
本发明实施例第一方面提供一种故障处理的方法，包括：
获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态；
当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库；
当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。
本发明实施例第二方面提供一种故障处理的装置，包括：
获取单元，用于获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态；
第一重启单元，用于当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库；
第二重启单元，用于当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。
本发明实施例通过获取状态检测参数，根据所述状态检测参数确定数据库当前状态的故障类型并根据故障类型重新启动数据库，恢复数据库的正常运行，实现了自动检测故障并从故障状态中恢复，提高了数据库的处理效率和可用性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种故障处理的方法的流程示意图；
图2为本发明实施例提供的另一种故障处理的方法的流程示意图；
图3为本发明实施例提供的另一种故障处理的方法的流程示意图；
图4为本发明实施例提供的另一种故障处理的方法的流程示意图；
图5为本发明实施例提供的一种故障处理的装置的结构示意图；
图6为本发明实施例提供的另一种故障处理的装置的结构示意图；
图7为本发明实施例提供的另一种故障处理的装置的结构示意图；
图8为本发明实施例提供的另一种故障处理的装置的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例中的故障处理的方法和装置是针对Informix数据库设计的，实施例中所提到的数据库即为Informix数据库。本发明实施例中的管理端可以为管理Informix数据库的管理操作员，也可以为管理Informix数据库的终端。
下面将结合附图1-附图4，对本发明实施例提供的故障处理的方法进行详细介绍。
请参见图1，为本发明实施例提供的一种故障处理的方法的流程示意图；该方法可包括以下步骤S101-步骤S103。
S101，获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态。
具体地，获取正在运行的数据库的状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态。其中，所述待处理事件的个数为所述正在运行的数据库中等待处理的事件的个数，在Informix数据库中为ready队列的长度，若所述待处理事件的个数异常，将会导致数据库运行速度缓慢、性能降低。所述数据库实例状态为所述数据库中正在运行的实例状态，当所述数据库实例状态处于online状态时表明所述数据库实例状态为正常运行状态，当所述数据库实例状态未处于online状态时表明所述数据库实例状态为异常运行状态，若所述数据库实例状态处于异常状态将引起数据库宕机。现有技术中的数据库只是一味地执行命令，无法检测状态以致数据库出现故障时便停止运行，通过获取所述状态检测参数可以检测到所述数据库是否发生故障，还可以根据所述状态检测参数判断故障的类型。
S102，当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库。
具体地，根据所述状态参数来判断所述数据库的故障类型，当所述状态检测参数包括待处理事件的个数时，表明所述待处理事件的个数异常，可能会导致所述数据库出现性能故障状态。为了进一步地确认所述数据库当前状态为性能故障状态，需要根据所述待处理事件的个数检测数据库当前状态。若检测出所述数据库当前状态为性能故障状态，则通过切换用户模式并重新启动所述数据库以使所述数据库从故障状态中恢复。
S103，当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。
具体地，根据所述状态参数来判断所述数据库的故障类型，当所述状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。为了进一步地确认所述数据库当前状态为宕机故障状态，需要根据所述数据库实例状态检测数据库当前状态。若检测出所述数据库当前状态为宕机故障状态，则重新启动所述数据库以使所述数据库从故障状态中恢复。
当所述状态检测参数同时包括所述待处理事件的个数和所述数据库实例状态时，可以同时执行步骤S102和步骤S103，实现对两种故障状态的处理。
本发明实施例通过获取状态检测参数，根据所述状态检测参数确定数据库当前状态的故障类型并根据故障类型重新启动数据库，恢复数据库的正常运行，实现了自动检测故障并从故障状态中恢复，提高了数据库的处理效率和可用性。
请参见图2，为本发明实施例提供的另一种故障处理的方法的流程示意图；该方法可包括以下步骤S201-步骤S204。
S201，当获取到的状态检测参数包括待处理事件的个数时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为性能故障结果
具体地，当获取到的状态检测参数包括待处理事件的个数时，表明所述待处理事件的个数异常，可能会导致所述数据库出现性能故障状态。通过获取至少一个探测结果来判断所述数据库当前状态是否为性能故障状态。所述至少一个探测结果一般为两个探测结果，用于判断得到的性能故障状态更加准确。所述两个探测结果的探测间隔时间是一个固定值，为所述数据库休眠的时间，每隔一个探测间隔时间，数据库就会获取到一个探测结果。判断所述至少一个探测结果是否均为性能故障结果来确定所述数据库当前状态。
其中，所述性能故障结果包括所述待处理事件的个数高于预设的个数阈值的结果，所述预设的个数阈值为所述数据库正常运行时所承受的待处理事件的个数的最大值，即ready队列长度的最大值。若探测到所述待处理事件的个数低于或等于预设的个数阈值，则表明探测结果为正常结果。
S202,当所述至少一个探测结果均为所述性能故障结果时，确定所述数据库当前状态为性能故障状态。
具体地，当所述至少一个探测结果均为所述性能故障结果时，即获取到的两个连续的探测结果均为所述性能故障结果，可以确定所述数据库当前状态为性能故障状态。若第一探测结果为性能故障结果，经过探测间隔时间后获取的第二探测结果为正常结果，则所述数据库当前状态为正常结果状态；若第一探测结果为正常状态结果，经过探测间隔时间后获取的第二探测结果为性能故障状态结果，则无法判断所述数据库当前状态，需再次获取第三探测结果来判断所述数据库当前状态。只有当所述至少一个探测结果均为所述性能故障结果时，才能确定所述数据库当前状态为性能故障状态。若无法判断所述数据库当前状态或所述数据库当前状态为正常状态，则执行步骤S101，获取状态检测参数，检测所述数据库是否处于故障状态。
S203，根据所述性能故障状态，向管理端发送告警信息。
由步骤S202判断得出所述数据库当前状态为性能故障状态，将所述性能故障状态的信息记录于所述数据库的告警文件中并向管理端发送告警信息。所述告警信息用于通知所述管理端所述数据库处于所述性能故障状态并将自动恢复。
S204，根据所述性能故障状态切换用户模式为单用户模式，并重新启动数据库。
其中，所述用户模式包括单用户模式和多用户模式，当所述数据库的待处理事件的个数低于或等于所述预设的个数阈值时，所述数据库采用多用户模式处理待处理事件，一旦所述数据库当前状态为性能故障状态时，采用多用户模式处理将严重影响所述数据库的运行速度并降低所述数据库的性能。因此，将用户模式切换为单用户模式，依次处理待处理事件直到所述待处理事件的个数低于或等于所述预设的个数阈值并重新启动所述数据库以使所述数据库从故障状态中恢复。
为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过当获取到的状态检测参数包括待处理事件的个数时，判断获取至少一个探测结果是否均为性能故障结果，实现了对性能故障状态的处理，完成了性能故障状态的检测、告警以及自动恢复，提高了数据库的性能，增强了数据库的主动性。
请参见图3，为本发明实施例提供的另一种故障处理的方法的流程示意图；该方法可包括以下步骤S301-步骤S307。
S301，当获取到的状态检测参数包括数据库实例状态时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为宕机故障结果。
具体地，当获取到的状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。通过获取至少一个探测结果来判断所述数据库当前状态是否为宕机故障状态。所述至少一个探测结果一般为两个探测结果，用于判断得到的宕机故障状态更加准确。所述两个探测结果的探测间隔时间是一个固定值，为所述数据库休眠的时间，每隔一个探测间隔时间，数据库就会获取到一个探测结果。判断所述至少一个探测结果是否均为宕机故障结果来确定所述数据库当前状态。
其中，所述宕机故障结果包括所述数据库实例状态为异常工作状态的结果，这是所述数据库实例状态未处于online状态。
S302，当所述至少一个探测结果均为所述宕机故障结果时，确定所述数据库当前状态为宕机故障状态。
具体地，当所述至少一个探测结果均为所述宕机故障结果时，即获取到的两个连续的探测结果均为所述宕机故障结果，可以确定所述数据库当前状态为宕机故障状态。若第一探测结果为宕机故障结果，经过探测间隔时间后获取的第二探测结果为正常结果，则所述数据库当前状态为正常结果状态；若第一探测结果为正常状态结果，经过探测间隔时间后获取的第二探测结果为宕机故障状态结果，则无法判断所述数据库当前状态，需再次获取第三探测结果来判断所述数据库当前状态。只有当所述至少一个探测结果均为所述宕机故障结果时，才能确定所述数据库当前状态为宕机故障状态。若无法判断所述数据库当前状态或所述数据库当前状态为正常状态，则执行步骤S101，获取状态检测参数，检测所述数据库是否处于故障状态。
S303，检测数据库实例的进程是否存在。
步骤S302能够确定所述数据库当前状态为所述宕机故障状态，但是并不清楚是所述数据库中的具体哪个实例发生了宕机，因此需要检测数据库实例进程以及宕机故障状态来查找宕机实例。首先，检测数据库实例的进程是否存在，若存在则表明所述数据库实例未发生宕机，则执行步骤S101，获取状态检测参数，检测所述数据库是否处于故障状态。
S304，当检测到所述数据库实例的进程不存在时，检测所述宕机故障状态是否包括目标关键字。
当检测到所述数据库实例的进程不存在时，表明所述数据库实例可能发生了宕机，需要通过检测所述宕机故障状态是否包括目标关键字来进一步确认。其中，所述目标关键字包括所述数据库实例的名称、shared memory not initialized。
S305，当检测到所述宕机故障状态不包括目标关键字时，确定所述数据库实例为宕机实例。
S306，根据所述宕机故障状态，向管理端发送告警信息。
由步骤S302判断得出所述数据库当前状态为宕机故障状态且查找到宕机实例，将所述宕机故障状态的信息以及所述宕机实例记录于所述数据库的告警文件中并向管理端发送告警信息。所述告警信息用于通知所述管理端所述数据库处于所述宕机故障状态并将自动恢复。
S307，根据所述宕机故障状态重新启动所述数据库。
根据所述宕机故障状态重新启动所述数据库以使所述数据库从故障状态中恢复。
同样，为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过当获取到的状态检测参数包括数据库实例状态时，判断获取至少一个探测结果是否均为宕机故障结果以及查找宕机实例，实现了对宕机故障状态的处理，完成了宕机故障状态的检测、告警以及自动恢复，脱离了人工操作，缩短了恢复时间，提高了数据库的运行效率。
请参见图4，为本发明实施例提供的另一种故障处理的方法的流程示意图；该方法可包括以下步骤S401-步骤S402。
S401，当所述状态检测参数包括数据库实例状态时，检测数据库地址和所述数据库的端口网络状态是否正常。
具体地，当所述状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。宕机故障状态除了所述数据库实例异常外，还包括客观原因，如数据库地址和所述数据库的端口网络状态异常，因此需要数据库地址和所述数据库的端口网络状态是否正常。
S402,当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，重新启动所述数据库。
当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，表明所述数据库当前状态为宕机故障状态，需要通过重新启动所述数据库以使所述数据库从故障状态中恢复。
同样，为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过检测数据库地址和所述数据库的端口网络状态是否正常来判断所述数据库当前状态是否为宕机故障状态，完成了宕机故障状态的检测以及自动恢复，脱离了人工操作，缩短了恢复时间，提高了数据库的运行效率。
图3和图4所示的实施例均为对所述数据库当前状态为宕机故障状态的处理，两者可以同时进行，也可以单独进行，互不影响，具体情况根据数据库的故障原因而定。
下面将结合附图5-附图8，对本发明实施例提供的一种故障处理的装置进行详细介绍。需要说明的是，附图5-附图8所述的故障处理的装置可应用于执行上述附图1-附图4所示的方法。
请参见图5，为本发明实施例提供的一种故障处理的装置的结构示意图；该装置可包括：获取单元101、第一重启单元102和第二重启单元103。
获取单元101，用于获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态。
具体地，获取正在运行的数据库的状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态。其中，所述待处理事件的个数为所述正在运行的数据库中等待处理的事件的个数，在Informix数据库中为ready队列的长度，若所述待处理事件的个数异常，将会导致数据库运行速度缓慢、性能降低。所述数据库实例状态为所述数据库中正在运行的实例状态，当所述数据库实例状态处于online状态时表明所述数据库实例状态为正常运行状态，当所述数据库实例状态未处于online状态时表明所述数据库实例状态为异常运行状态，若所述数据库实例状态处于异常状态将引起数据库宕机。现有技术中的数据库只是一味地执行命令，无法检测状态以致数据库出现故障时便停止运行，通过获取所述状态检测参数可以检测到所述数据库是否发生故障，还可以根据所述状态检测参数判断故障的类型。
第一重启单元102，用于当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库。
具体地，根据所述状态参数来判断所述数据库的故障类型，当所述状态检测参数包括待处理事件的个数时，表明所述待处理事件的个数异常，可能会导致所述数据库出现性能故障状态。为了进一步地确认所述数据库当前状态为性能故障状态，需要根据所述待处理事件的个数检测数据库当前状态。若检测出所述数据库当前状态为性能故障状态，则通过切换用户模式并重新启动所述数据库以使所述数据库从故障状态中恢复。
第二重启单元103，用于当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。
具体地，根据所述状态参数来判断所述数据库的故障类型，当所述状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。为了进一步地确认所述数据库当前状态为宕机故障状态，需要根据所述数据库实例状态检测数据库当前状态。若检测出所述数据库当前状态为宕机故障状态，则重新启动所述数据库以使所述数据库从故障状态中恢复。
当所述状态检测参数同时包括所述待处理事件的个数和所述数据库实例状态时，可以同时调用第一重启单元102和第二重启单元103，实现对两种故障状态的处理。
本发明实施例通过获取状态检测参数，根据所述状态检测参数确定数据库当前状态的故障类型并根据故障类型重新启动数据库，恢复数据库的正常运行，实现了自动检测故障并从故障状态中恢复，提高了数据库的处理效率和可用性。
请参见图6，本发明实施例提供的一种故障处理的装置的结构示意图；该装置可包括：获取单元101、第一结果获取单元201、第一确定单元202和第一重启单元102，其中，所述第一重启单元包括：第一发送单元203和第一数据库重启单元204。
获取单元101，为图5所示的获取单元101，在此不再赘述。
第一结果获取单元201，用于当所述获取模块获取到的状态检测参数包括待处理事件的个数时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为性能故障结果。
具体地，当获取到的状态检测参数包括待处理事件的个数时，表明所述待处理事件的个数异常，可能会导致所述数据库出现性能故障状态。通过获取至少一个探测结果来判断所述数据库当前状态是否为性能故障状态。所述至少一个探测结果一般为两个探测结果，用于判断得到的性能故障状态更加准确。所述两个探测结果的探测间隔时间是一个固定值，为所述数据库休眠的时间，每隔一个探测间隔时间，数据库就会获取到一个探测结果。判断所述至少一个探测结果是否均为性能故障结果来确定所述数据库当前状态。
其中，所述性能故障结果包括所述待处理事件的个数高于预设的个数阈值的结果，所述预设的个数阈值为所述数据库正常运行时所承受的待处理事件的个数的最大值，即ready队列长度的最大值。若探测到所述待处理事件的个数低于或等于预设的个数阈值，则表明探测结果为正常结果。
第一确定单元202，用于当所述至少一个探测结果均为所述性能故障结果时，确定所述数据库当前状态为性能故障状态。
具体地，当所述至少一个探测结果均为所述性能故障结果时，即获取到的两个连续的探测结果均为所述性能故障结果，可以确定所述数据库当前状态为性能故障状态。若第一探测结果为性能故障结果，经过探测间隔时间后获取的第二探测结果为正常结果，则所述数据库当前状态为正常结果状态；若第一探测结果为正常状态结果，经过探测间隔时间后获取的第二探测结果为性能故障状态结果，则无法判断所述数据库当前状态，需再次获取第三探测结果来判断所述数据库当前状态。只有当所述至少一个探测结果均为所述性能故障结果时，才能确定所述数据库当前状态为性能故障状态。若无法判断所述数据库当前状态或所述数据库当前状态为正常状态，获取状态检测参数，检测所述数据库是否处于故障状态。
第一发送单元203，用于当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，向管理端发送告警信息。
由第一确定单元202判断得出所述数据库当前状态为性能故障状态，将所述性能故障状态的信息记录于所述数据库的告警文件中并向管理端发送告警信息。所述告警信息用于通知所述管理端所述数据库处于所述性能故障状态并将自动恢复。
第一数据库重启单元204，用于根据所述性能故障状态切换用户模式为单用户模式，并重新启动数据库。
其中，所述用户模式包括单用户模式和多用户模式，当所述数据库的待处理事件的个数低于或等于所述预设的个数阈值时，所述数据库采用多用户模式处理待处理事件，一旦所述数据库当前状态为性能故障状态时，采用多用户模式处理将严重影响所述数据库的运行速度并降低所述数据库的性能。因此，将用户模式切换为单用户模式，依次处理待处理事件直到所述待处理事件的个数低于或等于所述预设的个数阈值并重新启动所述数据库以使所述数据库从故障状态中恢复。
为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过当获取到的状态检测参数包括待处理事件的个数并判断获取至少一个探测结果是否均为性能故障结果，实现了对性能故障状态的处理，完成了性能故障状态的检测、告警以及自动恢复，提高了数据库的性能，增强了数据库的主动性。
请参见图7，本发明实施例提供的一种故障处理的装置的结构示意图；该装置可包括：获取单元101、第二结果获取单元301、第二确定单元302、第一检测单元303、第二检测单元304、确定宕机单元305和第二重启单元103，其中，所述第二重启单元103包括：第二发送单元306和第二数据库重启单元307。
获取单元101，为图5所示的获取单元101，在此不再赘述。
第二结果获取单元301，用于当所述获取模块获取到的状态检测参数包括数据库实例状态时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为宕机故障结果。
具体地，当获取到的状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。通过获取至少一个探测结果来判断所述数据库当前状态是否为宕机故障状态。所述至少一个探测结果一般为两个探测结果，用于判断得到的宕机故障状态更加准确。所述两个探测结果的探测间隔时间是一个固定值，为所述数据库休眠的时间，每隔一个探测间隔时间，数据库就会获取到一个探测结果。判断所述至少一个探测结果是否均为宕机故障结果来确定所述数据库当前状态。
其中，所述宕机故障结果包括所述数据库实例状态为异常工作状态的结果，这是所述数据库实例状态未处于online状态。
第二确定单元302，用于当所述至少一个探测结果均为所述宕机故障结果时，确定所述数据库当前状态为宕机故障状态。
具体地，当所述至少一个探测结果均为所述宕机故障结果时，即获取到的两个连续的探测结果均为所述宕机故障结果，可以确定所述数据库当前状态为宕机故障状态。若第一探测结果为宕机故障结果，经过探测间隔时间后获取的第二探测结果为正常结果，则所述数据库当前状态为正常结果状态；若第一探测结果为正常状态结果，经过探测间隔时间后获取的第二探测结果为宕机故障状态结果，则无法判断所述数据库当前状态，需再次获取第三探测结果来判断所述数据库当前状态。只有当所述至少一个探测结果均为所述宕机故障结果时，才能确定所述数据库当前状态为宕机故障状态。若无法判断所述数据库当前状态或所述数据库当前状态为正常状态时，获取状态检测参数，检测所述数据库是否处于故障状态。
第一检测单元303，用于检测数据库实例的进程是否存在。
第二确定单元302能够确定所述数据库当前状态为所述宕机故障状态，但是并不清楚是所述数据库中的具体哪个实例发生了宕机，因此需要检测数据库实例进程以及宕机故障状态来查找宕机实例。首先，检测数据库实例的进程是否存在，若存在则表明所述数据库实例未发生宕机，获取状态检测参数，检测所述数据库是否处于故障状态。
第二检测单元304，用于当所述第一检测单元检测到所述数据库实例的进程不存在时，检测所述宕机故障状态是否包括目标关键字。
当所述第一检测单元303检测到所述数据库实例的进程不存在时，表明所述数据库实例可能发生了宕机，需要通过检测所述宕机故障状态是否包括目标关键字来进一步确认。其中，所述目标关键字包括所述数据库实例的名称、shared memory not initialized。
确定宕机单元305，用于当所述第二检测单元检测到所述宕机故障状态不包括目标关键字时，确定所述数据库实例为宕机实例。
第二发送单元306，用于当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，向所述管理端发送实例宕机信息。
由第二确定单元302判断得出所述数据库当前状态为宕机故障状态且查找到宕机实例，将所述宕机故障状态的信息以及所述宕机实例记录于所述数据库的告警文件中并向管理端发送告警信息。所述告警信息用于通知所述管理端所述数据库处于所述宕机故障状态并将自动恢复。
第二数据库重启单元307，用于根据所述宕机故障状态重新启动所述数据库。
根据所述宕机故障状态重新启动所述数据库以使所述数据库从故障状态中恢复。
同样，为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过获取到的状态检测参数包括数据库实例状态并判断获取至少一个探测结果是否均为宕机故障结果以及查找宕机实例，实现了对宕机故障状态的处理，完成了宕机故障状态的检测、告警以及自动恢复，脱离了人工操作，缩短了恢复时间，提高了数据库的运行效率。
其中，图6中的各个单元可以与图7中的各个单元处于同一个故障处理的装置中，即所述故障处理的装置可以包括：获取单元101、第一结果获取单元201、第一确定单元202、第一重启单元102、第二结果获取单元301、第二确定单元302、第一检测单元303、第二检测单元304、确定宕机单元305、第二重启单元103，其中，所述第一重启单元包括：第一发送单元203和第一数据库重启单元204，所述第二重启单元103包括：第二发送单元306和第二数据库重启单元307。所述故障处理的装置可以在检测出性能故障的同时，又可以检测出宕机故障，并同时对性能故障和宕机故障进行恢复。
请参见图8，为本发明实施例提供的另一种故障处理的装置的结构示意图；该装置可包括：获取单元101、第一重启单元102、第二重启单元103和第三重启单元104。
获取单元101，用于获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态。
第一重启单元102，用于当所述状态检测参数包括待处理事件的个数，且根据所述待处理事件的个数检测出数据库当前状态为性能故障状态时，切换用户模式并重新启动数据库。所述第一重启单元102的具体实现方式可以参见上述图5对应实施例中的第一重启单元102，或参见上述图6对应实施例中的第一重启单元102，这里不再进行赘述。
第二重启单元103，用于当所述状态检测参数包括数据库实例状态，且根据所述数据库实例状态检测出所述数据库当前状态为宕机故障状态时，重新启动所述数据库。所述第一重启单元103的具体实现方式可以参见上述图5对应实施例中的第二重启单元103，或参见上述图7对应实施例中的第二重启单元103，这里不再进行赘述。
第三重启单元104，用于当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，重新启动所述数据库。
具体地，当所述状态检测参数包括数据库实例状态时，表明所述数据库实例状态处于异常状态，并非online状态，可能会导致所述数据库出现宕机故障状态。宕机故障状态除了所述数据库实例异常外，还包括客观原因，如数据库地址和所述数据库的端口网络状态异常，因此需要数据库地址和所述数据库的端口网络状态是否正常。当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，表明所述数据库当前状态为宕机故障状态，需要通过重新启动所述数据库以使所述数据库从故障状态中恢复。
同样，为了保证重新启动后的数据库处于正常运行状态，需检测所述数据库的运行状态，若检测到所述数据库的运行状态处于正常状态则表明所述数据库已从故障状态中恢复。
本发明实施例通过检测数据库地址和所述数据库的端口网络状态是否正常来判断所述数据库当前状态是否为宕机故障状态，完成了宕机故障状态的检测以及自动恢复，脱离了人工操作，缩短了恢复时间，提高了数据库的运行效率。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。
以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。
Claims (10)
1.一种故障处理的方法，其特征在于，包括：
获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态；
当获取到的状态检测参数包括待处理事件的个数时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为性能故障结果；当所述至少一个探测结果均为所述性能故障结果时，确定所述数据库当前状态为性能故障状态，根据所述性能故障状态切换用户模式并重新启动数据库，所述性能故障结果包括所述待处理事件的个数高于预设的个数阈值的结果；
当获取到的状态检测参数包括数据库实例状态时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为宕机故障结果；当所述至少一个探测结果均为所述宕机故障结果时，确定所述数据库当前状态为宕机故障状态，根据所述宕机故障状态重新启动所述数据库，所述宕机故障结果包括所述数据库实例状态为异常工作状态的结果。
2.根据权利要求1所述的方法，其特征在于，所述根据所述性能故障状态切换用户模式并重新启动数据库，包括：
根据所述性能故障状态向管理端发送告警信息；
根据所述性能故障状态切换用户模式为单用户模式，并重新启动数据库。
3.根据权利要求1所述的方法，其特征在于，所述根据所述宕机故障状态重新启动所述数据库，包括：
根据所述宕机故障状态向管理端发送实例宕机信息；
根据所述宕机故障状态重新启动所述数据库。
4.根据权利要求1所述的方法，其特征在于，在所述当所述至少一个探测结果均为所述宕机故障结果时，确定所述数据库当前状态为宕机故障状态的步骤之后，还包括：
检测数据库实例的进程是否存在；
当检测到所述数据库实例的进程不存在时，检测所述宕机故障状态是否包括目标关键字；
当检测到所述宕机故障状态不包括目标关键字时，确定所述数据库实例为宕机实例。
5.根据权利要求1所述的方法，其特征在于，还包括：
当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，重新启动所述数据库。
6.一种故障处理的装置，其特征在于，包括：
获取单元，用于获取状态检测参数，所述状态检测参数包括待处理事件的个数或数据库实例状态；
第一重启单元，用于当所述获取单元获取到的状态检测参数包括待处理事件的个数时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为性能故障结果；当所述至少一个探测结果均为所述性能故障结果时，确定所述数据库当前状态为性能故障状态，根据所述性能故障状态，根据所述性能故障状态切换用户模式并重新启动数据库，所述性能故障结果包括所述待处理事件的个数高于预设的个数阈值的结果；
第二重启单元，用于当所述获取单元获取到的状态检测参数包括数据库实例状态时，获取至少一个探测结果，并判断所述至少一个探测结果是否均为宕机故障结果；当所述至少一个探测结果均为所述宕机故障结果时，确定所述数据库当前状态为宕机故障状态，根据所述宕机故障状态重新启动所述数据库，所述宕机故障结果包括所述数据库实例状态为异常工作状态的结果。
7.根据权利要求6所述的装置，其特征在于，所述第一重启单元包括：
第一发送单元，用于根据所述性能故障状态向管理端发送告警信息；
第一数据库重启单元，用于根据所述性能故障状态切换用户模式为单用户模式，并重新启动数据库。
8.根据权利要求7所述的装置，其特征在于，所述第二重启单元包括：
第二发送单元，用于根据所述宕机故障状态向管理端发送实例宕机信息；
第二数据库重启单元，用于根据所述宕机故障状态重新启动所述数据库。
9.根据权利要求6所述的装置，其特征在于，还包括：
第一检测单元，用于检测数据库实例的进程是否存在；
第二检测单元，用于当所述第一检测单元检测到所述数据库实例的进程不存在时，检测所述宕机故障状态是否包括目标关键字；
确定宕机单元，用于当所述第二检测单元检测到所述宕机故障状态不包括目标关键字时，确定所述数据库实例为宕机实例。
10.根据权利要求6所述的装置，其特征在于，还包括:
第三重启单元，用于当检测到所述数据库的地址和所述数据库的端口网络状态均异常时，重新启动所述数据库。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410594247.0A CN104408059B (zh) | 2014-10-29 | 2014-10-29 | 一种故障处理的方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410594247.0A CN104408059B (zh) | 2014-10-29 | 2014-10-29 | 一种故障处理的方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104408059A CN104408059A (zh) | 2015-03-11 |
| CN104408059B true CN104408059B (zh) | 2019-03-01 |
Family
ID=52645691
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410594247.0A Active CN104408059B (zh) | 2014-10-29 | 2014-10-29 | 一种故障处理的方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104408059B (zh) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109240876B (zh) * | 2018-07-18 | 2022-05-27 | 平安科技（深圳）有限公司 | 实例监控方法、计算机可读存储介质和终端设备 |
| CN109739674B (zh) * | 2018-12-17 | 2021-06-25 | 网联清算有限公司 | 交易数据库的异常检测方法、装置及存储介质 |
| CN110532278B (zh) * | 2019-10-30 | 2020-01-31 | 上海爱可生信息技术股份有限公司 | 声明式的MySQL数据库系统高可用方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7627777B2 (en) * | 2006-03-17 | 2009-12-01 | Microsoft Corporation | Fault tolerance scheme for distributed hyperlink database |
| CN101296135A (zh) * | 2008-06-27 | 2008-10-29 | 中兴通讯股份有限公司 | 故障信息的处理方法和装置 |
| CN102571465A (zh) * | 2010-12-21 | 2012-07-11 | 鸿富锦精密工业（深圳）有限公司 | 服务器异常告警系统及方法 |
| CN103678095A (zh) * | 2012-09-03 | 2014-03-26 | 鼎桥通信技术有限公司 | 一种告警检测方法 |
| CN103490919A (zh) * | 2013-09-02 | 2014-01-01 | 用友软件股份有限公司 | 故障管理系统和故障管理方法 |
-
2014
- 2014-10-29 CN CN201410594247.0A patent/CN104408059B/zh active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN104408059A (zh) | 2015-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106685676B (zh) | 一种节点切换方法及装置 | |
| CN111290918B (zh) | 服务器运行状态监控方法、装置及计算机可读存储介质 | |
| CN104486100B (zh) | 故障处理装置及方法 | |
| CN103259688B (zh) | 一种分布式存储系统的故障诊断方法与装置 | |
| US20150033076A1 (en) | Anomaly detection system, anomaly detection method, and program for the same | |
| EP3335384A1 (en) | Systems and methods for managing network health | |
| CN106789306B (zh) | 通信设备软件故障检测收集恢复方法和系统 | |
| CN104408059B (zh) | 一种故障处理的方法及装置 | |
| CN101188527B (zh) | 一种心跳检测方法和装置 | |
| CN104796273A (zh) | 一种网络故障根源诊断的方法和装置 | |
| US20130311835A1 (en) | Forecasting workload transaction response time | |
| CN108337266B (zh) | 一种高效的协议客户端漏洞发掘方法与系统 | |
| CN109413016B (zh) | 一种基于规则的报文检测方法和装置 | |
| CN103414916A (zh) | 一种故障诊断系统及方法 | |
| CN110213065A (zh) | 一种路径切换的方法及装置 | |
| CN107102929A (zh) | 故障的检测方法及装置 | |
| CN108304276B (zh) | 一种日志处理方法、装置及电子设备 | |
| CN102761432B (zh) | Cgi监控方法及其装置和系统 | |
| CN103731315A (zh) | 一种服务器故障检测方法 | |
| CN110598797B (zh) | 故障的检测方法及装置、存储介质和电子装置 | |
| CN105530110A (zh) | 一种网络故障检测方法以及相关网元 | |
| CN108512698B (zh) | 一种网络容灾方法、装置及电子设备 | |
| AU2014200806B1 (en) | Adaptive fault diagnosis | |
| CN112994947A (zh) | 一种网络运维方法、装置、存储介质及电子设备 | |
| JP6984119B2 (ja) | 監視装置、監視プログラム、及び監視方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |