CN113656358A - 一种数据库日志文件处理方法及系统 - Google Patents

Abstract

本发明公开了一种数据库日志文件处理方法及系统，该方法包括：监听第一数据库日志文件的大小，判断第一数据库日志文件的大小是否超过第一预设阈值；在第一数据库日志文件的大小超过第一预设阈值的情况下，对第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务；判断第一数据库日志文件是否满足切割归档条件；在第一数据库日志文件满足切割归档条件的情况下，确定第一数据库日志文件的日志类型，并根据日志类型对第一数据库日志文件进行切割归档处理。本发明保证在不影响数据库在线实时业务的情况下进行大日志文件的切割和归档，实现对线上运行的数据库进行标准化、自动化日志切割归档，极大的提高了数据库稳定性。

Description

一种数据库日志文件处理方法及系统

技术领域

本发明涉及计算机技术领域，具体涉及一种数据库日志文件处理方法及系统。

背景技术

数据库的日志管理是数据库运维的重要部分。以支付清算平台为例，由于实时业务的交易数据均存储在MySQL数据库中，因此，在实施业务不间断运行、交易量巨大的情况下，MySQL日志也随之快速增长。大容量的日志文件会导致磁盘空间占用率过高，IO吞吐资源消耗过大，业务处理资源受损等问题，因此，需要对日志进行管理。

发明内容

有鉴于此，本发明实施例提供了一种数据库日志文件处理方法及系统，解决现有技术中由于数据库上线后会产生大日志文件，导致磁盘空间占用率过高，IO吞吐资源消耗过大，业务处理资源受损的问题。

为达到上述目的，本发明提供如下技术方案：

第一方面，本发明实施例提供一种数据库日志文件处理方法，包括：监听第一数据库日志文件大小，判断所述第一数据库日志文件的大小是否超过第一预设阈值；在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，对所述第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务，所述预设时间表示允许对数据库日志文件进行切割归档处理的时间，所述定时任务用于定时切割归档数据库日志文件；判断所述第一数据库日志文件是否满足切割归档条件；在所述第一数据库日志文件满足切割归档条件的情况下，确定所述第一数据库日志文件的日志类型，并根据所述日志类型对所述第一数据库日志文件进行切割归档处理。

在一实施例中，所述根据所述日志类型对所述第一数据库日志文件进行切割归档处理，包括：确定所述日志类型对应的切割归档函数；利用所述切割归档函数对所述第一数据库日志文件进行切割归档，输出目标日志文件。

在一实施例中，在确定所述日志类型对应的切割归档函数之后，在利用所述切割归档函数对所述第一数据库日志文件进行切割归档之前，还包括：获取会话级别的日志，判断所述会话级别的日志是否开启；当所述会话级别的日志开启时，关闭会话级别的日志。

在一实施例中，所述利用所述切割归档函数对所述第一数据库日志文件进行切割归档，输出目标日志文件，包括：生成唯一对应所述第一数据库日志文件的日志名称；根据所述日志名称建立归档目录；将日志文件移动到所述归档目录下，对所述第一数据库日志文件进行切割归档，输出目标日志文件。

在一实施例中，所述判断所述第一数据库日志文件是否满足切割归档条件，包括：判断数据库的磁盘剩余空间是否小于第二预设阈值；在所述数据库的磁盘剩余空间小于所述第二预设阈值的情况下，判定结果为所述第一数据库日志文件满足切割归档条件。

在一实施例中，本发明实施例提供的数据库日志文件处理方法，还包括：在所述第一数据库日志文件不满足切割归档条件的情况下，生成所述第一数据库日志文件切割归档失败的标志文件，并发送所述第一数据库日志文件切割归档失败的消息至数据库管理后台。

在一实施例中，在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，所述数据库日志文件处理方法还包括：发送所述第一数据库日志文件已经闭锁的信息至数据库管理后台并建立第二数据库日志文件，所述第二数据库日志文件用于记录在所述第一数据库日志文件闭锁的情况下产生的日志。

第二方面，本发明实施例提供一种数据库日志文件处理系统，包括如下模块，第一判断模块，用于监听第一数据库日志文件的大小，判断所述第一数据库日志文件的大小是否超过第一预设阈值；定时任务启动模块，用于在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，对所述第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务；第二判断模块，用于判断所述第一数据库日志文件是否满足切割归档条件；切割归档模块，用于在所述第一数据库日志文件满足切割归档条件的情况下，确定所述第一数据库日志文件的日志类型，并根据所述日志类型对所述第一数据库日志文件进行切割归档处理。

第三方面，本发明实施例提供一种电子设备，包括：至少一个处理器，以及与至少一个处理器通信连接的存储器，其中，存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器执行本发明实施例第一方面的数据库日志文件处理方法。

第四方面，本发明实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令用于使计算机执行本发明实施例第一方面的数据库日志文件处理方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本发明提供的数据库日志文件处理方法及系统，通过对数据库日志文件的大小进行监听，在数据库日志文件的大小超过第一预设阈值的情况下，启动预先配置定时任务，保证在不影响数据库在线实时业务的情况下进行大日志文件的切割和归档；当达到预设时间并且数据库日志文件满足切割归档条件时，确定数据库日志文件的日志类型，通过检查对应的日志类型，避免因为遗漏部分检查项导致数据库实时业务受到影响；然后对每个日志类型对应的数据库日志文件进行切割归档，真正实现对线上正在运行的数据库进行标准化、自动化日志切割、归档，避免了大日志文件出现的隐患，极大的提高了数据库稳定性。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的数据库日志文件处理方法的一个具体示例的流程图；

图2为本发明实施例提供的数据库日志文件进行切割归档的一个具体示例的流程图；

图3为本发明实施例提供的数据库日志文件处理方法的另一个具体示例的流程图；

图4为本发明实施例提供的数据库日志文件处理系统示意图；

图5为本发明实施例提供的电子设备一个具体示例的组成图。

具体实施方式

下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本发明的描述中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，还可以是两个元件内部的连通，可以是无线连接，也可以是有线连接。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

此外，下面所描述的本发明不同实施方式中所涉及的技术特征只要彼此之间未构成冲突就可以相互结合。

实施例1

本发明实施例提供一种数据库日志文件处理方法，应用在数据库运维中对数据库的大日志文件进行切割归档，如图1所示，包括如下步骤：

步骤S1：监听第一数据库日志文件的大小，判断第一数据库日志文件的大小是否超过第一预设阈值。

本发明实施例中，在数据库运维过程中，每个数据库至少具有两个操作系统文件：一个数据文件和一个日志文件，其中，日志文件包含恢复数据库中的所有事务所需的信息，为了便于分配和管理，可以将数据文件集合起来，放到文件组中。事务日志文件保存用于恢复数据库的日志信息，对数据库的每次操作，都会在日志文件中有相应的记录，为了防止数据丢失，或者出现异常的情况时，对数据进行有效的恢复，每个数据库必须至少有一个日志文件。

在实际应用中，数据库处于在线运行的状态时用户避免不了会直接对比较大的数据库日志文件进行查看，然而对大日志文件进行查看可能会影响线上的实时任务。此时就需要对数据库的日志文件进行切割，其实数据库本身没有对日志文件进行切割的服务，一般数据库管理员也不会对数据库进行日志切割和归档，在使用过程中，通用的方式是通过手动方式对数据库进行移除管理。但是当文件过大时，如果进行删除操作，也会影响IO，因而无法确保业务正常交易的耗时，经常会出现在某一天问题爆发出来，对于分布式数据库集群单纯靠人工检查处理，人力成本高，不仅耗时长，而且很容易遗漏部分检查项，遗漏后将可能导致业务受到影响。因此针对在线实时业务，通过对日志自动化切割和归档，并且预先配置好定时任务，定时任务中设置有切割归档启动时间，用于定时切割归档数据库日志文件。

本发明实施例的实时监听第一数据库日志文件的大小，判断第一数据库日志文件的大小是否超过第一预设阈值，以实现对大日志文件的及时发现、及时处理，需要说明的是，第一预设阈值是根据系统实际需求进行设定的，在实际应用中也可以根据实践经验进行设定，本发明并不以此为限。

步骤S3：在第一数据库日志文件的大小超过第一预设阈值的情况下，对第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务。

本发明实施例中，当监听并判断出第一数据库日志文件的大小超过第一预设阈值时，说明此时数据库日志文件过大，需要进行切割归档并且不宜再对当前数据库日志文件也就是第一数据库日志文件进行操作，在第一数据库日志文件大小超过第一预设阈值的情况下，在预设时间启动预先配置的定时任务，定时任务还有设置有任务内容，包括切割归档的日志文件的日志类型、归档的位置等信息。启动定时任务之后，可以通过计时的方式确定切割归档日志文件的开始时间。

其中，预设时间表示允许对第一数据库日志文件进行切割归档处理的时间，例如，设置的切割归档启动时间为凌晨3点，那么在启动定时任务之后，当达到凌晨3点的时间时，就可以开始判断是否进行日志文件的切割归档，然后自动进行日志文件的切割归档，不需要人工进行数据库日志文件查看。切割归档启动时间可以设置在不影响正常业务运行的时间，在该时间进行大日志文件的自动切割归档，真正实现数据库慢日志、错误日志、通用日志归档自动化。解决人力成本高、耗时长、多件过大、IO过大导致业务受影响的问题。

需要说明的是，本发明实施例中预设时间和预先配置的定时任务都是根据实际需要进行设置的，在实际应用中可以根据具体系统操作规则和操作习惯进行设定，本发明并不以此为限。

步骤S5：判断第一数据库日志文件是否满足切割归档条件。

本发明实施例中，当达到预设时间，即切割归档启动时间，判断第一数据库日志文件是否满足切割归档条件，也就是说，不是到达预先设置的切割归档启动时间就直接进行日志文件的切割归档，还需要进一步的判断第一数据库日志文件是否满足预先设定的数据库日志的切割归档条件，这样能够避免一些不必要的日志文件切割归档。需要说明的是，本发明实施例中进行判断的切割归档条件是根据实际需要以及数据库系统的需求进行设定的，本发明并不以此为限。

步骤S7：在第一数据库日志文件满足切割归档条件的情况下，确定第一数据库日志文件的日志类型，并根据日志类型对第一数据库日志文件进行切割归档处理。

本发明实施例中，当判定第一数据库日志文件满足切割归档条件时，读取定时任务中的数据库日志文件的日志类型，通过对每个日志类型进行检查，然后根据检查结果对切割后的第一数据库日志文件进行归档，将读取到的定时任务中的数据库日志文件的日志类型进行统计与记录，然后根据每个日志类型将对应的数据库日志文件进行切割归档，将相应的所有数据库日志类型一一进行比对，进而可以解决漏查的问题，提高数据库日志文件切割归档的准确性以及保证第一数据库日志文件切割归档的时效性。需要说明的是，在实际应用中数据库日志文件的日志类型是根据数据库系统的实际需要进行设定的，其日志类型及日志类型数量都可以根据需要进行适应性的选择及更改，本发明并不以此为限。

在实际应用中，数据库日志类型可以包括：慢日志、错误日志及通用日志，其中通用日志包括：普通查询日志，binlog日志，中继日志等。不同的日志对应不同的日志文件，不同类型的数据库日志可以采用不同的切割归档函数，需要说明的是，切割归档函数是根据数据库日志的不同进行适应性自定义的函数，可以根据实际应用进行选择和设定，本发明并不以此为限。

