CN113377502A - 事务处理方法、装置、服务器、数据库管理***及介质 - Google Patents
事务处理方法、装置、服务器、数据库管理***及介质 Download PDFInfo
- Publication number
- CN113377502A CN113377502A CN202110648078.4A CN202110648078A CN113377502A CN 113377502 A CN113377502 A CN 113377502A CN 202110648078 A CN202110648078 A CN 202110648078A CN 113377502 A CN113377502 A CN 113377502A
- Authority
- CN
- China
- Prior art keywords
- transaction
- server node
- target
- data
- serial number
- 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.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 26
- 238000012545 processing Methods 0.000 claims abstract description 88
- 238000000034 method Methods 0.000 claims abstract description 31
- 238000011010 flushing procedure Methods 0.000 claims description 39
- 238000004590 computer program Methods 0.000 claims description 6
- 230000004048 modification Effects 0.000 abstract description 27
- 238000012986 modification Methods 0.000 abstract description 27
- 238000007726 management method Methods 0.000 description 17
- 230000007246 mechanism Effects 0.000 description 14
- 230000008569 process Effects 0.000 description 12
- 230000001680 brushing effect Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 101100153085 Dictyostelium discoideum trxA gene Proteins 0.000 description 4
- 101150102071 TRX1 gene Proteins 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 230000008707 rearrangement Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000002618 waking effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种事务处理方法、装置、服务器、数据库管理***及介质。该方法包括：接收SQL请求，SQL请求用于请求对目标事务的数据进行指定处理；若目标服务器节点非当前服务器节点，则提取目标服务器节点的提交日志序列号和刷盘日志序列号，目标服务器节点为在接收到SQL请求之前最后修改目标事务数据的事务所在的服务器节点；根据提交日志序列号、刷盘日志序列号以及SQL请求对目标事务数据进行指定处理。上述技术方案针对其他服务器节点对目标事务的修改，根据提交日志序列号和刷盘日志序列号，在处理事务前明确提交日志序列号对应的日志是否完成刷盘，从而保证数据的正确性，提高事务处理的可靠性。
Description
技术领域
本发明实施例涉及数据库技术领域，尤其涉及一种事务处理方法、装置、服务器、数据库管理***及介质。
背景技术
数据库管理***(Database Management System，DBMS)通常利用重做(Redo)日志来保证事务的持久性(Durability)，用户发起事务提交(Commit)请求时，数据库服务器修改事务状态的操作会产生一条Redo日志，将Redo日志写入磁盘的联机日志文件(即刷盘)后，数据库服务器响应用户，事务提交完成。事务提交完成后，如果数据库服务器发生异常重启，根据Redo日志可以将数据恢复到故障前的状态，维持该事务的数据修改有效。
目前，一种优化的事务处理机制无需等待日志刷盘完成即可提前响应用户，以减少Redo日志刷盘冲突和刷盘等待时间，这种机制称为Commit nowait。对于还未刷盘的Redo日志，如果发生异常重启，数据库服务器会忽略这些Redo日志对应的修改，将数据回滚到修改前的状态，通过允许这些数据修改的丢失，以换取更好的***性能。
然而，在数据库管理***包含多个数据库服务器的情况下，允许多个数据库服务器访问或者修改同一事务的数据，这种情况下，如果发生异常重启，这些数据会按照完成刷盘的Redo日志恢复，可能会由于Redo日志未刷盘而回滚，从而会引发数据错误，影响事务的正确处理。
发明内容
本发明提供了一种事务处理方法、装置、服务器、数据库管理***及介质及***，以保证事务数据的正确性，提高事务处理的可靠性。
第一方面，本发明实施例提供了一种事务处理方法，包括：
接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号小于或等于所述刷盘日志序列号，则按照所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号大于所述刷盘日志序列号，则向所述目标服务器节点发送刷盘请求；
在所述目标服务器节点完成刷盘后，按照所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，在接收SQL请求之后，还包括：
若所述目标服务器节点为当前服务器节点，则按照所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，在接收SQL请求之前，还包括：
在启动所述目标事务时，记录集群中每个服务器节点的提交日志序列号和刷盘日志序列号；
在启动所述目标事务之后，实时更新每个服务器节点的刷盘日志序列号。
进一步的，在接收SQL请求之后，还包括：
读取在接收到所述SQL请求之前最后修改所述目标事务的数据的事务的事务号；
根据所述事务号对集群中服务器节点总数取余的余数，确定所述目标服务器节点
第二方面，本发明实施例提供了一种事务处理装置，包括：
接收模块，用于接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
提取模块，用于若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
处理模块，用于根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
第三方面，本发明实施例提供了一种数据库服务器，包括：
一个或多个处理器；
存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的事务处理方法。
第四方面，本发明实施例提供了一种***，包括：
多个数据库服务器，每个数据库服务器为一个服务器节点；
其中，至少一个服务器节点用于：
接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
第五方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面所述的事务处理方法。
本发明实施例提供了一种事务处理方法、装置、服务器、数据库管理***及介质。该方法包括：接收SQL请求，SQL请求用于请求对目标事务的数据进行指定处理；若目标服务器节点非当前服务器节点，则提取目标服务器节点的提交日志序列号和刷盘日志序列号，其中，目标服务器节点为在接收到SQL请求之前最后修改目标事务数据的事务所在的服务器节点；根据提交日志序列号、刷盘日志序列号以及SQL请求对目标事务数据进行指定处理。上述技术方案针对其他服务器节点对目标事务的修改，根据提交日志序列号和刷盘日志序列号，在处理事务前明确提交日志序列号对应的日志是否完成刷盘，从而保证数据的正确性，提高事务处理的可靠性。
附图说明
图1为本发明实施例一提供的一种事务处理方法的流程图；
图2为本发明实施例二提供的一种事务处理方法的流程图；
图3为本发明实施例三提供的一种事务处理装置的结构示意图；
图4为本发明实施例四提供的一种数据库服务器的硬件结构示意图；
图5为本发明实施例五提供的一种数据库管理***的结果示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。此外，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其处理完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
为了更好地理解本发明实施例，下面对相关技术进行介绍。
利用Redo日志可以保证事务的持久性。具体的，数据库服务器收到用户发起事务提交请求时，将事务修改为已提交(Committed)状态，修改事务状态的操作会产生一条Redo日志，并启动日志刷盘操作，将Redo日志写入磁盘的联机日志文件，然后再响应用户，事务提交完成。事务提交完成后，如果数据库服务器发生异常重启，则根据Redo日志可以将数据恢复到故障前的状态，确保该事务状态仍为Committed，并维持对该事务的数据修改有效。这种机制意味着每个事务的提交都会触发Redo日志刷盘操作，频繁的Redo日志刷盘请求和刷盘等待，在很大程度上会影响数据库管理***的整体性能。
Commit nowait机制的实现原理是：事务提交时允许指定nowait选项，即，在事务产生的Redo日志写入磁盘之前，提前响应用户，目的是减少Redo日志刷盘冲突和刷盘等待。但是由于这些Redo日志还未刷盘，如果发生异常重启，数据库服务器会忽略这些Redo日志对应的修改，将数据回滚到修改前的状态，通过允许这些数据修改的丢失，以换取更好的***性能。
在数据库管理***包含多个数据库服务器的情况下，允许多个数据库服务器访问或者修改同一事务的数据，这种情况下，Commit nowait机制会引发数据错误，影响事务的正确处理。例如：
Create table t1(c1 int)；
Create table t2(c1 int)；
Insert into t1 values(1)；
Insert into t2 values(1)；
Commit；
执行上述语句后，数据库中存在t1和t2两张表，且t1和t2中各有一条数据，其值为1。
然后，0号节点(记为EP[0])的事务(记为trx0，0为事务的事务号或ID号)执行以下处理：
update t1 set c1＝11； --修改表t1的数据为11，且修改操作的Redo日志刷盘完成
Commit； --修改事务状态为Committed的Redo日志未刷盘
此外，1号节点(记为EP[1])的事务(记为trx1，1为事务的事务号或ID号)执行以下处理：
update t1 set c1＝22； --修改表t1的数据为22
update t2 set c1＝22； --修改表t2的数据为22
Commit； --上述两条修改数据的操作和修改事务状态为Committed的Redo日志都完成刷盘
这种情况下，如果***发生异常重启，则数据库服务器会先重做已经完成刷盘Redo日志，再将没有提交的事务的数据回滚。具体的，EP[1]修改trx1的事务状态的Redo日志已经完成刷盘，trx1提交完成，因此数据修改有效，在重启时即t1和t2的数据都恢复为22；但是，由于EP[0]修改trx0的事务状态的Redo日志未刷盘，trx0仍然处于活动状态，重启后trx0事务的数据回滚，t1表的数据重新修改为1。可见，由于EP[1]的trx1事务对t1表的修改丢失、对t2表修改的数据保持，引发了数据错误。
本实施例所提供的方法，目的是提供一种事务处理方法，能够在保证***高性能(即Commit nowait机制)的前提下，针对其他数据库服务器修改了目标事务的数据的情况，通过分析被记录的最后一次已提交的修改数据的Redo日志(即提交日志序列号对应的日志)是否完成刷盘，判断数据是否正确、是否能够直接按照SQL请求处理目标事务的数据，从而保证数据的正确性，提高事务处理的可靠性。
实施例一
图1为本发明实施例一提供的一种事务处理方法的流程图，本实施例可适用于在数据库管理***中对目标事务的数据进行访问、修改、增删等处理的情况。具体的，该事务处理方法可以由事务处理装置执行，该事务处理装置可以通过软件和/或硬件的方式实现，并集成在数据库服务器中。需要说明的是，数据库管理***中可以包括多个数据库服务器，每个数据库服务器为一个服务器节点，***采用Commit nowait机制，即，每个数据库服务器可以先响应用户、再将修改事务状态对应的Redo日志刷盘。当一个数据库服务器(即当前数据库服务器或当前服务器节点)接收到用户发起的SQL请求时，可以执行本实施例的方法。
如图1所示，该方法具体包括如下步骤：
S110、接收SQL请求，SQL请求用于请求对目标事务的数据进行指定处理。
具体的，SQL请求指用户发起的、由当前服务器节点对目标事务的数据进行处理的请求，其中，处理可以指对目标事务的数据的访问、增删、修改和查询等。
S120、若目标服务器节点非当前服务器节点，则提取目标服务器节点的提交日志序列号和刷盘日志序列号。
具体的，目标服务器节点为在接收到SQL请求之前，最后修改目标事务的数据的事务所在的服务器节点。目标服务器节点可能是当前服务器节点，也可能是集群中的其他服务器节点。如果目标服务器节点是当前服务器节点，即在接收到SQL请求之前最后修改数据的服务器节点，与即将对目标事务的数据进行处理的当前服务器节点为同一服务器节点，这种情况下不需要考虑集群中其他服务器节点对目标事务的数据的修改，如果***故障重启，则在Commit nowait机制下，当前服务器节点忽略未刷盘的Redo日志对应的修改、按照已完成刷盘的Redo日志恢复数据即可，不会引起数据错误。
如果目标服务器节点非当前服务器节点，即在当前服务器节点接收到SQL请求之前，有其他服务器节点对目标事务的数据进行了修改，若发生故障重启，当前服务器节点按照已完成刷盘的Redo日志恢复数据之后，由于其他服务器节点对应的Redo日志可能未刷盘，造成相应数据回滚，修改了按照已完成刷盘的Redo日志恢复的数据，引起数据错误。本实施例中，通过分析目标服务器节点的提交日志序列号和刷盘日志序列号，来确定在接收到SQL请求之前目标服务器节点最后修改数据的Redo日志是否完成刷盘，在此基础上，可以及时将未刷盘的Redo日志写入磁盘以避免数据回滚，然后再处理目标事务的数据。
日志序列号(Log Sequence Number，LSN)是数据库管理***内部维护的一个递增数值，用于标识Redo日志。本实施例中，每个数据库服务器有两种日志序列号，分别是提交日志序列号(记为Commit_LSN)和刷盘日志序列号(记为File_LSN)，其中，Commit_LSN是在目标事务启动时记录的、目标服务器节点在其事务提交时修改事务状态为Committed所产生的Redo日志的LSN；File_LSN是写入磁盘的Redo日志的最大LSN，在目标事务启动时记录，并且目标事务启动后更新，每有一批Redo日志完成刷盘，File_LSN增加相应的数值。在接收到SQL请求之前，目标服务器节点最后修改了目标事务的数据，则当前服务器节点在接收到SQL请求时，可以根据其目标事务所记录的目标服务器节点的Commit_LSN以及当前最新的File_LSN，确定目标服务器节点在目标事务启动时产生的Redo日志是否完成刷盘。
可选的，集群中各服务器节点间实时交互Commit_LSN和File_LSN，以便在某个服务器节点接收到SQL请求时，可以获取到目标服务器节点对应的Commit_LSN和File_LSN。
S130、根据提交日志序列号、刷盘日志序列号以及SQL请求对目标事务数据进行指定处理。
具体的，当前服务器节点根据其目标事务所记录的目标服务器节点的Commit_LSN以及最新的File_LSN，确定目标服务器节点在目标事务启动时产生的Redo日志是否已完成刷盘，据此按照SQL请求对目标事务数据进行指定处理。
例如，Commit_LSN＝10，File_LSN＝12，即目标服务器节点在目标事务启动时最近的提交操作对应的的Redo日志的日志序列号为10，而已经完成刷盘的Redo日志的日志序列号达到12，说明日志序列号为10的Redo日志已经完成刷盘，此时目标事务的数据是正确的，即便发生异常重启也不会丢失，此时按照SQL请求对目标事务数据进行指定处理即可。又如，Commit_LSN＝10，File_LSN＝8，即已经完成刷盘的Redo日志的日志序列号仅到8，说明日志序列号为10的Redo日志未刷盘，一旦发生异常重启，日志序列号为10的Redo日志对应的数据修改会丢失，数据会回滚到修改前的状态，引发数据错误，这种情况下需要等待目标服务器节点完成Redo日志的刷盘后再按照SQL请求对目标事务数据进行指定处理。
本发明实施例一提供的一种事务处理方法，通过引入Commit_LSN和File_LSN，确定目标服务器节点在目标事务启动时已提交操作对应的Redo日志是否完成刷盘，从而避免其他服务器节点对目标事务数据的修改丢失，在确保数据正确性的基础上再处理目标事务的数据，在共享存储集群数据库管理***的Commit nowait机制下，实现对目标事务高效、可靠地处理。
实施例二
图2为本发明实施例二提供的一种事务处理方法的流程图，本实施例是在上述实施例的基础上进行优化，对序列号提取过程、根据事务号确定目标服务器节点的过程以及是否需要等待刷盘的过程进行具体描述。需要说明的是，未在本实施例中详尽描述的技术细节可参见上述任意实施例。
具体的，如图2所示，该方法具体包括如下步骤：
S210、在启动目标事务时，记录集群中每个服务器节点的提交日志序列号和刷盘日志序列号。
具体的，启动目标事务是指启动对目标事务的数据的具体操作，例如增删、查询、修改等，此时，当前服务器节点(可能是集群中的任意一个服务器节点)为目标事务记录其他每个服务器节点的Commit_LSN和File_LSN。
可以理解的是，集群中的每个服务器节点在修改事务状态为Committed并产生Redo日志时都生成对应的Commit_LSN，并广播给共享存储数据库集群中的其他服务器节点；在每次Redo日志完成刷盘后，广播File_LSN给其他服务器节点。具体的，集群中的每个服务器节点在Commit nowait机制下可执行以下操作：
接收用户的事务Commit请求；
修改事务状态为Committed；
生成修改事务状态的Redo日志，登记Commit_LSN；
释放事务的封锁资源，唤醒等待的事务
触发Commit_LSN信息的广播流程，向其他服务器节点发送Commit_LSN，向各服务器节点广播可由异步的线程执行)；
事务提交完成，响应用户。
S220、在启动目标事务之后，实时更新每个服务器节点的刷盘日志序列号。
具体的，启动目标事务之后，目标事务记录的其他服务器节点的Commit_LSN值不会改变，但当前服务器节点会根据接收到的其他服务器节点广播的File_LSN更新目标事务记录的对应File_LSN。
S230、接收SQL请求。
S240、读取在接收到SQL请求之前最后修改目标事务的数据的事务的事务号。
本实施例中，利用事务号确定目标服务器节点。***中每一个事务都对应于一个事务号(trxID)，每一条数据都包含trxID字段，用于标识最后修改此条数据的事务号。
需要说明的是，在读取事务号的过程中，需要对***中的各事务进行可见性分析，即分析各事务对当前服务器节点来说是否可见，可见性决定了一个事务对目标事务的数据的修改是否有效。示例性的，一个历史事务为在数据页中删除数据A，目标事务为查询该数据页中的所有数据，如果该历史事务为可见的，则目标事务的查询结果中不包括数据A；如果该历史事务为不可见的，则目标事务的查询结果中包括数据A。通过判断各事务的可见性，能够保证数据的一致性。
本实施例中，在接收到SQL请求之前最后修改目标事务的数据的事务是可见的事务。具体的，如果一个事务的事务号与目标事务的事务号相同，或者，一个事务的事务号小于目标事务的事务号且不属于活动事务，则该事务对于当前服务器节点为可见的，该事务对目标事务的数据的修改是有效的，需要保证该事务对应的Redo日志完成刷盘后才能根据SQL请求处理目标事务的数据。如果一个事务的事务号大于目标事务的事务号或者属于活动事务，则该事务对于当前服务器节点为不可见的，该事务对目标事务的数据的修改是在启动目标事务并记录Commit_LSN之后发生的，因此是无效的，可以忽略。
S250、根据事务号对集群中服务器节点总数取余的余数，确定目标服务器节点。
具体的，根据读取的trxID字段确定在接收到SQL请求之前最后修改数据的事务所在的目标服务器节点。本实施例中，用读取的事务号对集群中服务器节点总数取余，余数记为服务器节点的节点号。例如读取的事务号为4，节点总数为3，当前服务器节点的节点号为1，则目标服务器节点为当前服务器节点。在此基础上，可以确保不同服务器节点分配的事务号不会冲突，且通过建立节点号与事务号的映射关系，便于快速确定目标服务器节点。
S260、目标服务器节点为当前服务器节点？若是，则执行S280；否则，执行S270。
具体的，如果目标服务器节点为当前服务器节点，这种情况下不需要考虑集群中其他服务器节点对目标事务的数据的修改，如果***发生异常重启，则在Commit nowait机制下，忽略未刷盘的Redo日志的修改、按照已完成刷盘的Redo日志恢复数据即可，并不会引起数据错误；如果目标服务器节点非当前服务器节点，即在当前服务器节点接收到SQL请求之前，有其他服务器节点对目标事务的数据进行了修改，则通过分析目标事务记录的目标服务器节点的Commit_LSN和File_LSN，可以明确Commit_LSN对应的Redo日志是否完成刷盘，进而决定是否需要等待刷盘。
S270、提交日志序列号≤刷盘日志序列号？若是，则执行S280；否则，执行S290。
具体的，由于Commit_LSN在目标事务处理开始之前收集，在访问到其他服务器节点上事务的修改记录时，如果Commit_LSN≤File_LSN，说明Commit_LSN对应的Redo日志已完成刷盘，目标服务器节点的事务对数据的修改已经保存，则按照SQL请求对目标事务的数据进行指定处理即可。这种异步的服务器节点间Redo日志刷盘等待机制，可以提升共享存储集群Commit nowait机制的执行效率。
S280、按照SQL请求对目标事务的数据进行指定处理。
S290、向目标服务器节点发送刷盘请求，并在目标服务器节点完成刷盘后，按照SQL请求对目标事务的数据进行指定处理。
具体的，如果Commit_LSN＞File_LSN，说明Commit_LSN对应的Redo日志未刷盘，故障重启时数据会回滚，目标服务器节点的事务对数据的修改丢失，这种情况下需要向目标服务器节点发送刷盘请求，等待Commit_LSN对应的Redo日志完成刷盘后，再按照SQL请求对目标事务的数据进行指定处理，执行完成后可以响应用户，目标事务完成。
本发明实施例二提供的一种事务处理方法，在上述实施例的基础上进行优化，各服务器节点通过广播和记录Commit_LSN和File_LSN，为判断是否需要等待Redo日志刷盘提供依据；通过判断各事务的可见性，确保其他服务器节点对目标事务的数据的修改有效，数据可以正确恢复，保证数据的一致性；通过建立节点号与事务号的映射关系，将读取的事务号对节点总数取余，可高效地确定目标服务器节点，确保不同服务器节点分配的事务号不会冲突；通过异步的服务器节点间Redo日志刷盘等待机制，可提升共享存储集群Commitnowait机制的执行效率；最终根据Commit_LSN和File_LSN，保证Commit_LSN对应的日志完成刷盘，从而提高事务处理的可靠性
实施例三
图3为本发明实施例三提供的一种事务处理装置的结构示意图。本实施例提供的事务处理装置包括：
接收模块310，用于接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
提取模块320，用于若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
处理模块330，用于根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
本发明实施例三提供的一种事务处理装置，对于其他服务器节点对目标事务的修改，可根据提交日志序列号和刷盘日志序列号明确目标服务器节点的日志提交进度和刷盘进度，据此在处理事务前明确提交日志序列号对应的日志是否完成刷盘，从而保证事务数据的正确性，提高事务处理的可靠性。
在上述实施例的基础上，处理模块330，包括：
第一处理单元，用于若所述提交日志序列号小于或等于所述刷盘日志序列号，则按照所述SQL请求对所述目标事务的数据进行指定处理。
在上述实施例的基础上，处理模块330，包括：
请求单元，用于若所述提交日志序列号大于所述刷盘日志序列号，则向所述目标服务器节点发送刷盘请求；
第二处理单元，用于在所述目标服务器节点完成刷盘后，按照所述SQL请求对所述目标事务的数据进行指定处理。
在上述实施例的基础上，该装置还包括：
第三处理单元，用于在接收SQL请求之后，若所述目标服务器节点为当前服务器节点，则按照所述SQL请求对所述目标事务的数据进行指定处理。
在上述实施例的基础上，该装置还包括：
记录模块，用于在接收SQL请求之前，在启动所述目标事务时，记录集群中每个服务器节点的提交日志序列号和刷盘日志序列号；
更新模块，用于在启动所述目标事务之后，实时更新每个服务器节点的刷盘日志序列号。
在上述实施例的基础上，该装置还包括：
读取模块，用于在接收SQL请求之后，读取在接收到所述SQL请求之前最后修改所述目标事务的数据的事务的事务号；
取余模块，用于根据所述事务号对集群中服务器节点总数取余的余数，确定所述目标服务器节点。
本发明实施例三提供的事务处理装置可以用于执行上述任意实施例提供的事务处理方法，具备相应的功能和有益效果。
实施例四
图4为本发明实施例四提供的一种数据库服务器的硬件结构示意图。如图4所示，本申请提供的数据库服务器，包括存储器42、处理器41以及存储在存储器上并可在处理器上运行的计算机程序，处理器41执行所述程序时实现上述的事务处理方法。
数据库服务器还可以包括存储器42；该数据库服务器中的处理器41可以是一个或多个，图4中以一个处理器41为例；存储器42用于存储一个或多个程序；所述一个或多个程序被所述一个或多个处理器41执行，使得所述一个或多个处理器41实现如本申请实施例中所述的事务处理方法。
数据库服务器还包括：通信装置43、输入装置44和输出装置45。
数据库服务器中的处理器41、存储器42、通信装置43、输入装置44和输出装置45可以通过总线或其他方式连接，图4中以通过总线连接为例。
输入装置44可用于接收输入的数字或字符信息，以及产生与数据库服务器的用户设置以及功能控制有关的按键信号输入。输出装置45可包括显示屏等显示设备。
通信装置43可以包括接收器和发送器。通信装置43设置为根据处理器41的控制进行信息收发通信。
存储器42作为一种计算机可读存储介质，可设置为存储软件程序、计算机可执行程序以及模块，如本申请实施例所述事务处理方法对应的程序指令/模块(例如，事务处理装置中的接收模块310、提取模块320和处理模块330)。存储器42可包括存储程序区和存储数据区，其中，存储程序区可存储处理***、至少一个功能所需的应用程序；存储数据区可存储根据数据库服务器的使用所创建的数据等。此外，存储器42可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器42可进一步包括相对于处理器41远程设置的存储器，这些远程存储器可以通过网络连接至数据库服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
实施例五
本发明实施例五提供一种数据库管理***。图5为本发明实施例五提供的一种数据库管理***示意图。如图5所示，该***包括：多个数据库服务器(例如数据库服务器511和数据库服务器512)，每个数据库服务器为一个服务器节点；其中，至少一个服务器节点用于：接收SQL请求，SQL请求用于请求对目标事务的数据进行指定处理；若目标服务器节点非当前服务器节点，则提取目标服务器节点的提交日志序列号和刷盘日志序列号，其中，目标服务器节点为在接收到SQL请求之前最后修改目标事务的数据的事务所在的服务器节点；根据提交日志序列号、刷盘日志序列号以及SQL请求对目标事务的数据进行指定处理。
本发明实施例五提供的一种数据库管理***，对于其他服务器节点对目标事务的修改，当前服务器节点可根据提交日志序列号和刷盘日志序列号明确目标服务器节点的日志提交进度和刷盘进度，据此在处理事务前明确其他服务器节点的日志是否都完成刷盘，从而保证事务数据的正确性，提高事务处理的可靠性。
进一步的，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号小于或等于所述刷盘日志序列号，则按照所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号大于所述刷盘日志序列号，则向所述目标服务器节点发送刷盘请求；
在所述目标服务器节点完成刷盘后，按照所述SQL请求对所述目标事务的数据进行指定处理。
进一步的，在接收SQL请求之后，上述的至少一个服务器节点还用于：
若所述目标服务器节点为当前服务器节点，则按照所述SQL请求对所述目标事务的数据进行指定处理。
例如，数据库服务器511为目标事务所在的当前服务器节点，在数据库服务器511接收到SQL请求之前最后修改目标事务的数据的事务所在的目标服务器节点可能是数据库服务器511，也可能是数据库服务器512。如果是数据库服务器511，则无需等待刷盘，按照SQL请求对目标事务的数据进行相应处理即可；如果是数据库服务器512，则需要根据数据库服务器512的Commit_LSN和File_LSN决定是否需要等待刷盘，在此基础上再按照SQL请求对目标事务的数据进行相应处理。
具体的，如果数据库服务器512对应的Commit_LSN≤File_LSN，则无需等待刷盘，按照SQL请求对目标事务的数据进行相应处理即可；如果Commit_LSN＞File_LSN，则需要等待数据库服务器512的日志完成刷盘之后再按照SQL请求对目标事务的数据进行相应处理。
进一步的，在接收SQL请求之前，上述的至少一个服务器节点还用于：
在启动所述目标事务时，记录集群中每个服务器节点的提交日志序列号和刷盘日志序列号；
在启动所述目标事务之后，实时更新每个服务器节点的刷盘日志序列号。
进一步的，在接收SQL请求之后，上述的至少一个服务器节点还用于：
读取在接收到所述SQL请求之前最后修改所述目标事务的数据的事务的事务号；
根据所述事务号对集群中服务器节点总数取余的余数，确定所述目标服务器节点。
本实施例五提供的一种数据库管理***可以用于实现上述任意实施例提供的事务处理方法，具备相应的功能和有益效果。
在上述实施例的基础上，本实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被事务处理装置执行时实现本发明上述任意实施例中的事务处理方法，该方法包括：接收SQL请求，SQL请求用于请求对目标事务的数据进行指定处理；若目标服务器节点非当前服务器节点，则提取目标服务器节点的提交日志序列号和刷盘日志序列号，其中，目标服务器节点为在接收到SQL请求之前最后修改目标事务数据的事务所在的服务器节点；根据提交日志序列号、刷盘日志序列号以及SQL请求对目标事务数据进行指定处理。
本发明实施例所提供的一种包含计算机可执行指令的存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是，但不限于：电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式CD-ROM、光存储器件、磁存储器件、或者上述的任意合适的组合。计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于：电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、无线电频率(Radio Frequency，RF)等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请处理的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的事务处理方法。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。
Claims (10)
1.一种事务处理方法，其特征在于，包括：
接收结构化查询语言SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
2.根据权利要求1所述的方法，其特征在于，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号小于或等于所述刷盘日志序列号，则按照所述SQL请求对所述目标事务的数据进行指定处理。
3.根据权利要求1所述的方法，其特征在于，根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理，包括：
若所述提交日志序列号大于所述刷盘日志序列号，则向所述目标服务器节点发送刷盘请求；
在所述目标服务器节点完成刷盘后，按照所述SQL请求对所述目标事务的数据进行指定处理。
4.根据权利要求1所述的方法，其特征在于，在接收SQL请求之后，还包括：
若所述目标服务器节点为当前服务器节点，则按照所述SQL请求对所述目标事务的数据进行指定处理。
5.根据权利要求1所述的方法，其特征在于，在接收SQL请求之前，还包括：
在启动所述目标事务时，记录集群中每个服务器节点的提交日志序列号和刷盘日志序列号；
在启动所述目标事务之后，实时更新每个服务器节点的刷盘日志序列号。
6.根据权利要求1所述的方法，其特征在于，在接收SQL请求之后，还包括：
读取在接收到所述SQL请求之前最后修改所述目标事务的数据的事务的事务号；
根据所述事务号对集群中服务器节点总数取余的余数，确定所述目标服务器节点。
7.一种事务处理装置，其特征在于，包括：
接收模块，用于接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
提取模块，用于若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
处理模块，用于根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
8.一种数据库服务器，其特征在于，包括：
一个或多个处理器；
存储器，用于存储一个或多个程序；
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-6中任一所述的事务处理方法。
9.一种数据库管理***，其特征在于，包括多个数据库服务器，每个数据库服务器为一个服务器节点；
其中，至少一个服务器节点用于：
接收SQL请求，所述SQL请求用于请求对目标事务的数据进行指定处理；
若目标服务器节点非当前服务器节点，则提取所述目标服务器节点的提交日志序列号和刷盘日志序列号，其中，所述目标服务器节点为在接收到所述SQL请求之前最后修改所述目标事务的数据的事务所在的服务器节点；
根据所述提交日志序列号、所述刷盘日志序列号以及所述SQL请求对所述目标事务的数据进行指定处理。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-6中任一所述的事务处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110648078.4A CN113377502A (zh) | 2021-06-10 | 2021-06-10 | 事务处理方法、装置、服务器、数据库管理***及介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110648078.4A CN113377502A (zh) | 2021-06-10 | 2021-06-10 | 事务处理方法、装置、服务器、数据库管理***及介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113377502A true CN113377502A (zh) | 2021-09-10 |
Family
ID=77573608
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110648078.4A Pending CN113377502A (zh) | 2021-06-10 | 2021-06-10 | 事务处理方法、装置、服务器、数据库管理***及介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113377502A (zh) |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100502501B1 (ko) * | 2004-08-05 | 2005-07-20 | 주식회사 알티베이스 | 데이터베이스 시스템의 실시간 원격 로깅 및 복구 방법 |
| US20070143299A1 (en) * | 2005-12-19 | 2007-06-21 | Huras Matthew A | Commitment of transactions in a distributed system |
| CN103678608A (zh) * | 2013-12-16 | 2014-03-26 | 华为技术有限公司 | 日志管理方法和装置 |
| CN107025242A (zh) * | 2016-02-02 | 2017-08-08 | 南京中兴新软件有限责任公司 | 数据库间数据的复制方法及装置 |
| US20170300552A1 (en) * | 2016-04-18 | 2017-10-19 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
| CN109657007A (zh) * | 2018-12-17 | 2019-04-19 | 武汉达梦数据库有限公司 | 基于异步提交的数据库数据同步并行执行方法及设备 |
| US20190129894A1 (en) * | 2016-06-30 | 2019-05-02 | Huawei Technologies Co., Ltd. | Database Transaction Processing Method, Client, and Server |
| CN109828720A (zh) * | 2019-01-21 | 2019-05-31 | 上海达梦数据库有限公司 | 数据存储方法、装置、服务器和存储介质 |
| CN110196759A (zh) * | 2018-06-20 | 2019-09-03 | 腾讯科技（深圳）有限公司 | 分布式事务处理方法和装置、存储介质及电子装置 |
| CN111240810A (zh) * | 2020-01-20 | 2020-06-05 | 上海达梦数据库有限公司 | 一种事务管理方法、装置、设备和存储介质 |
| CN111444147A (zh) * | 2020-03-30 | 2020-07-24 | 上海达梦数据库有限公司 | 一种数据页创建方法、装置、终端设备及存储介质 |
| CN112015713A (zh) * | 2019-05-30 | 2020-12-01 | 阿里巴巴集团控股有限公司 | 数据库任务的处理方法、装置、电子设备及可读介质 |
-
2021
- 2021-06-10 CN CN202110648078.4A patent/CN113377502A/zh active Pending
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100502501B1 (ko) * | 2004-08-05 | 2005-07-20 | 주식회사 알티베이스 | 데이터베이스 시스템의 실시간 원격 로깅 및 복구 방법 |
| US20070143299A1 (en) * | 2005-12-19 | 2007-06-21 | Huras Matthew A | Commitment of transactions in a distributed system |
| CN103678608A (zh) * | 2013-12-16 | 2014-03-26 | 华为技术有限公司 | 日志管理方法和装置 |
| CN107025242A (zh) * | 2016-02-02 | 2017-08-08 | 南京中兴新软件有限责任公司 | 数据库间数据的复制方法及装置 |
| US20170300552A1 (en) * | 2016-04-18 | 2017-10-19 | Amazon Technologies, Inc. | Versioned hierarchical data structures in a distributed data store |
| US20190129894A1 (en) * | 2016-06-30 | 2019-05-02 | Huawei Technologies Co., Ltd. | Database Transaction Processing Method, Client, and Server |
| CN110196759A (zh) * | 2018-06-20 | 2019-09-03 | 腾讯科技（深圳）有限公司 | 分布式事务处理方法和装置、存储介质及电子装置 |
| CN109657007A (zh) * | 2018-12-17 | 2019-04-19 | 武汉达梦数据库有限公司 | 基于异步提交的数据库数据同步并行执行方法及设备 |
| CN109828720A (zh) * | 2019-01-21 | 2019-05-31 | 上海达梦数据库有限公司 | 数据存储方法、装置、服务器和存储介质 |
| CN112015713A (zh) * | 2019-05-30 | 2020-12-01 | 阿里巴巴集团控股有限公司 | 数据库任务的处理方法、装置、电子设备及可读介质 |
| CN111240810A (zh) * | 2020-01-20 | 2020-06-05 | 上海达梦数据库有限公司 | 一种事务管理方法、装置、设备和存储介质 |
| CN111444147A (zh) * | 2020-03-30 | 2020-07-24 | 上海达梦数据库有限公司 | 一种数据页创建方法、装置、终端设备及存储介质 |
Non-Patent Citations (2)
| Title |
|---|
| 王嘉豪;蔡鹏;钱卫宁;周傲英;: "集群数据库***的日志复制和故障恢复", 软件学报, no. 03 * |
| 飞鸡壳壳: "mysql日志刷新到磁盘_MySQL数据库刷日志的方法", Retrieved from the Internet <URL:https://www.blog.csdn.net/weixin_30580403/article/113555748> * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10691722B2 (en) | Consistent query execution for big data analytics in a hybrid database | |
| EP3295332B1 (en) | Direct-connect functionality in a distributed database grid | |
| US9348641B2 (en) | System and method for performing a transaction in a massively parallel processing database | |
| CN109684307B (zh) | 一种数据存储方法、装置、设备及存储介质 | |
| CN108363806B (zh) | 数据库的多版本并发控制方法、装置、服务器及存储介质 | |
| US20190012343A1 (en) | Transaction execution commitment without updating of data row transaction status | |
| CN110196856B (zh) | 一种分布式数据读取方法及装置 | |
| EP1402414B1 (en) | Consistent read in a distributed database environment | |
| CN111259083A (zh) | 分布式事务处理方法及装置 | |
| CN110188114B (zh) | 一种数据操作的优化方法、装置、***、设备和存储介质 | |
| CN111444147B (zh) | 一种数据页创建方法、装置、终端设备及存储介质 | |
| CN111190935B (zh) | 数据读取方法、装置、计算机设备及存储介质 | |
| CN106354732B (zh) | 一种支持并发协同的离线数据版本冲突解决方法 | |
| CN111522631A (zh) | 分布式事务处理方法、装置、服务器及介质 | |
| CN110413687B (zh) | 基于节点互证校验的分布式事务故障处理方法及相关设备 | |
| CN108090056B (zh) | 数据查询方法、装置及*** | |
| CN111475480A (zh) | 一种日志处理方法及*** | |
| CN112800060A (zh) | 数据处理方法、装置、计算机可读存储介质及电子设备 | |
| CN113377502A (zh) | 事务处理方法、装置、服务器、数据库管理***及介质 | |
| CN111240810B (zh) | 一种事务管理方法、装置、设备和存储介质 | |
| WO2023111910A1 (en) | Rolling back database transaction | |
| CN115421880A (zh) | 事务处理方法、装置、设备及介质 | |
| CN112612647B (zh) | 日志并行重演方法、装置、设备及存储介质 | |
| CN114036195A (zh) | 一种数据请求处理方法、装置、服务器和存储介质 | |
| CN112925807A (zh) | 面向数据库的请求的批处理方法、装置、设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |