WO2004055674A1 - Dispositif, programme, procede et systeme repartis de transactions - Google Patents

Dispositif, programme, procede et systeme repartis de transactions Download PDF

Info

Publication number
WO2004055674A1
WO2004055674A1 PCT/JP2002/013250 JP0213250W WO2004055674A1 WO 2004055674 A1 WO2004055674 A1 WO 2004055674A1 JP 0213250 W JP0213250 W JP 0213250W WO 2004055674 A1 WO2004055674 A1 WO 2004055674A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
distributed
processing
transaction processing
local
Prior art date
Application number
PCT/JP2002/013250
Other languages
English (en)
Japanese (ja)
Inventor
Yoshitake Shinkai
Original Assignee
Fujitsu Limited
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2002/013250 priority Critical patent/WO2004055674A1/fr
Priority to JP2004560585A priority patent/JP4286786B2/ja
Publication of WO2004055674A1 publication Critical patent/WO2004055674A1/fr
Priority to US11/150,109 priority patent/US7587397B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1474—Saving, restoring, recovering or retrying in transactions
    • 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
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99938—Concurrency, e.g. lock management in shared database

Definitions

  • Distributed transaction processing apparatus distributed transaction processing program, distributed transaction processing method, and distributed transaction processing system
  • the present invention updates related data distributed and stored in a plurality of databases.
  • the present invention relates to a distributed transaction processing program and a distributed transaction processing method, in particular, a distributed transaction processing system capable of preventing the occurrence of blocking at the time of a failure with a small overhead and recovering database consistency immediately after recovery from the failure.
  • the present invention relates to a distributed transaction processing device, a distributed transaction processing program, and a distributed transaction processing method.
  • the server that started the distributed transaction sends a transaction request (local transaction request) to multiple servers, and succeeds from all servers that sent the local transaction request.
  • a transaction request local transaction request
  • a two-phase commit method in which a commit request is sent to all servers when a response is sent, and an abort request is sent otherwise, is well known.
  • commit means to actually update the database of each server during transaction processing.
  • This two-phase commit makes it possible to update all databases at the same time, and the atomicity of transactions, that is, the ability to perform transaction processing on all databases Transaction processing is performed on all databases. No power, can guarantee.
  • the technology for the two-phase commit method is disclosed.
  • the server that responds to the success of the local transaction cannot determine further action until the server that started the distributed transaction, that is, the master server instructs commit or abort. For this reason, the two-phase commit had a blocking problem in that if the master server failed, the servers that responded to the success of the local transaction had to wait until the master server started up again.
  • the present invention provides a distributed transaction processing apparatus, a distributed transaction processing program, and a distributed transaction that can prevent the occurrence of blocking at the time of a failure with a small overhead and can restore the consistency of a database immediately after recovery from the failure. It aims to provide a processing method and a distributed transaction processing system. Disclosure of the invention
  • the present invention provides a method for processing a transaction for updating related data distributed and stored in a plurality of databases.
  • a distributed transaction processing device used in a distributed transaction processing system and distributed on a network, wherein the transaction processing is performed in a log data storage device accessible by all the distributed transaction processing devices constituting the distributed transaction processing system.
  • Progress status recording means for recording the progress status of the log as log data; failure recovery means for performing a failure recovery process based on the log data recorded in the log data storage device by the progress status recording means; It is a special feature to have
  • the present invention provides a transaction in which data is distributed and stored in a database managed by each of a plurality of distributed transaction processing devices distributed on a network, and a transaction for updating the distributed and related data is performed.
  • a distributed transaction processing method for a distributed transaction processing system comprising: recording progress status of processing of said transaction as log data in a log data storage device accessible by all distributed transaction processing devices constituting said distributed transaction processing system. And a failure recovery step of performing a failure recovery process based on the log data recorded in the log data storage device by the progress status recording step.
  • the progress status of the transaction processing is recorded as the log data in the log data storage device accessible by all the distributed transaction processing devices constituting the distributed transaction processing system, and is recorded in the log data storage device. Failure recovery processing is performed based on log data, so that locking can be prevented in the event of a failure with a small amount of overhead, and database consistency can be restored immediately after recovery from the failure. Can be.
  • the present invention provides a distributed transaction processing system configured to process a transaction for updating related data distributed and stored in a plurality of databases, and the distributed transaction processing executed by a computer distributed on a network.
  • a program wherein the transaction data is stored in a log data storage device accessible by all computers constituting the distributed transaction processing system.
  • a progress status recording procedure for recording the progress status of the action processing as log data, and a fault recovery process for performing a fault recovery process based on the log data recorded in the log data storage device by the progress status recording procedure. Performing a step and a step.
  • the progress of transaction processing is recorded as log data in a log data storage device that can be accessed by all computers constituting the distributed transaction processing system, and the log data recorded in the log data storage device is recorded in the log data storage device. Since failure recovery processing is performed based on this, it is possible to prevent the occurrence of blocking when a failure occurs with a small amount of overhead, and to restore database consistency immediately after recovery from the failure.
  • the present invention provides a transaction in which data is distributed and stored in a database managed by each of a plurality of distributed transaction processing devices distributed on a network, and a transaction for updating the distributed and related data is performed.
  • a distributed transaction processing system for processing comprising: a storage device that is shared by the plurality of distributed transaction processing devices and stores a progress status of the processing of the transaction; and wherein the distributed transaction processing device includes the log data storage.
  • Progress status recording means for recording the progress status of transaction processing in the device as log data; and failure recovery processing based on the log data recorded in the log data storage device by the progress status recording means.
  • a failure recovery means for performing the following.
  • a log data storage device which is shared by a plurality of distributed transaction processing devices and stores the progress of transaction processing, and the distributed transaction processing device stores the transaction processing in the log data storage device.
  • the progress status is recorded as log data, and failure recovery processing is performed based on the log data recorded in the log data storage device.
  • FIG. 1 is an explanatory diagram for explaining the concept of the commit method of the distributed transaction processing system according to the present embodiment
  • FIG. 2 shows the system configuration of the distributed transaction processing system according to the present embodiment
  • FIG. 3 is a block diagram showing an example of the data structure of the tag data stored in the mouth file shown in FIG. 2
  • FIG. 4 is a diagram showing the global transaction processing unit shown in FIG.
  • FIG. 5 is a flowchart showing a processing procedure of the local transaction processing unit shown in FIG. 2
  • FIG. 6 is a flowchart showing a processing procedure of the failure recovery unit shown in FIG.
  • FIG. 7 is a flowchart showing a processing procedure
  • FIG. 7 is a flowchart showing a processing procedure of the other device failure recovery unit shown in FIG. 2, and
  • FIG. 9 is a functional Bed-locking diagram showing a configuration of the main portion shown in FIG. 8.
  • FIG. 1 is an explanatory diagram for explaining the concept of the commit method of the distributed transaction processing system according to the present embodiment.
  • FIG. 1A shows a conventional two-phase commit method
  • FIG. 1B shows a commit method according to the present embodiment.
  • a distributed transaction processing device that has started distributed transaction processing sends a local transaction to another distributed transaction processing device (slave device). Send a request to start Yeon processing.
  • slave device the master device sends a request for starting local transaction processing to a plurality of slave devices.
  • the master device itself functions as a slave device.
  • the slave device that has received the request to start the local transaction process executes the local transaction process, and when this process is successful, returns the success of the process to the master device without updating the database.
  • the master device waits for responses from all the slave devices that have sent the request to start the local transaction processing, and upon receiving successful responses from all the slave devices, sends a commit request to all the slave devices, Instruct the actual update of the database.
  • the master device receives at least one failure response from the slave device that sent the request to start the local transaction processing, it sends an abort request to all slave devices and instructs to discard the local transaction processing. I do.
  • the slave device cannot receive a commit request or an abort request from the master device, and the processing is interrupted. Will be locked. If the slave device goes down after responding to the master device that the local transaction processing was successful (down B), after recovering from the down state, information about the local transaction that notified the master device of the success is lost and the database is lost. Will not be updated.
  • the slave device that has received the request to start the local transaction process executes the oral transaction process, as shown in FIG. If it succeeds, it writes a prepare port 10 to the area of the shared disk corresponding to its own device before responding to the master device that the process was successful, and then responds to the master device that the process was successful.
  • the shared disk is a storage area that can be accessed by all distributed transaction processors.
  • the master device waits for responses from all slave devices that sent the request to start local transaction processing, and receives successful responses from all slave devices.
  • a commit request log 30 is written to an area corresponding to the self device of the shared disk, and then a commit request is sent to all slave devices. Then, the slave device that has received the commit request writes the commit acceptance log 20 to an area of the shared disk corresponding to the own device before performing the actual update of the database, and then performs the actual update of the database.
  • the slave device If the master device goes down before writing the commit request log 30 after sending the local transaction processing start request to the slave device (down C), the slave device sends the log data of the master device. Check the commit request log 30 in it, and abort the process. If the master device goes down after writing the commit request log 30 (Down D), the slave device examines the log data of the master device, finds the commit request log 30 therein, Perform commit processing.
  • the slave device goes down after writing the prepare log 10 and before writing the commit reception port 20 (down E), after recovering from the down, the log data of the master device is checked, and the operation is interrupted. Continue local transaction processing.
  • the commit request log 30 is present in the log data of the master device, the commit process is performed because the master device has issued a commit request during the downtime, and the commit request log is included in the log data of the master device. If there is no 30, perform the import process.
  • the slave device goes down after writing out the commit reception port 20 before performing the actual update of the database (down F), after recovering from the down, the log data of the own device is examined, and the commit reception port is checked. Find 20 and continue the commit process.
  • log data indicating the progress of distributed transaction processing is recorded on a shared disk that can be accessed by all distributed transaction processing devices, and when a failure occurs in the master device, The slave device Therefore, the oral transaction processing in a state of waiting for an instruction from the master device is determined by checking the data, so that the oral transaction processing of the slave device can be prevented from being blocked.
  • the slave device can continue processing related to the local transaction interrupted by the failure by checking the log data after the recovery from the failure.
  • FIG. 2 is a block diagram showing a system configuration of the distributed transaction processing system according to the present embodiment.
  • the distributed preparative Ranzakushiyon processing system includes N stand distributed transaction processing system 2 0 0 to 2 0 0 N connected via the network, a local database 2 7 0-2 7 0 and N, composed of a log file 2 8 0 1 ⁇ 2 8 0 N .
  • Distributed transaction processing system 2 0 0 ⁇ 2 0 0 N is an apparatus for processing a transaction distributed to, here, as all distributed transaction processing system 2 0 0 ⁇ 2 0 0 N master and slave devices Operate. That is, any distributed transaction processing device can start distributed transaction processing as a master device in response to a request from an application, and request local transaction processing to a plurality of distributed transaction processing devices.
  • Local Database 2 7 0 i ⁇ 2 7 0 N are respectively connected to the distributed transaction processing system 2 0 0 ⁇ 2 0 0 N, a database for storing specific data. These local database 2 7 0 ⁇ 2 7 0 N is distributed and stored data to be updated by the transaction process.
  • Log File 2 8 0 ⁇ 2 8 0 N is a file that stores the log data in a distributed transaction processing system 2 0 0 ⁇ 2 0 0 N, respectively. These log it le 2 8 ( ⁇ 2 8 0 N is created on the shared disk, each distributed transaction processing device, not only the mouth Gudeta that he has recorded, another distributed transaction processing apparatus is recorded Log data can also be accessed. Log File 2 8 0 8 0 N need not be on the shared disk, if. A storage device in which all of the distributed transaction processing system 2 0 0 i ⁇ 2 0 0 N access, memory or other storage It may be on the device.
  • this log file 2 8 0 ⁇ 2 8 0 N stores the transaction processing progress of each distributed transaction processing system SOC ⁇ SOON Kuchiku, as' de one data on a shared disk, part of a distributed Even if a failure occurs in the transaction processing device, another distributed transaction processing device can continue processing by referring to the log data and prevent blocking. In addition, the distributed transaction processing device in which the failure has occurred can continue the local transaction processing by referring to the log data after recovery.
  • the distributed transaction processing device 200 includes a global transaction processing unit 210, a local transaction processing unit 220, a log generation unit 230, a failure recovery unit 240, and other device failure recovery. It has a unit 250 and a down monitoring unit 260.
  • the global transaction processing unit 210 is a processing unit that causes the distributed transaction processing device 200 to function as a master device. That is, the global transaction processing unit 210 receives a transaction processing request from an application, sends a single transaction processing request to a plurality of distributed transaction processing devices, and the transaction that received the processing request is executed atomically. Control so that Here, the processing request sent to the plurality of distributed transaction processing devices includes a start request for requesting the start of execution of a local transaction, and the result of execution of the local transaction reflected in the local database. Commit request and low power to demand There is an appointment request requesting that the execution result of the transaction be discarded. The global transaction processing unit 210 requests local transaction processing not only from other distributed transaction processing devices but also from its own device. In addition, the global transaction processing unit 210 Also, commit request log 30 is recorded as log data indicating the progress status of the entire transaction processing.
  • the oral transaction processing unit 220 is a processing unit that processes the oral transaction by causing the distributed transaction processing device 200 i to function as a slave device. That is, the local transaction processing unit 220 processes the local transaction that has received the processing request from the global transaction processing unit 210, and reflects the processing result in the local database 270.
  • the local transaction processing unit 220 receives a local transaction processing request not only from the global transaction processing unit of another distributed transaction processing device but also from the global transaction processing unit 210 of its own device. receive.
  • the local transaction processing unit 220 records a prepare log 10 and a commit reception log 20 in a log file 280 as log data indicating the progress of the local transaction processing.
  • the progress status of the entire transaction processing unit 210 is recorded in the data file 280 as a commit request log 30 as the progress status of the entire S transaction processing, and the oral transaction processing unit 220 is recorded.
  • the prepare log 10 and the commit acceptance log 20 are recorded as log data 280 as log data indicating the progress of oral transaction processing.
  • the distributed transaction processing device 200 i failed. even is generated, the other distributed transaction processing apparatus continues processing with reference to the mouth Gufuainore 2 8 0 1, it is possible to prevent blocking.
  • the distributed transaction processing device 200 ! To continue the local transaction processing.
  • the log generation unit 230 is a processing unit that receives requests from the global transaction processing unit 210 and the role transaction processing unit 220 and writes the log data to the log file 28.
  • the failure recovery unit 240 uses the log data stored in the log file 28 O i S 800 N after the distributed transaction processing device 200 recovers from the failure to execute the local transaction processing interrupted by the failure. It is a processing unit that continues. By continuing the local transaction processing interrupted by the failure, the failure recovery unit 240 can recover the consistency of the local database.
  • the other device failure recovery unit 250 is a processing unit that, when a failure occurs in another distributed transaction processing device, performs a failure handling process for a transaction associated with the failed distributed transaction processing device.
  • the failure handling process performed by the other device failure recovery unit 250 includes a process for a transaction in which the distributed transaction processing device in which the failure has occurred has requested local transaction processing as a master device, and a process in which a failure has occurred.
  • the down monitoring unit 260 is a processing unit that monitors the status of the distributed transaction processing device that constitutes the distributed transaction processing system. More specifically, the status is monitored mutually by exchanging “I'mive message” between the distributed transaction processors. When the down monitoring unit 260 recognizes that a failure has occurred in another distributed transaction processing device, the down monitoring unit 260 restarts the other device failure recovery unit 250. Start up and perform failure recovery processing.
  • FIG. 3 is a diagram showing an example of a data structure of log data stored in the log file 280 shown in FIG.
  • FIG. 2A shows the data structure of the prepare log 10
  • FIG. 2B shows the data structure of the commit acceptance log 20
  • FIG. 1C shows the data structure of the commit request log 30. 2 shows a data structure.
  • the prepare log 10 includes a master device number 11 indicating the number of the distributed transaction processing device requesting the local transaction processing, and a transaction number 1 indicating a number that uniquely identifies the transaction. 2 and update contents 13 indicating the update data of the local database are included. Here, the updated content 13 indicates the data after the local transaction processing.
  • the commit reception log 20 similarly includes a master device number 21 indicating the number of the distributed transaction processing device that has requested the roll transaction processing, and a unique transaction.
  • a transaction number 22 indicating the identification number and an update content 23 indicating the update data of the local database are included.
  • the update contents 23 show the data after the local transaction processing.
  • the commit request log 30 is recorded by writing the number of the transaction that transmits the commit request to the global transaction history 31 for each distributed transaction processing device.
  • the global transaction history 31 stores the transaction number determined to be committed for each distributed transaction processing device. This global transaction history 31 is placed at the beginning of the log file.
  • FIG. 4 is a flowchart showing a processing procedure of the global transaction processing unit 210 shown in FIG.
  • the global transaction processing unit 210 When a transaction processing request is received from the case, a local transaction processing start request is sent to a plurality of distributed transaction processing devices (step S401), and a response from the distributed transaction processing device that sent the start request is sent. Wait (step S402). When a response is received from one of the distributed transaction processing devices that sent the start request (step S403), it is checked whether the response was successful (step S404), and the response is If it is successful, it checks whether or not it has received a successful response from all the distributed transaction processors that sent the start request (step S405).
  • the commit request log 30 is written to the log file 28 via the log generation unit 230 (step S 4). 0 6). Then, a commit request is sent to all the distributed transaction processing devices that have sent the start request (step S407), and a success of the transaction processing is returned to the application (step S408).
  • Step S410 if a successful response has not been received from all the distributed transaction processing devices that sent the start request, the process returns to step S402 and waits for a response from another distributed transaction processing device. If the response received from the distributed transaction processing device is not successful, an abort request is sent to the other distributed transaction processing device that sent the start request (step S409), and the transaction processing failure to the application ends. (Step S410).
  • FIG. 5 is a flowchart showing a processing procedure of the local transaction processing unit 220 shown in FIG.
  • the local transaction processing unit 220 checks the type of the request received from the global transaction processing unit (step S501), and if the type of the received request is a start request, First, the local transaction specified by the start request is processed (step S502). Then, the result of the local transaction processing is determined (step S503), and if the result is successful, the prepare log 10 is written to the log file 28 through the log generation unit 230 (step S503). 4) A response is sent to the global transaction processing unit that sent the start request, indicating success (step S505). On the other hand, if the result of the local transaction processing is unsuccessful, the update result by the low-power transaction processing is discarded (step S506), and the failure is sent to the global transaction processing unit that sent the start request. Respond (step S507).
  • step S508 If the type of the received request is an abort request, the update result by the local transaction processing is discarded (step S508). If the type of the received request is a commit request, the commit reception log 20 is written to the log file 280t via the login generation unit 230 (step S509), and the The actual update of the local database 270 i is scheduled (step S 510).
  • FIG. 6 is a flowchart showing a processing procedure of the failure recovery unit 240 shown in FIG. The failure recovery unit 240 is started when the distributed transaction processing device 200 recovers from a failure.
  • the failure recovery unit 240 reads log data from the log file 280 (step S601) and reads the log data.
  • the type of log data is checked (step S602).
  • the read log data is the prepare log 10
  • the prepared log 10 is stored in the memory (step S 603).
  • the read log data is the commit reception port 20
  • a failure has occurred in the distributed transaction processing device 200 before the commit request is received and the local database 27 is actually updated. Since this is the case, the low power database 270 is actually updated (step S640), and the corresponding prepare log 10 is deleted from the memory (step S650).
  • step S606 it is checked whether or not all the log data has been read from the log file 28. If not all the log data has been read, the process returns to the step S601 and returns to the next step. Read the log data of
  • step S607 when all the log data is read from the log file 28, it is checked whether or not the prepared log 10 remaining in the memory has a certain force (step S607), and the prepared log 10 is present.
  • the local transaction corresponding to the prepared log 10 does not receive a commit request, and therefore, the global transaction of the distributed transaction processing device having the number indicated by the master device number 11 in the prepared log 10 is performed.
  • the commit request log 30 for the distributed transaction processor 200 i is read from the run history 31 (step S 608), and it is checked whether there is a commit request log 30 corresponding to the prepare log 10. (Step S609).
  • whether or not the commit request log 30 corresponding to the prepare log 10 is present is determined by the transaction of the prepared log 10 in the read commit request log 30. Check if there is a transaction number that matches number 1 2.
  • step S610 the local database 270 is actually updated (step S610), and the prepare log 10 is discarded (step S611). Then, the process returns to step S607, and the next prepare log 10 is processed.
  • step S611 the prepare log 10 is discarded (step S611). Then, the process returns to step S607, and the next prepare log 10 is processed.
  • step S 6 12 If there is no prepared log 10 left in the memory or if all prepared logs 10 left in the memory have been processed, the log file 280 i is initialized (step S 6 12), and The commit transaction log 30 corresponding to the distributed transaction processor 200 of the global transaction history 31 of another distributed transaction processor is cleared (step S613).
  • FIG. 7 is a flowchart showing a processing procedure of the other device failure recovery unit 250 shown in FIG.
  • the other device failure recovery unit 250 is activated when the down monitoring unit 260 recognizes and recognizes a failure in another distributed transaction processing device.
  • the other-device failure recovery unit 250 first checks whether or not there is an instruction-waiting local transaction 3 in which the failed distributed transaction processing device is set as the master device (Step S). 7 0 1). And the local waiting for instructions If there is a transaction, the commit request log 30 for the distributed transaction processing device 200j is read from the global transaction history 31 of the distributed transaction processing device in which the failure has occurred (step S702), and It is checked whether or not the commit request log 30 corresponding to the instruction waiting local transaction has a certain power (step S703). As a result, if there is a corresponding commit request log 30, commit processing is performed (step S 704), and if there is no commit request log 30, abort processing is performed (step S 705). . Then, the process returns to step S701 to process the next local transaction waiting for an instruction.
  • step S 706 the global transaction history of the failed distributed transaction processing device 3 1
  • the part related to the distributed transaction processor 20 is cleared (step S 706).
  • an abort request is sent to another distributed transaction processing device for a transaction that has made a start request to the failed distributed transaction processing device (step S707).
  • the failed distributed transaction processing device is regarded as a master device, and the local transaction in a state of waiting for an instruction is processed. Since the failure response processing is performed based on the commit request log 30 recorded in the global transaction history 31, blocking due to the failure of the master device can be prevented.
  • the other device failure recovery unit 250 decides to abort the local transaction which has requested processing to the failed distributed transaction processing device when another distributed transaction processing device has failed. Thus, it is possible to prevent the distributed transaction processing apparatus in which the failure has occurred from being wastefully kept waiting.
  • all the distributed transaction processing apparatuses 2 0 0 ⁇ 2 0 0 N log file 2 8 0 i ⁇ 2 8 0 N provided in the shared disk that is accessible, Susumu ⁇ global transaction processing unit and the mouth one local transaction processing unit transaction processing of each distributed transaction processing system mouth Gudeta indicating the status recorded in the log file ⁇ ⁇ ⁇ 2 8 0 ⁇ , other distributed transactor when the action processor fails, the other device failure recovery unit log file 2 8 0 ⁇ 2 8 0 N Using the log data recorded in the transaction, recovery processing for transactions related to the distributed transaction processing unit in which the failure occurred is performed, thereby preventing the occurrence of blocking and guaranteeing the atomic generation of transactions. it can.
  • the failure recovery unit of the failed distributed transaction processing device operates the log file 280 X to 280 0 after recovery from the failure. Since the processing of the interrupted local transaction is continued by using the log data recorded in N , the atomicity of the transaction can be guaranteed and the consistency of the database can be restored.
  • the distributed transaction processing device operates as both a master device and a slave device.
  • the present invention is not limited to this, and the distributed transaction processing device is used only as a master device. The same can be applied to the case of operating, or the case of operating only as a slave device.
  • FIG. 8 is a diagram showing a computer system that executes the distributed transaction processing program according to the present embodiment.
  • the computer system 100 includes a main body 101, a display 102 for displaying information such as an image on a display screen 102a in accordance with an instruction from the main body 101, and various types of the computer system 100.
  • a keyboard 103 for entering information
  • a mouse 104 for specifying an arbitrary position on the display screen 102a of the display 102a
  • a LAN interface for connecting to a local area network (LAN) 106 or a wide area network (WAN)
  • a modem 105 connected to a public line 107 such as the Internet.
  • the LAN 106 connects the other computer system (PC) 11, the server 112, the printer 113, and the like to the computer system 100.
  • FIG. 9 is a functional block diagram showing the configuration of the main body 101 shown in FIG.
  • the main body 101 includes a CPU 121, a RAMI 22, a ROM 123, a hard disk drive (HDD) 124, a CD-ROM drive 125, an FD drive 126, and an I ⁇ interface 127. , And a LAN interface 128.
  • the computer system 100 When executing a distributed transaction processing program in the computer system 100, the computer system 100 is connected via a portable storage medium such as a floppy disk (FD) 108, a CD-ROM 109, a DVD disk, a magneto-optical disk, an IC card, and a LAN interface 128.
  • FD floppy disk
  • CD-ROM 109 CD-ROM
  • DVD disk DVD disk
  • magneto-optical disk an IC card
  • a LAN interface 128 a portable storage medium
  • the distributed transaction processing program stored in the database of the server 1 12 or another computer system (PC) 111 or the database of another computer system connected via the public line 107 is transferred to the computer system 100. install. Then, the installed distributed transaction processing program is stored in the HDD 124. It is stored and executed by the CPU 121 using the RAM I 22, ROM 23, and the like.
  • the progress status of transaction processing is recorded as log data in a log data storage device that can be accessed by all distributed transaction processing devices constituting the distributed transaction processing system.
  • the system is configured to perform failure recovery processing based on the log data recorded in the storage device, so that blocking can be prevented in the event of a failure with a small amount of overhead, and the consistency of the database can be maintained immediately after recovery from the failure. It has the effect of being able to recover.
  • the progress of transaction processing is recorded as log data in a log data storage device accessible by all computers constituting the distributed transaction processing system, and the log data recorded in the log data storage device is stored in the log data storage device. Since the system is configured to perform failure recovery processing based on this, it is possible to prevent the occurrence of blocking in the event of a failure with a small amount of overhead, and to restore the consistency of the database immediately after recovery from the failure. It works.
  • the distributed transaction processing apparatus includes a log data storage device that is shared by a plurality of distributed transaction processing devices and stores a progress status of transaction processing, and the distributed transaction processing device includes a log data storage device.
  • the progress of transaction processing is recorded as log data, and failure recovery processing is performed based on the log data recorded in the log data storage device. The effect is that the consistency of the database can be restored immediately after recovery from the failure.
  • the distributed transaction processing device As described above, the distributed transaction processing device, the distributed transaction processing program, the distributed transaction processing method, and the distributed transaction processing system according to the present invention require highly reliable distributed transaction processing that is resistant to chapter P damage. It is suitable for a distributed transaction processing system and its construction.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne un dispositif réparti de transactions, réparti sur un réseau de manière à être utilisé dans un système réparti de transactions pour mettre en oeuvre une transaction et mettre à jour des données associées, stockées dans une pluralité de bases de données. Le dispositif comprend une unité de transactions générale, et une unité de transactions locale servant à enregistrer des données de journalisation indiquant l'état d'avancement d'une transaction dans un fichier de journalisation auquel peuvent accéder tous les appareils de transactions répartis constituant le système de transactions réparti ; une autre unité de reprise sur incident d'appareil pour assurer la reprise, après incident, d'une transaction liée à un appareil de transactions réparti défaillant, au moyen des données de journalisation enregistrées dans le fichier de journalisation ; et une unité de reprise sur incident pour poursuivre la transaction locale interrompue par la défaillance, au moyen des données de journalisation enregistrées dans le fichier de journalisation, après la reprise.