错误日志是指默认开启记录服务在启动和运行过程中产生的错误信息，在MySQL数据库中，错误信息位置log-error＝/var/log/mysqld.log，并且包含以下表示错误信息的语句“mysql>show global variables like'log_error'”；慢日志用于记录超过指定时间后才显示查询结果的sql命令，存放目录位于/var/lib/mysql，其中包含以下语句“mysql>show global variables like'slow_query_log'”；普通查询日志用于记录所有sql命令，其中普通查询日志存放目录位于/var/lib/mysql，并且包含以下语句“mysql>show globalvariables like'general_log'”；binlog日志又被称作是MySQL数据库的二进制日志，用于记录用户对数据库操作的sql语句(除了数据查询语句)信息，并且此binlog日志存放目录位于/var/lib/mysql，需要使用mysqldump工具查看，其中包含以下语句“mysql>showglobal variables like 'log_bin'”；中继日志主要用于恢复数据，存放目录位于/var/lib/mysql，因为中继日志也是二进制日志，所以也需要使用mysqldump工具查看。

在实际应用中，binlog的格式也有三种：

1、STATMENT模式：基于sql语句的复制(statement-based replication,SBR)，每一条会修改数据的sql语句并记录到binlog中。此模式的优点是：不需要记录每一条sql语句与每行的数据变化，这样子binlog的日志也会比较少，减少了磁盘IO，提高性能；缺点是：在某些情况下会导致数据不一致(如sleep()函数，last_insert_id()，以及user-definedfunctions(udf)等会出现问题)。

2、基于行的复制(row-based replication,RBR)：不记录每一条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成了什么样子了。此模式的优点是：不会出现某些特定情况下的存储过程的调用和触发无法被正确复制的问题；缺点是：会产生大量的日志，尤其是会让日志暴涨。

3、混合模式复制(mixed-based replication,MBR)：以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作，会根据执行的sql语句选择日志保存方式。

需要说明的是，本发明实施例中仅仅举例说明了几种数据库的日志类型，在实际应用中可能还包含其他日志类型，本发明实施例并没有一一枚举，本发明并不以此为限。

本发明提供的数据库日志文件处理方法，通过对数据库日志文件的大小进行监听，在数据库日志文件的大小超过第一预设阈值的情况下，启动预先配置定时任务，保证在不影响数据库在线实时业务的情况下进行大日志文件的切割和归档；当达到预设时间并且数据库日志文件满足切割归档条件时，确定数据库日志文件的日志类型，通过检查对应的日志类型，避免因为遗漏部分检查项导致数据库实时业务受到影响；然后对每个日志类型对应的数据库日志文件进行切割归档，真正实现对线上正在运行的数据库进行标准化、自动化日志切割、归档，避免了大日志文件出现的隐患，极大的提高了数据库稳定性。

在一具体实施例中，根据日志类型对第一数据库日志文件进行切割归档处理，包括如下步骤：

步骤S71：确定日志类型对应的切割归档函数。

本发明实施例中，归档日志是当数据库运行在归档模式下时，一个日志组写满后，由进程将重做日志的内容备份到归档日志文件下，然后这个日志组才能被下一次使用，其中重做日志的目的是万一实例或者介质失败，重做日志文件就能派上用场。不管数据库是否处于归档模式，重做日志是肯定要写的，而只有数据库在归档模式下，重做日志才会备份，形成归档日志。一般来说，归档日志结合全备份，用于数据库出现问题后的恢复使用。

在实际应用中，重做日志是循环使用的，比如说，有三个重做日志组A、B、C。那么，当A写满后，系统就调用进程，将A备份为归档日志，同时B已经开始使用了，假设只有两个组A、B，如果某种情况下，A正在备份，未结束，还不能继续使用，而B也写满了，这个时候，数据库就会出现挂起的情况。所以一般情况下，重做日志最好是三个组或者再多一点，而且大小要适当。实际上，一个重做日志组满了后，就开始写入归档日志，不是等A、B、C都写满了再归档，而且归档日志和重做日志都是物理上的文件，只是存放的目录不同，而且重做日志的文件名不变，而归档日志的文件名是备份时系统生成的，也就是生成的数据库日志文件的唯一日志名称。在对日志文件进行切割归档时，要调用每个日志类型对应的切割归档函数，以完成对各个日志类型的日志文件的切割归档操作。需要说明的是，本发明实施例仅以调用切割归档函数为例进行说明，还可以是自动嵌入一段实现切割归档目的的代码在运行文件中等其他相关操作，本发明并不以此为限。

步骤S73：利用切割归档函数对第一数据库日志文件进行切割归档，输出目标日志文件。

本发明实施例中，利用切割归档函数对每个日志类型对应的数据库日志文件进行切割归档，输出目标日志文件，实际应用中如果数据库日志文件存在多个不同类型时，相当于这个步骤多次执行，每次执行时采用各自对应的函数即可实现，这样就将大日志文件进行了切割，并且完成相应的归档，最终完成了一次数据库日志的备份，就避免了大日志文件的出现，并且在大日志文件被直接查看后，极大的影响系统稳定性的问题。需要说明的是，最后输出的目标日志文件，就是切割归档后的备份文件。

在一具体实施例中，如图2所示，在确定日志类型对应的切割归档函数之后，在利用切割归档函数对第一数据库日志文件进行切割归档之前，还包括如下步骤：

步骤S703：获取会话级别的日志，判断会话级别的日志是否开启。

本发明实施例中，首先获取数据库文件中会话级别的日志，然后判断会话级别的日志是否开启，其中，会话级别的日志文件是否开启也是需要对此日志文件进行检测，例如：通过以下语句“mysql>show variables like'log_％'”检测是否启用了此日志文件。需要说明的是，本发明实施例中，判断日志文件是否开启的语句仅仅是举例进行说明的，本发明并不以此为限。

步骤S723：当会话级别的日志开启时，关闭会话级别的日志。

本发明实施例中，当检测到会话级别的日志开启时，需要把此会话级别的日志文件关闭，确保不会记录到数据库的binlog日志中，保证数据库文件主备的gtid一致性，并且对执行过程进行记录日志，如有异常可根据日志排查问题。其中，gtid(A globaltransaction identifier)全局事物id，是创建的和提交事物相匹配的ID号，它不仅在本机上是唯一的，而且在其他服务器上也是唯一的，gitd与事物一一对应，每次提交事物的时候就会自动创建gtid。

在一具体实施例中，利用切割归档函数对第一数据库日志文件进行切割归档，输出目标日志文件，包括如下步骤：

步骤S731：生成唯一对应第一数据库日志文件的日志名称。

本发明实施例中，首先生成第一数据库日志文件的日志名称，并且要保证此日志名称是唯一的，与之前生成的日志名称完全不同，同一时间触发可操作执行，保证日志文件不丢失，并且保证切割归档数据库日志文件的唯一性以及准确性。

步骤S733：根据日志名称建立归档目录。

本发明实施例中，对满足日志文件切割归档条件的，根据各日志名称建立归档目录，便于后续操作。需要说明的是，归档目录是对应日志名称并且系统实际需求进行设置的，本发明并不以此为限。

步骤S735：将日志文件移动到归档目录下，对第一数据库日志文件进行切割归档，输出目标日志文件。

本发明实施例中，将需要切割归档的日志文件，移动到建立好的归档目录下，对第一数据库日志文件进行切割归档，输出目标日志文件，完成日志文件的备份。

在一具体实施例中，如图3所示，判断第一数据库日志文件是否满足切割归档条件，包括如下步骤：

在实际应用中，当达到切割归档的预设时间后，判断第一数据库日志文件是否满足切割归档条件，应该在数据库的磁盘剩余空间的判断之前，首先会定时检查日志文件是否开启，只有在日志文件开启的情况之下在进一步的判断磁盘剩余空间。其中，日志文件是否开启仅仅需要对日志文件进行检测，例如：通过以下语句“mysql>show variables like'log_％'”检测是否启用了日志。

