Nothing Special   »   [go: up one dir, main page]

WO2016120988A1 - Système de base de données et procédé de gestion de base de données - Google Patents

Système de base de données et procédé de gestion de base de données Download PDF

Info

Publication number
WO2016120988A1
WO2016120988A1 PCT/JP2015/052160 JP2015052160W WO2016120988A1 WO 2016120988 A1 WO2016120988 A1 WO 2016120988A1 JP 2015052160 W JP2015052160 W JP 2015052160W WO 2016120988 A1 WO2016120988 A1 WO 2016120988A1
Authority
WO
WIPO (PCT)
Prior art keywords
log
database
logs
integrated
generated
Prior art date
Application number
PCT/JP2015/052160
Other languages
English (en)
Japanese (ja)
Inventor
田中　剛
敦 友田
有哉 礒田
上村　哲也
Original Assignee
株式会社日立製作所
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 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2015/052160 priority Critical patent/WO2016120988A1/fr
Publication of WO2016120988A1 publication Critical patent/WO2016120988A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures

Definitions

  • the present invention generally relates to database management, for example, to output of transaction processing logs.
  • Patent Document 1 a transaction processing log (Tx log) is output.
  • Tx log transaction processing log
  • Patent Document 1 a transaction processing log
  • a plurality of clients in an application program each pass a Tx log to a single log management system, and the log management system stores a plurality of logs in a single log disk.
  • Multiple clients and log management systems exist within a computing device.
  • the HA High Availability
  • the database system includes an active server and a standby server.
  • the HA configuration it is necessary to transfer the Tx log from the active server to the standby server.
  • Patent Document 2 is known as this type of technology.
  • Patent Document 2 a plurality of Tx logs generated in the active server are transferred in parallel to the standby server.
  • Patent Document 1 a conflict may occur when writing or transferring a Tx log, and thus it is necessary to acquire a lock.
  • the client needs to write a Tx log in a single log management system after acquiring a lock.
  • the transfer parallelism the number of Tx logs that can be simultaneously transferred from the active server to the standby server
  • the transfer from the active server to the standby server is performed. It is necessary to transfer the Tx log after acquiring the lock of the transfer path.
  • the active server has a first execution unit that executes a plurality of first sub-execution units in parallel, and an integrated log management unit.
  • the plurality of first sub-execution units executed in parallel execute a plurality of transactions for the first database managed by the active server, generate a plurality of logs respectively corresponding to the plurality of transactions, and generate the plurality of logs Are respectively written in a plurality of log storage areas.
  • the integrated log management unit reads a plurality of logs from a plurality of log storage areas, generates an integrated log including the read logs, and transfers the generated integrated log to the standby server.
  • log writing and transfer can be performed at high speed.
  • FIG. 1 shows a configuration of a database system according to a first embodiment.
  • the data structure of the Tx log which concerns on Example 1, and an integrated Tx log is shown.
  • An example of log output is shown.
  • It is a flowchart of a Tx process.
  • 6 is a flowchart of log output processing according to the first embodiment.
  • 6 is a flowchart of integrated Tx log writing processing according to the first embodiment.
  • the structure of the database system which concerns on Example 2 is shown.
  • the data structure of the integrated Tx log which concerns on Example 2 is shown.
  • the structure of a partition access map is shown.
  • 12 is a flowchart of log output processing according to the second embodiment.
  • 12 is a flowchart of integrated Tx log writing processing according to the second embodiment. It is a flowchart of an integrated Tx log reflection process.
  • PDEV indicates a physical storage device, and may typically be a nonvolatile storage device (for example, an auxiliary storage device).
  • the PDEV may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).
  • the “storage unit” may be one or more storage devices including a memory.
  • the storage unit may be at least a main storage device of a main storage device (typically a volatile memory) and an auxiliary storage device (typically a nonvolatile storage device).
  • a functional unit for example, a query reception unit, a query execution plan generation unit, a query execution unit, an integrated log management unit, an LLSN management unit
  • the program is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process is appropriately performed using a storage unit (for example, a memory) and / or an interface device (for example, a communication port).
  • the subject of processing may be a processor.
  • the processing described with the functional unit as the subject may be processing performed by a processor or an apparatus or system having the processor.
  • the processor may include a hardware circuit that performs a part or all of the processing.
  • the program may be installed in a computer-like device from a program source.
  • the program source may be, for example, a storage medium that can be read by a program distribution server or a computer.
  • the program distribution server may include a processor (for example, a CPU) and a storage unit, and the storage unit may further store a distribution program and a program to be distributed.
  • the processor of the program distribution server executes the distribution program, so that the processor of the program distribution server may distribute the distribution target program to other computers.
  • two or more functional units may be realized as one functional unit, or one functional unit may be realized as two or more functional units.
  • a common code among the reference codes is used (for example, DBMS 101).
  • the reference numerals of the active server and its constituent elements include “C” meaning the active system, and the reference numerals of the standby server and its constituent elements are “S” meaning the standby system. Including.
  • FIG. 1 shows a configuration of a database system according to the first embodiment.
  • the database system includes an active server 100C and a standby server 100S.
  • An in-memory database is realized in each of the active server 100C and the standby server 100S. That is, the memory 117C of the active server 100C stores the DB partitions 109CA and 109CB constituting the DB, and the memory 117S of the standby server 100S also corresponds to the DB partitions 109CA and 109CB and constitutes the DB. 109SA and 109SB are stored.
  • the DB is divided into two DB partitions, but the DB may be divided into three or more DB partitions.
  • the DB partitions 109SA and 109SB have the same contents (replication) as the DB partitions 109CA and 109CB.
  • the active server 100C As an example. At least a part of the description of the active server 100C can be applied to the standby server 100S.
  • the elements illustrated for the standby server 100S are elements related to the operation as the standby server 100S, but the standby server 100S operates as the active server by being failed over from the active server 100C. Therefore, although not shown, it can have the same functional units as the active server 100C.
  • the active server 100C includes a PDEV I / F (interface device) 119C, a network I / F 120C, a memory 117C, and a processor 118C connected thereto.
  • a plurality of local logs PDEV 121C are connected to the PDEV I / V 119C.
  • the local log PDEV 121C is a PDEV that stores a local log file (described later).
  • the local log file (for example, the local log PDEV 121C) and the DB partition 109C may correspond 1: 1.
  • the standby server 100S is connected to the network I / F 120C via a communication medium such as a communication network.
  • the memory 117C is an example of a storage unit, and includes at least a main memory of a main memory (for example, a volatile memory such as a DRAM (Dynamic Random Access Memory)) and an auxiliary memory (for example, a non-volatile memory such as a flash memory). .
  • main memory for example, a volatile memory such as a DRAM (Dynamic Random Access Memory)
  • auxiliary memory for example, a non-volatile memory such as a flash memory.
  • the DBMS 101C is realized by the processor 118C executing a DBMS (Database Management System) program.
  • the DBMS 101C includes a query reception unit 102C, a query execution plan generation unit 103C, a dictionary 104C, an integrated log management unit 105C, and a query execution unit 106C.
  • the DBMC 101C manages the integrated log buffer 115C.
  • the DBMS 101C has an LLSN management unit 111C for each DB partition 109C, and manages a log buffer 113C provided for each DB partition 109C.
  • the processor 118C executes an OS (Operating System) 116C.
  • the DBMS 101C is executed on the OS 116C.
  • the log buffer 113C temporarily stores a Tx log including the update history of the corresponding DB partition 109C.
  • the Tx log written in the log buffer 113C is not deleted from the log buffer 113C even if written in the local log PDEV 121C, and is at least acquired by the integrated log management unit 105C (included in the integrated Tx log).
  • the processing thread 107C and the log buffer 113C may correspond 1: 1.
  • the LLSN management unit 111C is an example of an order management unit, and manages the LLSN.
  • “LLSN” is an abbreviation for local log sequence number.
  • the LLSN is a number that does not overlap in one DB partition 109C.
  • the LLSN is numbered when outputting the Tx log.
  • the dictionary 104C is information indicating the position of a database element (for example, a table and an index).
  • the query receiving unit 102C receives a query issued by a query issuer.
  • the query is described by, for example, a structured query language (SQL, Structured Query Language).
  • SQL Structured Query Language
  • a plurality of transactions may be described by one query, and a plurality of transactions may be described by a plurality of queries.
  • the query issuer may be a functional unit in the DBMS 101C or a functional unit outside the DBMS 101C (for example, a client computer (not shown)).
  • the query execution plan generation unit 103C generates a query execution plan including one or more database operations necessary for executing the query from the query received by the query reception unit 102C.
  • the query execution plan is information including, for example, a relationship between one or more database operations and the execution order of the database operations, and may be stored as query execution plan information.
  • a query execution plan may be represented by a tree structure in which a database operation is a node and a relation of execution order of database operations is an edge.
  • One or a plurality of transaction sets can be specified from one query execution plan or a combination of a plurality of query execution plans.
  • the query execution unit 106C executes the query received by the query reception unit 102C according to the query execution plan generated by the query execution plan generation unit 103C, and returns the execution result to the query issuer. At this time, the query execution unit 106C issues a data read request (reference request) necessary for the execution of the database operation, and uses the data read from the DB partition 109C in accordance with the read request, to execute the database operation ( For example, new data is calculated using the read data (value), and a write request for updating the data in the read source record to the calculated data is issued.
  • the query execution unit 106C performs a database operation by executing the processing thread 107C. That is, the processing thread 107C can execute the database operation with reference to the dictionary 104C as appropriate.
  • the processor 118C has a plurality of cores.
  • a plurality of cores exist in one or a plurality of processors 118C.
  • the processing thread 107C may be called a task.
  • a user thread realized by a library or the like may be used in addition to a process and kernel thread realized by the OS 116C.
  • One transaction corresponding to one or more database operations may be executed by one processing thread 107C.
  • the subject of processing performed by the query execution unit 106C executing the processing thread 107C may be the processing thread 107C.
  • the query execution unit 106C (processing thread 107C) issues an I / O request for the local log PDEV 121C to the OS 116C in order to write a Tx log to the local log file in the local log PDEV 121C during execution of the transaction.
  • the OS 116C accepts the I / O request and issues an I / O request to the local log PDEV 121C.
  • the PDEV I / F 119C may be provided with a plurality of I / O queues (not shown).
  • the processing thread 107C issues an I / O request for writing the Tx log, but the I / O request may be stored in the I / O queue.
  • the I / O request may be stored in the I / O queue by the OS 116C.
  • the local log PDEV 121C stores the local log file.
  • the Tx log to which the I / O request is written is recorded in the local log file.
  • the DB partition 109C, the I / O queue, and the local log file may correspond 1: 1: 1. That is, there may be one I / O queue and one local log file for each DB partition 109C. There may be one or more processing threads 107C per local log file. However, it may be possible to reduce the I / O request processing by sending an interrupt for notifying completion of the I / O request to a specific processing thread 107C for each I / O queue. For example, there may be a case where the processing thread 107C, the DB partition 109C, and the I / O queue have a 1: 1 correspondence. In this embodiment, in order to make the explanation easy to understand, the processing thread 107C may also correspond to the local log file 1: 1.
  • the processing thread 107CA issues a Tx log I / O request indicating that a record in the DB partition 109CA has been updated to a local log file corresponding to the DB partition 109CA.
  • the issued I / O request is sent to the OS 116C via the log buffer 113CA.
  • the OS 116C receives the I / O request for the local log file, and stores the I / O request in the I / O queue corresponding to the local log file.
  • the I / O request stored in the I / O queue is sent from the I / O queue to the local log PDEV 121C that stores the local log file of the I / O destination by the OS 116C.
  • the plurality of processing threads 107CA and 107CB write Tx logs in the plurality of log buffers 113CA and 113CB, respectively.
  • the integrated log management unit 105C extracts a plurality of Tx logs from the plurality of log buffers 113CA and 113CB, generates one integrated Tx log including the plurality of Tx logs, and stores the integrated Tx log in the integrated log buffer 115C. Write. Then, the integrated log management unit 105C transfers the integrated Tx log written in the integrated log buffer 115C to the standby server 100S.
  • the integrated Tx log transferred to the standby server 100S and received by the standby server 100S is written to the integrated log PDEV (PDEV in which the integrated Tx log is stored) 134S through the integrated log buffer 115S by the integrated log management unit 105S.
  • a processing thread (processing thread for log expansion processing) 107S for each DB partition 109S copies the integrated Tx log from the integrated log PDEV 134S to the memory 117S.
  • the processing thread 107S changes the records in the order of the LLSN written in the integrated Tx log by referring to the last Tx log from the first Tx log in the integrated Tx log based on the position information in the integrated Tx log.
  • the update indicated by the history 204 is performed on the corresponding DB partition 109S.
  • FIG. 2 shows the data structure of the Tx log and the integrated Tx log.
  • the Tx log 201 may be one per transaction, and the TxID 202 that is the ID of the transaction, one or more LLSNs 203 that are numbered during the execution of the transaction, and the record change that is information representing the update history of the transaction History 204.
  • the number of LLSNs 203 included in the Tx log 201 is the same as the number of DB partitions 109C updated in the execution of one corresponding transaction.
  • the checkpoint log may be a log indicating that a checkpoint has been generated.
  • the checkpoint log may include the TxID of the transaction that generates the checkpoint, all the LLSNs numbered in the generation of the checkpoint, and the ID of the generated checkpoint.
  • the checkpoint ID can be used to specify the restoration point.
  • the checkpoint ID may be a value representing the time when the checkpoint is generated.
  • the integrated Tx log 209 includes position information 210 and a plurality of Tx logs 201A, 201B,... Read from the plurality of log buffers 113CA and 113CB, respectively.
  • the position information is at least a part of the header information in the integrated Tx log 209 and includes a plurality of Tx start positions 211A, 211B,... Respectively corresponding to the plurality of Tx logs 201A, 201B,.
  • the Tx start position 211 is information (for example, an address) that is a position in the integrated Tx log 209 and that indicates the start position of the corresponding Tx log 201.
  • the integrated log management unit 105S can identify the positions of the plurality of Tx logs 201A, 201B,... In the integrated Tx log 209 by referring to the plurality of Tx start positions 211A, 211B,. .
  • Fig. 3 shows an example of log output.
  • the local log file 211C is stored in the local log PDEV 121C.
  • the Tx log 201 is stored in the local log file 211C.
  • a plurality of Tx logs 201 are arranged sequentially.
  • the integrated log file 219S is stored in the integrated log PDEV 134S.
  • the integrated Tx log 209 is stored in the integrated log file 219S.
  • a plurality of integrated Tx logs 209 are arranged sequentially.
  • FIG. 4 is a flowchart of the Tx process.
  • the thread that executes the transaction A is the processing thread 107CA
  • the DB partitions updated by the transaction A are the DB partitions 109CA and 109CB
  • the local log files corresponding to the DB partitions 109CA and 109CB, respectively, are local log files.
  • 211CA and 211CB are local log files.
  • the processing thread 107CA When the transaction A is started, the processing thread 107CA generates a reference / update set for each of the DB partitions 109CA and 109CB based on an instruction corresponding to the transaction A (instruction in the query) (S301).
  • the reference / update set is a set of record reference (read request for partition) and record update (write request for partition).
  • the reference / update set is a request set for updating the partition, but at the time of S301, the DB partitions 109CA and 109CB are not changed, and are allocated in the local memory area (main memory 461) corresponding to the transaction A.
  • the reference / update set is held in a region (not shown).
  • the processing thread 107CA makes a commit determination (S302).
  • the commit determination is performed according to the isolation level of the database, for example, whether the change to the DB partitions 109CA and 109CB performed by the transaction A based on the reference / update set is consistent with other transactions. .
  • the processing thread 107CA executes a log output process (S304).
  • the processing thread 107CA updates the DB partitions 109CA and 109CB based on the reference / update set (S305), issues a commit completion notification to the query issuer (S306), and ends the transaction.
  • FIG. 5 is a flowchart of the log output process.
  • the LLSN management unit of the local log file 211CA associated with the processing thread 107CA executing the transaction A is the LLSN management unit 111CA.
  • the processing thread 107CA acquires the log file address from the LLSN management unit 111CA, and adds the log size of the transaction A to the log file address of the LLSN management unit 111CA (S401).
  • the processing thread 107CA numbers the LLSN of the DB partition 109CA or 109CB updated by executing the transaction A (S402).
  • the processing thread 107CA numbers the LLSN of the DB partition 109CA or 109CB updated by executing the transaction A (S402).
  • the processing thread 107CA performs S402 on the unnumbered DB partition. On the other hand, if the LLSNs of all the updated DB partitions 109CA and 109CB have been numbered (S403: No), the processing thread 107CA generates the Tx log 201 and writes the Tx log 201 to the log buffer 113CA. Then, a write request for the Tx log 201 (write request specifying the log file address acquired from the LLSN management unit 111CA) is issued (S404). The processing thread 107CA receives a write completion notification from the local log PDEV 121CA via the PDEV I / F 119C (S405).
  • the processing thread 107CA executes the integrated Tx log writing process (S407), and ends the log output process when the integrated Tx log writing process is completed.
  • the mode is the log asynchronous mode (S406: No)
  • the processing thread 107CA ends the log output process without executing the integrated Tx log writing process.
  • the “log synchronous mode” is a mode in which the log output process ends when the integrated Tx log write process is executed in the log output process and the integrated Tx log write process ends.
  • the “log asynchronous mode” is a mode in which the integrated Tx log writing process is executed asynchronously with the log output process.
  • the current mode may be registered in the memory 117C.
  • the mode is the log synchronous mode or the log asynchronous mode may be set or changed by the user, or may be dynamically changed depending on the status of the active server 100C.
  • Synchronous mode is used for systems that handle information that should not be lost, such as bank account information such as bank ATMs, and is used in cases where reliability is more important than performance.
  • the transaction log is completely identical between the active system and the standby system, so even if a single failure point (single point of failure) occurs, up to which transaction can be processed by referring to either log disk. Whether or not the processing is complete can be reliably determined, and the processing data is not lost.
  • the asynchronous mode is utilized in a system that places importance on response time even if there is a possibility that a log that cannot be copied to the standby system may occur when a failure occurs.
  • FIG. 6 is a flowchart of the integrated Tx log writing process.
  • the integrated Tx log writing process starts when the processing thread 107CA that executes the transaction A to be executed starts the integrated log management unit 105C.
  • the integrated Tx log writing process starts at a preset interval or when a predetermined event occurs.
  • the integrated log management unit 105C polls all the log buffers 113C and determines whether Tx logs are stored in two or more log buffers 113C (for example, all log buffers 113C) (S501). If the determination result in S501 is negative (S501: No), the integrated Tx log writing process ends.
  • the integrated log management unit 105C performs S502. That is, all Tx logs are acquired from all log buffers 113C in which Tx logs are stored.
  • the integrated log management unit 105C determines a Tx start position 211 (position (address) in the integrated Tx log) for each Tx log based on a plurality of Tx log sizes respectively corresponding to the acquired plurality of Tx logs.
  • Position information 210 including a plurality of Tx start positions 211 respectively corresponding to the Tx logs.
  • the integrated log management unit 105C generates an integrated Tx log 209 including the generated position information 210 and a plurality of acquired and sequentially arranged Tx logs.
  • the integrated log management unit 105C writes the generated integrated Tx log 209 in the integrated log buffer 115C.
  • the integrated log management unit 105C transfers the integrated Tx log 209 (the integrated Tx log 209 generated in S502) in the integrated log buffer 115C to the standby server 100S through the network I / F 120C (S503).
  • the standby server 100S receives the integrated Tx log 209, and the integrated log management unit 105S writes the received integrated Tx log 209 in the integrated log file 219S in the integrated log PDEV 134S (S504).
  • the integrated log management unit 105S notifies the active server 100C of the reception completion (S505).
  • the active server 100C receives the notification of reception completion, and the integrated log management unit 105C clears the integrated Tx log 209 from the integrated log buffer 115C in response to the notification, and the processing thread 107C (at least Tx in S502)
  • the processing thread 107C) corresponding to the log buffer 113C of the log acquisition source is notified of the completion of log writing in the standby server 100S (S506).
  • the processing thread 107C that has received the notification clears the Tx log from the log buffer 113C corresponding to the processing thread 107C (S507).
  • the processing thread 107C writes the Tx log 201 to the log buffer 113C corresponding to the processing thread 107C.
  • a dedicated log buffer 113C is provided for each processing thread 107C. Therefore, in the active server 100C, a plurality of Tx can be written in the plurality of log buffers 113C in parallel, and there is no contention for writing to the log buffer 113C. Further, since the integrated Tx log is generated by reading a plurality of Tx logs from the plurality of log buffers 113C and written to the integrated log buffer 115C, there is no contention when the integrated Tx logs are generated / written.
  • a plurality of Tx logs are serially arranged in the integrated Tx log, and the single integrated Tx log is transferred from the active server 100C to the standby server 100S.
  • the single integrated Tx log is transferred from the active server 100C to the standby server 100S.
  • Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.
  • the integrated Tx log includes a Tx log that does not need to be referred to by the processing thread 107S, specifically, a Tx log that includes an update history of a DB partition 109S different from the DB partition 109S corresponding to the processing thread 107S. ing.
  • the processing thread 107S of each DB partition 109S refers to all the Tx logs of the integrated Tx log. For this reason, it takes time to restore the DB partition 109S. Particularly in an in-memory database, it is desirable to shorten the database restoration time as much as possible.
  • the processing thread in reflecting the integrated Tx log, refers to only the Tx log related to the update of the DB partition corresponding to the processing thread among the plurality of Tx logs in the integrated Tx log. It is possible to skip Tx logs that are not related to the update of the DB partition corresponding to the processing thread. For this reason, the database restoration time can be shortened.
  • Example 2 will be described in detail.
  • elements different from those in the first embodiment are denoted by reference numerals different from those in the first embodiment.
  • FIG. 7 shows the configuration of the database system according to the second embodiment.
  • the DBMS 1010C manages the partition access map 151C for each processing thread 1070C.
  • the partition access map 151C is information indicating the DB partition 109C updated by the corresponding processing thread 1070C.
  • FIG. 8 shows the data structure of the integrated Tx log according to the second embodiment.
  • the location information 2100 of the integrated Tx log 2090 includes a partition access map 151C in addition to the Tx start location 211 for each Tx log 201.
  • the processing thread (processing thread for log expansion processing) 1070SA determines whether or not the partition access map 151CA indicates the update of the DB partition 109SA. When the determination result is affirmative, the processing thread 1070 Sk updates the DB partition 109SA according to the Tx log 201A specified from the Tx start position 211A. On the other hand, if the determination result is negative, the processing thread 1070 Sk skips reading the Tx start position 211A (Tx log 201A).
  • FIG. 9 shows the configuration of the partition access map 151C.
  • the partition access map 151C is a bitmap.
  • the partition access map 151C is composed of a plurality of bits respectively corresponding to the plurality of DB partitions 109C. Bit “1” means that the DB partition 109 corresponding to the bit has been updated. Bit “0” means that the DB partition 109 corresponding to the bit has not been updated.
  • the bit map is an example of the partition access map 151C.
  • the partition access map 151C may have another configuration, for example, a list of updated DB partition 109C IDs.
  • FIG. 10 is a flowchart of the log output process according to the second embodiment.
  • the processing thread 1070S updates the bit corresponding to the updated DB partition 109C in the partition access map 151C corresponding to the processing thread 1070S to “1” for each DB partition 109C updated in the transaction processing (S441). Others are the same as in the first embodiment.
  • FIG. 11 is a flowchart of the integrated Tx log writing process according to the second embodiment.
  • S5020 is performed instead of S502.
  • all Tx logs are acquired from all log buffers 113C in which Tx logs are stored.
  • the integrated log management unit 105C determines a Tx start position 211 (position (address) in the integrated Tx log) for each Tx log based on a plurality of Tx log sizes respectively corresponding to the acquired plurality of Tx logs.
  • the integrated log management unit 1050C includes a plurality of partition access maps 151C corresponding to the plurality of Tx logs in addition to the plurality of Tx start positions 211 respectively corresponding to the plurality of Tx logs included in the integrated Tx log. Information 2100 is generated.
  • the integrated log management unit 1050C generates an integrated Tx log 2090 that includes the generated position information 2100 and a plurality of acquired and sequentially arranged Tx logs.
  • the integrated log management unit 1050C writes the generated integrated Tx log 2090 in the integrated log buffer 115C. Others are the same as in the first embodiment.
  • FIG. 12 is a flowchart of the integrated Tx log reflection process.
  • the integrated Tx log reflection process may be started, for example, when the administrator of the standby server 100S is instructed to start the integrated Tx log reflection process, or when the integrated Tx log is stored in the integrated log PDEV 134S. May be started.
  • the plurality of processing threads (log development processing thread) 1070S are executed in parallel, for example, and the following processing is performed for each processing thread 1070S.
  • the processing thread 1070S reads the integrated Tx log from the integrated log PDEV 134S to the work area of the processing thread 1070S (S1201).
  • Each processing thread 1070S refers to the first partition access map 151C in the integrated Tx log stored in the work area, and determines whether the partition access map 151C indicates the update of the DB partition 109S (S1202). .
  • the processing thread 1070S performs a reflection process of the Tx log 201 specified from the Tx start position 211x corresponding to the partition access map 151C (S1203). Specifically, the processing thread 1070S refers to the identified Tx log 201, and updates the DB partition 109Sk according to the referenced Tx log 201k.
  • the processing thread 1070S skips the Tx start position 211 (Tx log 201) corresponding to the referenced partition access map 151C (S1204).
  • the processing thread 1070S determines whether or not the partition access map 151C referenced in the immediately preceding 1202 is the last partition access map 151C (S1205).
  • the processing thread 1070S performs S1202 for the next partition access map 151C.
  • the processing thread 1070S selects only the Tx log related to the update of the DB partition corresponding to the processing thread 1070S among the plurality of Tx logs in the integrated Tx log.
  • the Tx log that is not related to the update of the DB partition corresponding to the processing thread 1070S can be skipped. For this reason, the database restoration time can be shortened.
  • the Tx log may be deleted from the log buffer 113C when it is written from the log buffer 113C to the local log PDEV 121C.
  • the integrated log management unit 105C may acquire a Tx log to be included in the integrated Tx log (a Tx log that has not been included in the integrated Tx log) from the local log PDEV 121C in the integrated Tx log writing process. .
  • the case where the LLSN is numbered may be a case where a set of transactions executed between checkpoints is at least a first type transaction set of a first type transaction set and a second type transaction set.
  • the first type transaction set may be a set of transactions whose results change depending on the transaction execution order. For example, according to the partial order, a plurality of transactions that update the same record must be executed in a defined order, but a plurality of transactions that update different records may be executed in any order.
  • the second type transaction set may be a transaction set in which the execution order of transactions does not affect the result. Whether the transaction to be executed belongs to the first type or the second type transaction set may be determined from one or a plurality of query execution plans, for example.
  • the LLSN (order) managed by the LLSN management unit 111C may be updated each time a Tx log of a transaction in which the DB partition 109C corresponding to the LLSN management unit 111C is updated is generated.
  • M Tx logs may be generated (M is N or less and M is an integer of 1 or more) as a transaction log (N is an integer of 2 or more) that updates N DB partitions 109C among a plurality of DB partitions 109C. ).
  • At least one of the M Tx logs may include two or more LLSNs among the N LLSNs respectively corresponding to the N DB partitions 109C.
  • the Tx log including one LLSN is written to the log buffer 113C corresponding to the LLSN and includes two or more LLSNs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Selon le présent système de base de données, un serveur de système actif comporte une première unité d'exécution, qui exécute en parallèle une pluralité de premières sous-unités d'exécution, et une unité de gestion de journal intégré. Les sous-unités d'exécution de la pluralité de premières sous-unités d'exécution exécutées en parallèle exécutent une pluralité de transactions par rapport à une première base de données gérée par le serveur de système actif, génèrent une pluralité de journaux, chacun correspondant à une transaction respective de la pluralité de transactions, et écrivent chaque journal de la pluralité de journaux générés dans une région correspondante d'une pluralité de régions de mémorisation de journaux. L'unité de gestion de journal intégré lit la pluralité de journaux à partir de la pluralité de régions de mémorisation de journaux, génère un journal intégré comprenant la pluralité de journaux lus, et transfère le journal intégré généré vers un serveur de système de secours.