PCT/JP2002/013250 2002-12-18 2002-12-18 Dispositif, programme, procede et systeme repartis de transactions WO2004055674A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2002/013250 WO2004055674A1 (fr) 2002-12-18 2002-12-18 Dispositif, programme, procede et systeme repartis de transactions
JP2004560585A JP4286786B2 (ja) 2002-12-18 2002-12-18 分散トランザクション処理装置、分散トランザクション処理プログラムおよび分散トランザクション処理方法
US11/150,109 US7587397B2 (en) 2002-12-18 2005-06-13 Distributed transaction processing control

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/013250 WO2004055674A1 (fr) 2002-12-18 2002-12-18 Dispositif, programme, procede et systeme repartis de transactions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/150,109 Continuation US7587397B2 (en) 2002-12-18 2005-06-13 Distributed transaction processing control

Publications (1)

Publication Number Publication Date
WO2004055674A1 true WO2004055674A1 (fr) 2004-07-01

Family

ID=32587968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2002/013250 WO2004055674A1 (fr) 2002-12-18 2002-12-18 Dispositif, programme, procede et systeme repartis de transactions

Country Status (3)

Country Link
US (1) US7587397B2 (fr)
JP (1) JP4286786B2 (fr)
WO (1) WO2004055674A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009080707A (ja) * 2007-09-27 2009-04-16 Jfe Steel Kk データベース同期更新処理方法、データベース同期更新処理システム、データベース同期更新処理プログラム、現品充当方法
JP2012022379A (ja) * 2010-07-12 2012-02-02 Nippon Telegr & Teleph Corp <Ntt> 分散トランザクション処理システム、装置、方法およびプログラム
JP2015170056A (ja) * 2014-03-05 2015-09-28 富士通株式会社 トランザクション処理装置、トランザクション処理プログラム及び分散処理システム
JP2017167842A (ja) * 2016-03-16 2017-09-21 株式会社日立製作所 トランザクション制御システムおよびトランザクション制御方法
JP2020529673A (ja) * 2017-08-01 2020-10-08 セールスフォース ドット コム インコーポレイティッド 分散ストアによる高可用性データベース
JP2020536339A (ja) * 2017-10-05 2020-12-10 ザダラ ストレージ インコーポレイテッド 共有ジャーナルを含むキーバリューストア間のコンシステンシー

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7363631B1 (en) * 2003-12-23 2008-04-22 Unisys Corporation Interface for accessing an open distributed transaction processing system log file
US20070143795A1 (en) * 2005-12-20 2007-06-21 Duong-Han Tran Application trace for distributed systems environment
US8156082B2 (en) * 2006-10-06 2012-04-10 Sybase, Inc. System and methods for temporary data management in shared disk cluster
WO2008105098A1 (fr) * 2007-02-28 2008-09-04 Fujitsu Limited Procédé de commande d'opération d'écriture miroir en mémoire
US20080243865A1 (en) * 2007-03-28 2008-10-02 Oracle International Corporation Maintaining global state of distributed transaction managed by an external transaction manager for clustered database systems
JP5385545B2 (ja) 2008-04-17 2014-01-08 インターナショナル・ビジネス・マシーンズ・コーポレーション トランザクションの実行を制御する装置及び方法
US8145838B1 (en) 2009-03-10 2012-03-27 Netapp, Inc. Processing and distributing write logs of nodes of a cluster storage system
US8327186B2 (en) * 2009-03-10 2012-12-04 Netapp, Inc. Takeover of a failed node of a cluster storage system on a per aggregate basis
US8069366B1 (en) * 2009-04-29 2011-11-29 Netapp, Inc. Global write-log device for managing write logs of nodes of a cluster storage system
US8301600B1 (en) * 2010-11-15 2012-10-30 Amazon Technologies, Inc. Failover recovery in a distributed data store
US9063969B2 (en) * 2010-12-28 2015-06-23 Sap Se Distributed transaction management using optimization of local transactions
US8984170B2 (en) 2011-09-09 2015-03-17 Oracle International Corporation Idempotence for database transactions
US8549154B2 (en) 2011-09-09 2013-10-01 Oracle International Corporation Recovering stateful read-only database sessions
WO2016049584A1 (fr) 2014-09-26 2016-03-31 Oracle International Corporation Système et procédé de récupération de transactions dans un environnement de serveur d'applications mutualisé
US10339127B2 (en) * 2016-01-28 2019-07-02 Oracle International Corporation Guaranteed commit outcome in a distributed transaction processing system
US11556500B2 (en) 2017-09-29 2023-01-17 Oracle International Corporation Session templates
CN107590286B (zh) * 2017-10-10 2021-03-09 苏州浪潮智能科技有限公司 在集群文件系统中事务信息的管理方法和装置
CN110196759B (zh) * 2018-06-20 2022-12-06 腾讯科技（深圳）有限公司 分布式事务处理方法和装置、存储介质及电子装置
TWI721355B (zh) * 2019-01-08 2021-03-11 資易國際股份有限公司 高可用度資料庫系統
CN115757330A (zh) * 2022-12-08 2023-03-07 丝路信息港云计算科技有限公司 一种分布式文件系统的高度可靠的元数据服务系统

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3006491B2 (ja) 1996-06-03 2000-02-07 日本電気株式会社 トランザクション実行状態管理システム、管理方法、および管理プログラムを記憶する媒体
US6023507A (en) * 1997-03-17 2000-02-08 Sun Microsystems, Inc. Automatic remote computer monitoring system
US6085244A (en) * 1997-03-17 2000-07-04 Sun Microsystems, Inc. Dynamic test update in a remote computer monitoring system
US6092084A (en) * 1997-03-28 2000-07-18 International Business Machines Corporation One system of a multisystem environment taking over log entries owned by another system
US7206805B1 (en) * 1999-09-09 2007-04-17 Oracle International Corporation Asynchronous transcription object management system
US7272649B1 (en) * 1999-09-30 2007-09-18 Cisco Technology, Inc. Automatic hardware failure detection and recovery for distributed max sessions server
US7203732B2 (en) * 1999-11-11 2007-04-10 Miralink Corporation Flexible remote data mirroring
US6490595B1 (en) 2000-03-30 2002-12-03 International Business Machines Corporation Method, system and program products for providing efficient syncpoint processing of distributed transactions
US20020001307A1 (en) * 2000-05-20 2002-01-03 Equipe Communications Corporation VPI/VCI availability index
US20050204214A1 (en) * 2004-02-24 2005-09-15 Lucent Technologies Inc. Distributed montoring in a telecommunications system
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US7519859B2 (en) * 2005-08-30 2009-04-14 International Business Machines Corporation Fault recovery for transaction server
US20070174695A1 (en) * 2006-01-18 2007-07-26 Srinidhi Varadarajan Log-based rollback-recovery

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
REDDY P.K. ET AL.: "Reducing the blocking in two-phase commit protocol employing backup sites", PROCEEDINGS OF 3RD IFCIS INTERNATIONAL CONFERENCE ON COOPERATIVE INFORMATION SYSTEMS, 1998, pages 406 - 415, XP010297249 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009080707A (ja) * 2007-09-27 2009-04-16 Jfe Steel Kk データベース同期更新処理方法、データベース同期更新処理システム、データベース同期更新処理プログラム、現品充当方法
JP2012022379A (ja) * 2010-07-12 2012-02-02 Nippon Telegr & Teleph Corp <Ntt> 分散トランザクション処理システム、装置、方法およびプログラム
JP2015170056A (ja) * 2014-03-05 2015-09-28 富士通株式会社 トランザクション処理装置、トランザクション処理プログラム及び分散処理システム
JP2017167842A (ja) * 2016-03-16 2017-09-21 株式会社日立製作所 トランザクション制御システムおよびトランザクション制御方法
JP2020529673A (ja) * 2017-08-01 2020-10-08 セールスフォース ドット コム インコーポレイティッド 分散ストアによる高可用性データベース
JP7263314B2 (ja) 2017-08-01 2023-04-24 セールスフォース インコーポレイテッド 分散ストアによる高可用性データベース
JP2020536339A (ja) * 2017-10-05 2020-12-10 ザダラ ストレージ インコーポレイテッド 共有ジャーナルを含むキーバリューストア間のコンシステンシー
JP7423534B2 (ja) 2017-10-05 2024-01-29 ザダラ ストレージ インコーポレイテッド 共有ジャーナルを含むキーバリューストア間のコンシステンシー

Also Published As

Publication number Publication date
US7587397B2 (en) 2009-09-08
US20050228834A1 (en) 2005-10-13
JPWO2004055674A1 (ja) 2006-04-20
JP4286786B2 (ja) 2009-07-01

Similar Documents

Publication Publication Date Title
WO2004055674A1 (fr) Dispositif, programme, procede et systeme repartis de transactions
US6978398B2 (en) Method and system for proactively reducing the outage time of a computer system
EP2521037B1 (fr) Groupes répartis géographiquement
US6665814B2 (en) Method and apparatus for providing serialization support for a computer system
US7448035B2 (en) Apparatus for maintaining resource integrity without a unified transaction manager in a software environment
US7730489B1 (en) Horizontally scalable and reliable distributed transaction management in a clustered application server environment
JP4283576B2 (ja) トランザクション同期方法、データベースシステム及びデータベース装置
JP4461147B2 (ja) リモートデータミラーリングを用いたクラスタデータベース
US7899897B2 (en) System and program for dual agent processes and dual active server processes
JPH086840A (ja) サーバ回復のためのディレクトリ操作の完了を判定する機構
US6381617B1 (en) Multiple database client transparency system and method therefor
KR100450400B1 (ko) 안전 기억 장치가 없는 환경을 위한 이중화 구조의 주 메모리 상주 데이터베이스 관리시스템 및 그 데이터 일치성 제어방법
US6389431B1 (en) Message-efficient client transparency system and method therefor
JPH09251412A (ja) 分散データベーストランザクションのコミットメント方法
JP2006004031A (ja) データ処理方法およびシステム並びにストレージ装置方法およびその処理プログラム
US6330686B1 (en) Handling protected conversation messages across IMS restart in shared queues environment
JP4500318B2 (ja) 分散トランザクション処理方法、装置、及びプログラム
US6212595B1 (en) Computer program product for fencing a member of a group of processes in a distributed processing environment
US6192443B1 (en) Apparatus for fencing a member of a group of processes in a distributed processing environment
EP1430419B1 (fr) Antememorisation de groupements avec verification d&#39;acces simultane
JP2008310591A (ja) クラスタシステム、計算機、および障害回復方法
JP2014038564A (ja) データベースに対する処理を行うシステム及び方法
JP4804653B2 (ja) 処理要求復旧システム
US20050165862A1 (en) Autonomic and fully recovering filesystem operations
US6205510B1 (en) Method for fencing a member of a group of processes in a distributed processing environment

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004560585

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11150109

Country of ref document: US

122 Ep: pct application non-entry in european phase