步骤S51：判断数据库的磁盘剩余空间是否小于第二预设阈值。

本发明实施例中，在日志文件开启的情况下，还需要判断数据库的磁盘剩余空间是否小于第二预设阈值，在数据库的管理过程中，经常会遇到数据库增长过快，原来预计分配的磁盘空间或数据库空间不足的情况，当磁盘剩余可用空间过小时，就会造成系统的各种文件缺乏可用空间，降低了系统的运行效率。需要说明的是，本发明实施例中的第二预设阈值是根据实际经验及系统功能要求进行设定的，本发明并不以此为限。

步骤S53：在数据库的磁盘剩余空间小于第二预设阈值的情况下，判定结果为第一数据库日志文件满足切割归档条件。

本发明实施例中，当数据库的磁盘剩余空间小于第二预设阈值时，就需要按照定时任务的要求对第一数据库日志文件的切割归档，也就是可以判定第一数据库日志文件满足数据库日志文件的切割归档条件。因为当数据库的磁盘剩余空间不足时，会引起许多问题，致使系统无法正常运行，在本发明实施例举例说明磁盘空间不足的情况下，可能引起的mysql问题：mysql进程起不来；mysql无法正常关闭，必须强制关闭；mysql能起来，可是用户连接失败；mysql能连接上，可是会堵塞大部分查询。这些问题都将会影响数据库业务的正常运行。需要说明的是，本发明实施例中磁盘空间过小可能引起的问题也仅仅是举例进行说明，本发明并不以此为限。

步骤S55：在第一数据库日志文件不满足切割归档条件的情况下，生成第一数据库日志文件切割归档失败的标志文件，并发送第一数据库日志文件切割归档失败的消息至数据库管理后台。

本发明实施例中，当第一数据库日志文件不满足切割归档条件时，需要人为的进行干扰，手动关闭已经处于开启状态的日志文件，生成第一数据库日志文件切割归档失败的标志文件，将数据库日志文件进行备份移出当前磁盘，并清理磁盘空间，并发送数据库日志文件切割归档失败的消息至数据库管理后台，其中，标志文件时为了实现对系统的监控告警，实时的记录日志文件切割归档失败的原因，进而保证后续工作可以根据日志进行排查。需要说明的是，发送数据库日志文件切割归档失败的消息给数据库管理人员也可以通过网络有线或者无线的方式发送至管理人员的手机或应用软件中，本发明并不以此为限。

在一具体实施例中，在第一数据库日志文件的大小超过第一预设阈值的情况下，数据库日志文件处理方法还包括如下步骤：

步骤S9：发送第一数据库日志文件已经闭锁的信息至数据库管理后台并建立第二数据库日志文件，第二数据库日志文件用于记录在第一数据库日志文件闭锁的情况下产生的日志。

本发明实施例中，当第一数据库日志文件进行闭锁的情况下，发送当前数据库日志文件已经闭锁的消息至数据库管理后台，避免数据库管理人员以及业务人员进行不必要的重复劳动，如果需要对第一数据库日志文件在当前时间段内进行紧急操作，可以根据闭锁信息进行人为干预，将第一数据库日志文件进行切割归档，并将无需操作的归档文件备份移出当前磁盘，并且对此过程中产生的新的日志新建一个名称唯一的第二数据库日志文件，用于记录在第一数据库日志文件闭锁的情况下产生的日志。

本发明提供的数据库日志文件处理方法，通过生成数据库日志文件的唯一的日志名称，保证归档文件名称不重复，同一时间触发可操作执行并且保证日志文件不丢失；判断数据库日志文件是否满足切割归档条件的重要一步包括判断数据库的磁盘剩余空间，避免数据库的磁盘剩余空间过小引起许多问题，致使系统无法正常运行的问题；同时在对数据库日志文件进行切割归档之前还需要关闭会话级别的日志，确保不会记录到数据库的binlog日志中，保证数据库文件主备的gtid一致性，并且对执行过程进行记录日志，操作简单，本地执行程序脚本即可，对异常的排查可根据记录的日志进行，且不受系统权限管理约束。