PCT/JP2015/052160 2015-01-27 2015-01-27 Système de base de données et procédé de gestion de base de données WO2016120988A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/052160 WO2016120988A1 (fr) 2015-01-27 2015-01-27 Système de base de données et procédé de gestion de base de données

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/052160 WO2016120988A1 (fr) 2015-01-27 2015-01-27 Système de base de données et procédé de gestion de base de données

Publications (1)

Publication Number Publication Date
WO2016120988A1 true WO2016120988A1 (fr) 2016-08-04

Family

ID=56542646

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/052160 WO2016120988A1 (fr) 2015-01-27 2015-01-27 Système de base de données et procédé de gestion de base de données

Country Status (1)

Country Link
WO (1) WO2016120988A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH096658A (ja) * 1995-06-21 1997-01-10 Shikoku Nippon Denki Software Kk トランザクションジャーナル管理方式
JP2006268531A (ja) * 2005-03-24 2006-10-05 Hitachi Ltd データ処理システム及びデータベースの管理方法
JP2006277208A (ja) * 2005-03-29 2006-10-12 Hitachi Ltd バックアップシステム、プログラム及びバックアップ方法
JP2010287142A (ja) * 2009-06-15 2010-12-24 Hitachi Ltd フォールトトレラントコンピュータシステムおよびフォールトトレラントコンピュータシステムにおける方法
WO2014097475A1 (fr) * 2012-12-21 2014-06-26 株式会社Ｍｕｒａｋｕｍｏ Méthode de traitement d'informations, dispositif de traitement d'informations et programme

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH096658A (ja) * 1995-06-21 1997-01-10 Shikoku Nippon Denki Software Kk トランザクションジャーナル管理方式
JP2006268531A (ja) * 2005-03-24 2006-10-05 Hitachi Ltd データ処理システム及びデータベースの管理方法
JP2006277208A (ja) * 2005-03-29 2006-10-12 Hitachi Ltd バックアップシステム、プログラム及びバックアップ方法
JP2010287142A (ja) * 2009-06-15 2010-12-24 Hitachi Ltd フォールトトレラントコンピュータシステムおよびフォールトトレラントコンピュータシステムにおける方法
WO2014097475A1 (fr) * 2012-12-21 2014-06-26 株式会社Ｍｕｒａｋｕｍｏ Méthode de traitement d'informations, dispositif de traitement d'informations et programme