实施例2

本发明实施例提供一种数据库日志文件处理系统，如图4所示，包括：

第一判断模块1，用于监听第一数据库日志文件的大小，判断第一数据库日志文件的大小是否超过第一预设阈值；此模块执行实施例1中的步骤S1所描述的方法，在此不再赘述。

定时任务启动模块2，用于在第一数据库日志文件的大小超过第一预设阈值的情况下，对第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务；此模块执行实施例1中的步骤S3所描述的方法，在此不再赘述。

第二判断模块3，用于判断第一数据库日志文件是否满足切割归档条件；此模块执行实施例1中的步骤S5所描述的方法，在此不再赘述。

切割归档模块4，用于在第一数据库日志文件满足切割归档条件的情况下，确定第一数据库日志文件的日志类型，并根据日志类型对第一数据库日志文件进行切割归档处理；此模块执行实施例1中的步骤S7所描述的方法，在此不再赘述。

本发明提供的数据库日志文件处理系统，通过对数据库日志文件大小进行监听，在数据库日志文件大小超过第一预设阈值的情况下，对数据库日志文件进行闭锁并启动预先配置定时任务，保证在不影响数据库在线实时业务的情况下进行大日志文件的切割和归档；当达到切割归档预设时间并且数据库日志文件满足切割归档条件时，确定定时任务中的数据库日志文件的日志类型，通过检查对应的日志类型，避免因为遗漏部分检查项导致数据库实时业务受到影响；然后对每个日志类型对应的数据库日志文件进行切割归档，通过生成数据库日志文件的唯一的日志名称，保证归档文件名称不重复，同一时间触发可操作执行并且保证日志文件不丢失；判断数据库日志文件是否满足切割归档条件的重要一步包括判断数据库的磁盘剩余空间，避免数据库的磁盘剩余空间过小引起许多问题，致使系统无法正常运行的问题；同时在对数据库日志文件进行切割归档之前还需要关闭会话级别的日志，确保不会记录到数据库的binlog日志中，保证数据库文件主备的gtid一致性，并且对执行过程进行记录日志，操作简单，本地执行程序脚本即可，对异常的排查可根据记录的日志进行，且不受系统权限管理约束，真正实现对线上正在运行的数据库进行标准化、自动化日志切割、归档，避免了大日志文件出现的隐患，极大的提高了数据库稳定性。

实施例3

本发明实施例提供一种电子设备，如图5所示，包括：至少一个处理器401，例如CPU(Central Processing Unit，中央处理器)，至少一个通信接口403，存储器404，至少一个通信总线402。其中，通信总线402用于实现这些组件之间的连接通信。其中，通信接口403可以包括显示屏(Display)、键盘(Keyboard)，可选通信接口403还可以包括标准的有线接口、无线接口。存储器404可以是高速RAM存储器(Ramdom Access Memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器404可选的还可以是至少一个位于远离前述处理器401的存储装置。其中处理器401可以执行实施例1的数据库日志文件处理方法。存储器404中存储一组程序代码，且处理器401调用存储器404中存储的程序代码，以用于执行实施例1的数据库日志文件处理方法。

其中，通信总线402可以是外设部件互连标准(peripheral componentinterconnect，简称PCI)总线或扩展工业标准结构(extended industry standardarchitecture，简称EISA)总线等。通信总线402可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器404可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard diskdrive，缩写：HDD)或固降硬盘(英文：solid-state drive，缩写：SSD)；存储器404还可以包括上述种类的存储器的组合。

其中，处理器401可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。

其中，处理器401还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic arraylogic,缩写：GAL)或其任意组合。

可选地，存储器404还用于存储程序指令。处理器401可以调用程序指令，实现如本申请执行实施例1中的模数据库日志文件处理方法。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机可执行指令，该计算机可执行指令可执行实施例1的数据库日志文件处理方法。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，缩写：HDD)或固降硬盘(Solid-State Drive，SSD)等；存储介质还可以包括上述种类的存储器的组合。

显然，上述实施例仅仅是为清楚地说明所作的举例，而并非对实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。而由此所引申出的显而易见的变化或变动仍处于本发明创造的保护范围之中。

Claims (10)

1.一种数据库日志文件处理方法，其特征在于，包括：

监听第一数据库日志文件的大小，判断所述第一数据库日志文件的大小是否超过第一预设阈值；

在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，对所述第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务，所述预设时间表示允许对数据库日志文件进行切割归档处理的时间，所述定时任务用于定时切割归档数据库日志文件；

判断所述第一数据库日志文件是否满足切割归档条件；

在所述第一数据库日志文件满足切割归档条件的情况下，确定所述第一数据库日志文件的日志类型，并根据所述日志类型对所述第一数据库日志文件进行切割归档处理。

2.根据权利要求1所述的数据库日志文件处理方法，其特征在于，所述根据所述日志类型对所述第一数据库日志文件进行切割归档处理，包括：

确定所述日志类型对应的切割归档函数；

利用所述切割归档函数对所述第一数据库日志文件进行切割归档，输出目标日志文件。

3.根据权利要求2所述的数据库日志文件处理方法，其特征在于，在确定所述日志类型对应的切割归档函数之后，在利用所述切割归档函数对所述第一数据库日志文件进行切割归档之前，还包括：

获取会话级别的日志，判断所述会话级别的日志是否开启；

当所述会话级别的日志开启时，关闭会话级别的日志。

4.根据权利要求2所述的数据库日志文件处理方法，其特征在于，所述利用所述切割归档函数对所述第一数据库日志文件进行切割归档，输出目标日志文件，包括：

生成唯一对应所述第一数据库日志文件的日志名称；

根据所述日志名称建立归档目录；

将日志文件移动到所述归档目录下，对所述第一数据库日志文件进行切割归档，输出目标日志文件。

5.根据权利要求1所述的数据库日志文件处理方法，其特征在于，所述判断所述第一数据库日志文件是否满足切割归档条件，包括：

判断数据库的磁盘剩余空间是否小于第二预设阈值；

在所述数据库的磁盘剩余空间小于所述第二预设阈值的情况下，判定结果为所述第一数据库日志文件满足切割归档条件。

6.根据权利要求1所述的数据库日志文件处理方法，其特征在于，还包括：在所述第一数据库日志文件不满足切割归档条件的情况下，生成所述第一数据库日志文件切割归档失败的标志文件，并发送所述第一数据库日志文件切割归档失败的消息至数据库管理后台。

7.根据权利要求1所述的数据库日志文件处理方法，其特征在于，在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，所述方法还包括：

发送所述第一数据库日志文件已经闭锁的信息至数据库管理后台并建立第二数据库日志文件，所述第二数据库日志文件用于记录在所述第一数据库日志文件闭锁的情况下产生的日志。

8.一种数据库日志文件处理系统，其特征在于，包括，

第一判断模块，用于监听第一数据库日志文件的大小，判断所述第一数据库日志文件的大小是否超过第一预设阈值；

定时任务启动模块，用于在所述第一数据库日志文件的大小超过所述第一预设阈值的情况下，对所述第一数据库日志文件进行闭锁，并在预设时间启动预先配置的定时任务；

第二判断模块，用于判断所述第一数据库日志文件是否满足切割归档条件；

切割归档模块，用于在所述第一数据库日志文件满足切割归档条件的情况下，确定所述第一数据库日志文件的日志类型，并根据所述日志类型对所述第一数据库日志文件进行切割归档处理。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储计算机指令，所述计算机指令被处理器执行时实现如权利要求1-7中任一项所述的数据库日志文件处理方法。

10.一种电子设备，其特征在于，包括：

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行如权利要求1-7中任一项所述的数据库日志文件处理方法。

Images