Similar Documents

Publication Publication Date Title
US9798792B2 (en) Replication for on-line hot-standby database
US9563636B2 (en) Allowing writes to complete without obtaining a write lock to a file
CN109086388B (zh) 区块链数据存储方法、装置、设备及介质
JP6152431B2 (ja) データベース管理システム及び方法
JP6445049B2 (ja) ログの管理方法及び計算機システム
US10007548B2 (en) Transaction system
US11321302B2 (en) Computer system and database management method
US11366788B2 (en) Parallel pipelined processing for snapshot data deletion
EP4170509A1 (fr) Procédé de lecture d'un journal sur un noeud de données, noeud de données et système
KR101584760B1 (ko) 순서 모드 저널링 파일 시스템을 위한 블록 그룹 단위 저널링 방법 및 장치
US8015375B1 (en) Methods, systems, and computer program products for parallel processing and saving tracking information for multiple write requests in a data replication environment including multiple storage devices
CN112015591A (zh) 一种日志管理方法、服务器和数据库系统
US11442663B2 (en) Managing configuration data
US11210024B2 (en) Optimizing read-modify-write operations to a storage device by writing a copy of the write data to a shadow block
EP3951611A1 (fr) Procédé, appareil et dispositif de vérification de bloc
US10025680B2 (en) High throughput, high reliability data processing system
US7949632B2 (en) Database-rearranging program, database-rearranging method, and database-rearranging apparatus
WO2016120988A1 (fr) Système de base de données et procédé de gestion de base de données
CN112559457A (zh) 数据访问方法及装置
KR20190096837A (ko) 충돌 페이지 리스트를 이용한 병렬 저널링 방법 및 그 장치
US20210034580A1 (en) Method, apparatus and computer program product for maintaining metadata
US20230385271A1 (en) Throughput-optimized schema-flexible storage with transactional properties
JP7024432B2 (ja) データベース管理システム、データ変換プログラム、データ変換方法及びデータ変換装置
JP6263673B2 (ja) 計算機システム及びデータベース管理方法
WO2018107460A1 (fr) Procédé et appareil de copie sur la base d'un objet, et dispositif de stockage sur la base d'un objet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15879885

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15879885

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP