JP5061250B2 - Database management method and storage system - Google Patents

Description

  The present invention relates to disaster recovery technology by log transfer, and in particular, reads and applies logs at a finer granularity than files, and re-reads logs or links with remote copy during log reading and application processing The present invention relates to a technology that is effective when applied to a disaster recovery technology that performs read.

  In recent years, IT has become the foundation of business and its importance is increasing. For this reason, the impact of system down is very large. For example, in the financial industry, it is said that there is a loss of several million dollars per hour. From the above background, disaster recovery (hereinafter referred to as DR), which backs up data to a remote location for the purpose of continuing business even in the event of a disaster, has attracted attention.

  As a method for realizing transfer between sites in the DR system, a method using a high-functional storage having a remote copy function has been attracting attention. As an advantage of the method using remote copy, transfer between sites can be realized without consuming server resources.

  In response to terrorism and wide-area disasters, there are trends in laws and regulations, and even with DR systems that use remote copy, (1) business can be resumed at the secondary site without data loss in the event of a disaster, and (2) There is a need to simultaneously solve the problem of maintaining the online performance of the primary site even when the site is located at a remote location several hundred kilometers away.

  At present, the DR system is being introduced mainly in the financial industry and large corporations. However, in the future, it is considered that the introduction of the DR system is also required for SMEs for reasons such as risk avoidance and rating. In order to expand the scope of application to small and medium enterprises, in addition to the above-mentioned two problems, reduction of DR system cost is an important problem. Here, in the current DR system, a dedicated line is often used from the viewpoint of reliability and security. Since the construction and maintenance of a dedicated line having a wide bandwidth requires enormous costs, it is essential to reduce the line cost in order to reduce the DR system cost.

  As a method for solving the above problems, there is a DR method in which only a log file of a database processing system (hereinafter referred to as DBMS) is transferred by remote copy, and a database (hereinafter referred to as DB) file is recovered from a log at a secondary site. Attention has been paid. In this method, transfer of the DB file is not required, so that the line cost can be greatly reduced. In recent years, the DR system for transferring logs has been required to speed up switching at the time of a disaster, systematic switching, or ease of operation.

  For example, as a method of transferring a log file by remote copy and recovering a DB file (DB volume: hereinafter referred to as a VOL) at the secondary site, the conventional method 1 (Non-patent Document 1) and the conventional method 2 (patent) Two methods of literature 1) are known.

(Conventional method 1)
This conventional method 1 is shown in FIG. FIG. 15 is a diagram illustrating an example of the configuration of a system to which the conventional method 1 is applied. In FIG. 15, 101 is a DBMS in the primary site server 100, 1400 is a DBMS in the secondary site server, 120 is a primary site storage, 130 is a secondary site storage, 128 and 138 are log VOLs, 129 and 139. Denotes a DB VOL, 1401 and 1411 denote archive log VOLs, and 1402 denotes a network. Further, 1403 is a remote copy, 1404 is a server-to-server transfer, 1405 is a log read, 1406 is a log application, and 1407 is a processing route indicating an archive.

  In general, a log file (log VOL) in which logs that are update differences to a DB are recorded is managed by generation management of multiple log files, and logs are added while switching at an event trigger such as exceeding capacity. Go. At this time, since the log file is repeatedly overwritten, an archive log file (archive log VOL) is created for the purpose of saving the contents of the switching source log file.

  In the method of FIG. 15, the log is transferred by remote copy and the archive log is transferred between servers. In the computer at the secondary site, the standby DBMS receives the archive log and recovers the DB (DB VOL) by applying the received archive log.

(Conventional method 2)
This conventional method 2 is shown in FIG. FIG. 16 is a diagram illustrating an example of the configuration of a system to which the conventional method 2 is applied. In FIG. 16, reference numeral 1600 denotes a processing route indicating an archive, and the same components as those in FIG.

  In the method of FIG. 16, only the log is transferred by remote copy. At the secondary site, archive log file generation at the primary site is monitored, and when archive log file generation is detected, an archive log file is also generated independently at the secondary site. When the archive log file is generated, the DB is updated by applying the file.

US Pat. No. 5,640,561

SANRISE Solution Suite with Oracle (http://www.hitachi.co.jp/Prod/comp/storage/diskarray/tech/whitepaper/pdf/tech_disaster.pdf)

  By the way, in the conventional method as described above, a log of one generation or more before is applied for each file instead of the latest log file being written at the primary site. This is because if the VOL being written by remote copy is read as it is, the consistency of the read contents is not guaranteed. These methods have the following problems.

(Issue 1: Rapid FO (Failover) is difficult)
In general, from the viewpoint of facilitating the operation, the operation of frequently archiving log files is not preferred, and the size of log files tends to increase. For this reason, the recovery method for each file must start log application from the beginning of a large file even during a disaster / planned FO, requiring a lot of processing time to complete the FO, and prompt service Cannot resume.

(Issue 2: Maintaining online performance of the main site and guaranteeing DB consistency)
In order to speed up the FO time, it is only necessary to read and apply the log with a finer granularity than the file, with the log file being used by the primary site being the target of reading, not the log file unit. Here, in order to recover the DB correctly, it must be ensured that the log is read correctly. However, if the log file is read during writing by remote copy, the log may be read illegally. In the following, after explaining the structure of the log file, a case where the log is read illegally will be explained.

  First, the structure of the log file and the read / write method will be described. Here, the update difference information for a row itself is called a log record. In the DBMS at the primary site, a log record is always generated when updating. However, every time a log record is generated, if it is output to the storage, the online performance is greatly affected. Therefore, buffering is performed internally and output is performed in units of log blocks composed of a plurality of records. A log block has a header and a trailer, and since both are written normally, consistency of the block can be guaranteed. For this purpose, even when the log is read at the secondary site, it can be read in block units, and the consistency can be verified by the header and trailer.

  However, when applied to a DR system that considers wide-area disasters, there are cases where consistency cannot be verified only by the above processing. When the distance between sites is long and the transfer delay is large, in order to minimize the influence of the transfer delay, it is desirable to increase the block size and reduce the number of transfers. However, when this block size is larger than the storage cache management unit (reading unit), there is a case in which log block consistency verification cannot be performed correctly. Such illegal integrity verification occurs when log application has completely caught up with online processing at the primary site, and the log application function at the secondary site is trying to read the area that is being written at the primary site. Arise.

  An example is shown in FIG. FIG. 17 is a diagram for explaining an example when log reading cannot be performed normally. In FIG. 17, 1500 is a log block, 1501 is a write (1) area, 1502 is a read (1) area, 1503 is a write (2) area, 1504 is a read (2) area, and 1505 is read by the log application unit. Each log block is shown.

  The DBMS at the primary site writes the entire log block, but may be divided into a plurality of IOs in the OS layer. In FIG. 17, it is divided into two IOs, and each is transferred by remote copy. At the secondary site, a log application unit having a log application function performs read processing independently of the IO at the primary site. At this time, in the storage, data management is performed in units of cache management, and reading is also performed in units of cache management.

  In FIG. 17, one write of the primary site DBMS is divided into two writes in the OS layer, and when only the first write is completed, the first log application read is performed. (T → t + 2). Subsequently, after the second writing is completed and writing of the entire block is completed, the log application unit performs the second reading (t + 3 → t + 4). As a result, the log block 1505 read by the log application unit is in a hollow state as shown in FIG. In this case, since the head / tail (header / trailer) is correctly read, it is determined that the log block is correct, and log application is performed. As a result, the sub-site DB is destroyed.

  As described above, in the DR method in which the log is transferred by remote copy to reduce the line cost and the DB is recovered by applying the log, (1) When the log file is read / applied, a quick FO is performed. (2) If application is performed with a finer granularity than a file in order to perform quick FO, there is a problem that the DB may be destroyed by reading and applying an invalid log.

  Accordingly, an object of the present invention is to realize a high-speed FO by reading and applying a log with a finer granularity than a file, and re-reading a log or performing remote reading in a log reading / applying process. An object of the present invention is to provide a DR technology that can perform log reading correctly even when the log writing unit of the primary site is large by performing reading linked with copying.

  The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in the present application, the outline of typical ones will be briefly described as follows.

  The present invention reads and applies logs with a finer granularity than files to speed up FO, and reads and applies logs in order to correctly read logs even when the log writing unit at the main site is large. During the process, the log is re-read or read in conjunction with remote copy. That is, in the present invention, the DR method and DR system for copying the DBMS data of the primary site to the remote site located at the remote location, and the update applied to the first storage (primary storage) are located at the remote location. The remote copy method and storage system reflected in the second storage (secondary storage) have the following characteristics.

  (1) A log consisting of multiple log records at the primary site in a log application process where the log is transferred at the primary site by remote copy of the primary storage, and the transferred log is applied at the secondary site to recover the secondary storage DB When writing in block units and applying logs at the secondary site, the following processing is performed. Read log blocks from secondary storage and verify consistency. When reading the log block, it is determined whether or not the reading process and the writing process by the remote copy conflict. Only log blocks determined to have no contention by determination are applied to the DB.

  (2) In the method of rereading the log, when applying the log at the secondary site, the log block is read from the secondary storage and the consistency is verified. Regarding the log blocks other than the last one among the read log blocks, it is determined that the read processing and the write processing by remote copy do not conflict. The log block except the last log block is applied after reloading. This makes it possible to apply the log while confirming whether the reading has been performed correctly, and restore the DB by applying the log independently at the secondary site without performing communication or processing for specifying the log to be read from the primary site. be able to.

  (3) In the method of reading linked with remote copy, the second copy is interrupted when log application is performed at the secondary site. Read a log block from the second volume. Apply the read log block. When there is no more log that can be read, the second copy is resumed after the log application process is interrupted. As a result, when the log is read, the second copy is suspended, thereby avoiding contention between log reading and remote copy writing, and performing communication and processing to specify the log to be read from the primary site. The DB can be recovered by applying the log independently at the secondary site.

  Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

  (1) When logs are transferred synchronously, it can be guaranteed that there is no loss. In addition, the use of remote copy allows transfer without consuming server resources, so the impact on the online performance of the primary site is small.

  (2) Since it is not necessary to transfer a DB file with a large update amount, it can be realized even with a narrow bandwidth line, and the line cost can be reduced.

  (3) Since the application is performed in units smaller than the file, the service can be restarted quickly even at the time of switching.

  (4) In order to maintain the online performance of the primary site, even if the log IO unit is large, it is possible to prevent the DB destruction due to unauthorized reading by the reread processing / remote copy cooperation processing. Therefore, it is possible to cope with a configuration in which the secondary site is several hundred km or more away in consideration of a wide area disaster.

  (5) Processing for determining the log reading position at the primary site, or performing log application processing independently only at the log application unit at the secondary site without newly adding communication, and recovering the DB Is possible.

It is a figure which shows an example of a structure of DR system in Embodiment 1 of this invention. In Embodiment 1 of this invention, it is a figure which shows an example of the structure of a log file. In Embodiment 1 of this invention, it is a figure which shows an example of the read / application schedule of a log block. In Embodiment 1 of this invention, it is a figure which shows an example of the flow of a log reading and application process (normal time). In Embodiment 1 of this invention, it is a figure which shows an example of the flow of a log reading and application process (at the time of switching). In Embodiment 1 of this invention, it is a figure which shows an example of the flow of a log reading and application process (normal time, with SZ determination). It is a figure which shows an example of a structure of DR system in Embodiment 2 of this invention. In Embodiment 2 of this invention, it is a figure which shows an example of the structure of the data stored with JNL VOL. In Embodiment 2 of this invention, it is a figure which shows an example of the flow of a log reading and application process (normal time, fixed time passage). In Embodiment 2 of this invention, it is a figure which shows an example of the flow of a log reading and application process (normal time, update amount excess). In Embodiment 2 of this invention, it is a figure which shows an example of the flow of a log reading and application process (at the time of switching). FIG. 10 is a diagram showing an example of a flow of secondary storage copy processing (remote copy) in Embodiment 2 of the present invention. In Embodiment 2 of this invention, it is a figure which shows an example of the flow of a copy process (reflection process from JNL VOL) of a secondary storage. It is a figure which shows an example of a structure of DR system in Embodiment 3 of this invention. It is a figure which shows an example of the structure of the system which applied the conventional system 1 with respect to this invention. It is a figure which shows an example of the structure of the system to which the conventional system 2 is applied with respect to this invention. It is a figure explaining an example when the log reading cannot be normally performed in the system to which the conventional method 1 is applied to the present invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

(Embodiment 1)
A DR system according to Embodiment 1 of the present invention will be described with reference to FIGS.

  First, an example of the configuration of the DR system in the present embodiment will be described with reference to FIG. FIG. 1 is a diagram illustrating an example of the configuration of a DR system.

  The DR system according to the present embodiment applies a method of rereading a log, and includes a primary site and a secondary site. The primary site includes a server 100 that is a computer on which a DBMS operates, and a storage 120 that stores the DBMS log file and the DB file. The secondary site includes a server 110 and a storage 130, each of which includes a secondary DBMS that performs log application processing or a computer that operates a function specialized for log application (log application function). The primary site storage 120 and the secondary site storage 130 are connected through a network 150.

  At the primary site, the server 100 operates a DBMS 101, and the DBMS 101 is provided with a DB buffer 102, a log buffer 103, a DB access control unit 104, and a log management unit 105. The storage 120 at the primary site is provided with a storage control processing unit 121, a cache 126, a disk access control unit 127, a log VOL (Log) 128, and a DB VOL (DB) 129. The storage control processing unit 121 includes a command processing unit 122, a copy processing control unit 123, and a remote copy processing unit 124.

  In the secondary site, the log application unit 111 operates in the server 110. The log application unit 111 includes a DB buffer 112, a log buffer 113, a log application control unit 114, a log reading consistency verification unit 115, and an application unit 116. Is provided. The storage 130 at the secondary site includes a storage control processing unit 131, a cache 136, a disk access control unit 137, a log VOL (Log) 138, and a DB VOL (DB) 139. The storage control processing unit 131 includes a command processing unit 132, a copy processing control unit 133, and a remote copy processing unit 134.

  The DBMS 101 operates in the server 100 at the primary site. The DBMS 101 refers to or updates data stored in the DB VOL 129 in the storage 120 in accordance with an instruction from the UAP (user application). When updating the DB VOL 129, the DBMS 101 first stores the update difference as a log in the log VOL 128 in the storage 120. The DBMS 101 includes a log management unit 105 and a DB access control unit 104, and each accesses data in the storage 120 via the DB buffer 102 and the log buffer 103.

  The primary site storage 120 has a remote copy function. Similarly, the storage 130 at the secondary site also has a remote copy function and will be described in parentheses. When there is an IO request from the server 100 (110), the command processing unit 122 (132) accepts the request. If the request is a write request, if there is data on the cache 126 (136), the data is updated on the cache 126 (136). If the data is not in the cache 126 (136), the disk access control unit 127 (137) is requested for the corresponding data, and is copied from the disk constituting the VOL to the cache 126 (136). The written data is asynchronously written back to the disk by the disk access control unit 127 (137).

  Here, when writing to the VOL that is the target of remote copying is performed, following the writing to the cache 126 (136), the remote copy processing unit 124 (134) handles the storage 120 at the secondary site. It is assumed that data is also written to the area (cache 136). Further, it is assumed that remote copy status control such as copy start / stop (disconnect) / interruption can be performed by giving an instruction to the copy processing control unit 123 (133). In this embodiment, it is assumed that the log VOL 128 (138) of the storage 120 (130) at the primary / secondary site is the target of remote copy.

  The log application unit 111 operates in the server 110 at the secondary site. The log application unit 111 reads the log VOL 138 transferred by remote copy, and updates the data included in the DB VOL 139. The log reading consistency verification unit 115 reads a log from the log VOL 138 and verifies the consistency of the read log. The log application unit 111 applies the read log and updates data on the DB VOL 139. The log application control unit 114 recovers the DB by controlling the log reading consistency verification unit 115 and the application unit 116. Note that the log application unit 111 also accesses data on the VOL via the DB buffer 112 and the log buffer 113 in the same manner as the DBMS 101.

  In the DR system according to the present embodiment, when the log application function is used instead of the secondary DBMS to perform log application, the secondary DBMS that continues the service after switching may operate on the server at the secondary site. However, it may operate on another server. Hereinafter, a case where the log application function is used will be described. The storage 120 at the primary site and the storage 130 at the secondary site are connected by the inter-storage network 150, and only the log file is transferred by remote copy.

  The log application function of the secondary site directly reads and applies the log file 201 existing on the log VOL 200 transferred by remote copy as shown in FIG. FIG. 2 is a diagram illustrating an example of the structure of a log file.

  The log file 201 is read and written in units of blocks in which log records 203 are bundled. That is, the primary site DBMS writes to the log file in block units, while the log application function reads in block units. The log block 202 is provided with a header 204 at the beginning and a trailer 205 at the end, and the consistency of the entire block can be verified by the magic word included in each.

  However, as described above, when the size of the log block 202 is large and the log application catches up with the log write of the primary site, this write header is used when the remote copy write and the log apply function read conflict. / Because consistency cannot be guaranteed only by consistency verification by a trailer, reading and application are performed according to a schedule as shown in FIG. FIG. 3 is a diagram illustrating an example of a log block reading / application schedule.

  That is, when reading / applying a certain log block (block (i)) (300), in order to ensure that reading and writing do not conflict with the block (block (i)), It is first checked whether the log lock (block (i + 1)) can be read (301). If the next block (block (i + 1)) can be read, the previous log block (block (i)) is re-read and applied (302). Since logs are added sequentially, if a log block (block (i + 1)) is written, it can be determined that the writing of the log block (block (i)) has been completed normally, and log block consistency It becomes possible to guarantee the sex.

  Next, an example of the flow of the log reading / applying process in the DR system of the present embodiment will be described with reference to FIGS. FIG. 4 is a diagram illustrating an example of a flow during normal operation, FIG. 5 is a diagram during switching, and FIG. 6 is a diagram illustrating an example of a flow during normal operation (with SZ (size) determination).

  In this embodiment, the blocks are read one by one, but a plurality of blocks may be read at a time. When a plurality of blocks are read, the blocks before the last block are applied, applied after rereading.

  In FIG. 4, in the log reading / applying process (normal time), the log reading position is first determined (S401). Here, the DBMS outputs the serial number (LSN) of the log that has been applied and the internal information such as the log file and DB file used at that time to the DBMS status file at the timing of the checkpoint or the like.

  In the log reading position determination, the LSN and the log file being used are read from the DBMS status file, and the block to be read first is determined (S402). Here, reading is started from the block indicated by the pointer (ptr).

  After determining the reading position, it is determined whether or not there is a FO / stop instruction from the administrator or application (S403). If there is a FO / stop instruction (Y), the process proceeds to stop / FO processing. When there is no FO / stop instruction (N), the log reading / applying process is repeated until the FO / stop instruction is issued.

  First, a block indicated by ptr (hereinafter referred to as a block (ptr)) is read (S404), and then the consistency of the block (ptr) is verified by the header and trailer. Here, it is determined whether or not the block (ptr) is consistent (S405). If it is not consistent (N), the process returns to S1, and if it is consistent (Y), that is, if it is correctly read. Shifts to S2.

  Then, it is determined again whether there is an FO / stop instruction (S406). If there is an FO / stop instruction (Y), the process proceeds to stop / FO processing, and if there is no FO / stop instruction (N). Reads the next block (ptr + 1) and performs consistency verification. First, the next block (ptr + 1) is read (S407), and then it is determined whether or not the block (ptr + 1) is consistent (S408). (Y), that is, if consistency is verified, the block (ptr) is re-read and applied (S409, S410), the ptr is advanced by 1 (S411), and the process returns to S2. .

  Thereafter, the block pointed to by ptr + 1 is read and verified. If there is no problem, the block pointed to by ptr is reread and applied.

  In FIG. 5, processing when an FO / stop instruction is received from the administrator will be described.

  In this log reading / applying process (at the time of switching), it is first determined whether it is a stop instruction or a FO instruction (S501). If it is a stop instruction (stop), ptr information is used as log application progress information in the DB state. Writing to the file ends the processing (S502). On the other hand, if it is an FO instruction (FO), remote copy status control is performed first (S503). For example, if it is a FO at the time of a disaster, the remote copy is set in a disconnected state, and subsequent writing from the primary site is suppressed. On the other hand, in the case of a planned FO, the copy direction is set in the reverse direction.

  Next, block (ptr) reading and consistency verification are performed, and thereafter, log reading and application processing are repeated until it is determined to be the end. That is, the application is performed after reading the block (ptf) (S504, S505), and it is determined whether it is the end (S506). Note that here, after remote copy status control is implemented, there is no conflict between remote copy and reading, so log re-reading processing is not necessary.

  If it is not the end (N), ptr is advanced by 1 (S507), and the process returns to S3. If it is determined that the end is reached (Y), that is, if there is no block to be read, an undecided transaction cancel process (undo process) ) Is carried out (S508). Here, when only the settlement transaction is applied in the log application process, the cancel process is not necessary. Subsequently, it is written in the state file that the DB file is in a consistent state (S509), the secondary DBMS is activated (S510), and the process is terminated.

  In FIG. 6, processing when there is an SZ determination at normal times will be described. If a block is smaller than the cache management size and written in batches, it will not be read in a blank state. Therefore, in this process, rereading is performed only when the block size is larger than the cache management size. This log reading / applying process (normally, with SZ determination) is an example in which the SZ determination process is added to the process of FIG. 4, and the added portion will be mainly described here.

  First, as in FIG. 4, log reading position determination processing (S601), block (ptr) log reading position determination (S602), whether or not there is a FO / stop instruction (S603), block After reading (ptr) (S604) and determining whether the block (ptr) is consistent (S605), if there is consistency (Y), the size of the block (ptr) is It is determined whether or not it is larger than the cache management size SZ (S606). If the size of the block (ptr) is larger than SZ (Y), the process proceeds to S2, and if not (N), the block (ptr) is applied (S607), and ptr is advanced by 1 (S608). Return to S1.

  When the process proceeds to S2, as in FIG. 4, it is determined whether there is an FO / stop instruction (S609), the reading of the block (ptr + 1) (S610), and whether the block (ptr + 1) is consistent or not. After performing the determination (S611) and rereading and applying the block (ptr) (S612, S613), it is determined whether or not the size of the next block (ptr + 1) is larger than the cache management size SZ (S614). When the size of the block (ptr + 1) is larger than SZ (Y), ptr is advanced by 1 (S615), and the process returns to S2, and when not larger (N), the block (ptr + 1) is applied (S616), Advance ptr by two (S617) and return to S1.

  As described above, according to the DR system of the present embodiment, the following effects can be obtained.

  (1) When a method for rereading a log is applied and logs are transferred synchronously, it is possible to ensure that there is no loss. Further, by using remote copy, transfer can be performed without consuming server resources, so that the influence on the online performance of the primary site can be reduced.

  (2) By applying a method of re-reading the log, it is not necessary to transfer a DB file with a large amount of update, so that it can be realized even with a narrow bandwidth line, so that the line cost can be reduced.

  (3) Since the application is performed in units of blocks smaller than the file, the service can be restarted quickly even at the time of switching.

  (4) Restore the DB by performing log application processing independently at the secondary site's log application unit without newly adding communication to the primary site, or processing for determining the log reading position. Is possible.

(Embodiment 2)
A DR system according to the second embodiment of the present invention will be described with reference to FIGS.

  First, an example of the configuration of the DR system in the present embodiment will be described with reference to FIG. FIG. 7 is a diagram illustrating an example of the configuration of the DR system.

  The DR system of the present embodiment applies a method for performing reading in cooperation with remote copy. For example, illegal reading is performed when read / write conflicts. Therefore, as in this embodiment, in the method of performing read in cooperation with remote copy, when the log application function performs read, write / write conflict is avoided by preventing the write by remote copy from occurring. .

  The DR system according to the present embodiment is different from the first embodiment in that a pull type copy processing unit 125 is added to the storage 120 at the primary site, and a pull type copy processing unit 135 and a JNL VOL ( JNL) 140 is added.

  A JNL VOL 140 as shown in FIG. 8 is arranged in the storage 130 of the secondary site. FIG. 8 is a diagram illustrating an example of the structure of data stored in the JNL VOL. The JNL VOL 140 stores metadata 800 801,..., Data 802, metadata 803 including data 800, sequence No., reflection destination address and size, and pointer 1 (hptr) 804 stores the sequence No. of the metadata 801. Pointer 2 (tptr) 805 points to the sequence NO of metadata 803.

  By disposing the JNL VOL 140 in the secondary site storage 130, the information of the primary site log VOL 128 is transmitted to the log VOL 138 of the secondary site storage 130 in a two-stage copy. That is, the first copy is copied from the log VOL 128 at the primary site to the JNL VOL 140 at the secondary site. At this time, the JNL VOL 140 is appended with information such as a serial number and a time stamp added to the data. Copying from the JNL VOL 140 to the log VOL 138 (Pull type copying) is performed asynchronously.

  In the present embodiment, the control program for the storage 130 at the secondary site has an interface for controlling (suspending / resuming) copying from the JNL VOL 140. When the log application function attempts to read the log, it first places the Pull type copy in a stopped state. As a result, since writing to the log VOL 138 can be suppressed, the log can be read / applied by a normal procedure (without re-reading). When reading of the block fails, the Pull type copy is resumed and the new information is reflected in the log VOL 138. After a certain period of time or when the copy amount of the Pull type copy exceeds a certain threshold value, the Pull type copy is stopped again, and log reading / application is resumed.

  Next, an example of the flow of the log reading / applying process in the DR system of the present embodiment will be described with reference to FIGS. FIG. 9 is a diagram illustrating an example of a flow during normal switching (elapsed time), FIG. 10 is a diagram during normal operation (exceeding update amount), and FIG.

  In the description of FIG. 9, the difference from the log reading / applying process shown in FIG. 4 of the first embodiment will be mainly described.

  In this log reading / applying process (normal time, a fixed time has elapsed), first, the Pull type copy is started (S901). Then, as in the case of performing re-reading, the log-reading position determination process (S902) and the block (ptr) log-reading position determination (S903) are performed, and then the Pull-type copy is interrupted (S904). To S11. After the pull-type copy is interrupted, it is repeatedly applied as long as the log is successfully read (as long as the header / trailer verification is successful).

  When the process proceeds to S11, it is determined whether or not there is an FO / stop instruction (S905), the block (ptr) is read (S906), and whether or not the block (ptr) is consistent (S907). If there is no consistency (N), that is, if the reading has failed and the part that has been reflected so far has been read and applied, the Pull type copy is changed to the resumed state (S908). Subsequently, when a certain amount of time has passed or the amount of reflection of the Pull type copy exceeds a certain amount, the Pull type remote copy is again suspended, and the log reading / applying process is executed.

  That is, after restarting the Pull type copy, the sleep is performed for the time Δt (S909), and the process returns to S10. If there is consistency (Y), it is determined whether the block (ptr-1) is not applied ( S910). As a result of this determination, if not applied (N), ptr is advanced by 1 (S911), and the process returns to S11. If not applied (Y), the block (ptr-1) is applied (S912). ), Ptr is advanced by 1 (S913), and the process returns to S11.

  In FIG. 10, in the log reading / applying process (normal, update amount exceeded), first, the same process as in FIG. 9 is performed (S1001 to S1007, S1013 to S1016). If there is no consistency (N), the time T is set to 0 (S1008), and the process proceeds to S12. When the process proceeds to S12, the storage is inquired about the update amount (S1009), and it is determined whether the update amount is larger than a predetermined constant P or whether the time T has passed the predetermined time T1 (S1010).

  As a result of this determination, if the update amount exceeds a constant or the time has elapsed (Y), the Pull-type copy is resumed (S1011), the process returns to S10, and otherwise (N) Sleeps for T2 (S1012) and returns to S12. Regarding time T2, in order to prevent the number of inquiries to the storage from becoming excessive, the second and subsequent inquiries are made after T2 (<T1) time has elapsed.

  In FIG. 11, processing when an FO / stop instruction is received from the administrator will be described.

  In this log reading / applying process (at the time of switching), it is first determined whether it is a stop instruction or a FO instruction (S1101). If it is a stop instruction (stop), ptr information is used as the log application progress information in the DB state. Writing to a file ends the process (S1102). On the other hand, if it is a FO instruction (FO), the remote copy state is set to the disconnected state if it is a disaster FO, and the suspended state is set if it is a planned FO. That is, first, remote copy status control (during split) is performed (S1103).

  Subsequently, log application processing is performed. First, the Pull type copy is stopped (S1104), the block (ptr)) is read (S1105), it is determined whether or not there is consistency (S1106), and the application process is repeated as long as there is consistency. That is, it is determined whether or not the block (ptr-1) is not applied (S1107). If it is not applied (N), ptr is advanced by 1 (S1108), and the process returns to S13. If not applied (Y) Is applied with the block (ptr-1) (S1109), advances ptr by one (S1110), and returns to S13.

  On the other hand, if there is no consistency (N), it is first determined whether there is data to be reflected in the JNL VOL (S1111). If data to be reflected still remains (Y), the Pull type copy is resumed (S1112), sleeps by Δt (S1113), returns to S12, and the log application process is repeated. If there is no more data to be reflected (N), it is confirmed that the log has been applied to the end (S1114). Here, in the case of the planned FO, the reverse remote copy setting is performed.

  Then, after execution of remote copy state control (at the time of takeover) (S1115), an undecided transaction cancellation process is executed (S1116). Note that this processing is not required when only the settlement transaction is applied in the log application processing. When all transactions are settled, information is written to the DBMS state file (S1117), then the secondary DBMS is activated (S1118), and the process is terminated.

  Here, the blocks are read one by one, but a plurality of blocks may be read at a time. When a plurality of blocks are read, the block before the last block is applied as an application target.

  Next, an example of the flow of the secondary storage copy process in the DR system of the present embodiment will be described with reference to FIGS. FIG. 12 is a diagram illustrating an example of a flow of reflection processing from the remote copy, and FIG. 13 is a diagram illustrating a flow of reflection processing from the JNL VOL.

  In FIG. 12, in the secondary storage copy process (remote copy), first, pointer 1 (hptr) and pointer 2 (tptr) are initialized (S1201), reflection process is started (S1202), and the process proceeds to S1. . Then, it is determined whether there is a transfer from the primary storage (S1203). If there is no transfer (N), the process returns to S1, and if there is a transfer (Y), it is determined whether additional writing is possible (S1204). ). If the result of this determination is that it is not possible (N), error processing / warning processing is performed (S1205). If possible, metadata and data are registered (S1206), tptr is updated (S1207), Return to S1.

  In FIG. 13, in the secondary storage copy process (reflection process from the JNL VOL), first, it is determined whether there is an interruption instruction through S1 (S1301), and if there is no interruption instruction (N), S2 If there is (Y), it is subsequently determined whether or not there is a restart instruction (S1302). As a result of this determination, if there is no restart instruction (N), the process returns to S1, and if there is (Y), the process proceeds to S2. After shifting to S2, the data pointed to by the pointer 1 (hptr) from the JNL VOL is reflected in the updated VOL (S1303), hptr is updated (S1304), and the process returns to S1.

  As described above, according to the DR system of the present embodiment, the same effects (1) to (4) as in the first embodiment can be obtained, and a method of reading in cooperation with remote copy is applied. Thus, even when the log IO unit is large, it is possible to prevent DB destruction due to unauthorized reading by the reread processing / remote copy cooperation processing. Therefore, it is possible to cope with a configuration in which the secondary site is several hundred km or more away in consideration of a wide area disaster.

(Embodiment 3)
A DR system according to Embodiment 3 of the present invention will be described with reference to FIG.

  An example of the configuration of the DR system in the present embodiment will be described with reference to FIG. FIG. 14 is a diagram illustrating an example of the configuration of the DR system.

  The DR system of the present embodiment includes a primary site, a secondary site, and a relay site that relays between the primary site and the secondary site. The primary site server 100 and storage 120 and the secondary site server 110 and storage 130 are the same as those in FIG. 1 of the first embodiment or FIG. 7 of the second embodiment. The relay site includes a storage 1300, and is provided with a storage control processing unit 1301, a log VOL 1302, and a JNL VOL 1303.

  A network 1304 is connected between the storage 120 at the primary site and the storage 1300 at the relay site, and between the storage 1300 at the relay site and the storage 130 at the secondary site. A remote copy 1305 as the first copy is performed from the log VOL 128 in the storage 120 at the primary site to the log VOL 1302 in the storage 1300 at the relay site, and the log VOL 138 in the storage 130 at the secondary site and the relay VOL A remote copy 1306 that is a second copy is performed with the JNL VOL 1303 in the storage 1300.

  Also in the DR system of the present embodiment, the same effects as those of the first and second embodiments can be obtained.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  The present invention relates to DR technology based on log transfer, and in particular, reads and applies logs with a finer granularity than files, and cooperates with log re-reading or remote copying during log reading and application processing. It is effective when applied to DR technology for reading.

  DESCRIPTION OF SYMBOLS 100 ... Server, 101 ... DBMS, 102 ... DB buffer, 103 ... Log buffer, 104 ... DB access control part, 105 ... Log management part, 110 ... Server, 111 ... Log application part, 112 ... DB buffer, 113 ... Log buffer , 114 ... log application control unit, 115 ... log read consistency verification unit, 116 ... application unit, 120 ... storage, 121 ... storage control processing unit, 122 ... command processing unit, 123 ... copy processing control unit, 124 ... remote copy Processing unit 125... Pull-type copy processing unit 126... Cache 127 Reference disk access control unit 128 Log VOL 129 DB VOL 130 Storage 131 131 Storage control unit 132 Command processing unit 133: Copy processing control unit, 134: Remote copy processing unit 135 ... Pull type copy processing unit, 136 ... Cache, 137 ... Disk access control unit, 138 ... Log VOL, 139 ... DB VOL, 140 ... JNL VOL, 150 ... Network, 200 ... Log VOL, 201 ... Log file 202 ... log block, 203 ... log record, 204 ... header, 205 ... trailer, 800 ... data, 801 ... metadata, 802 ... data, 803 ... metadata, 804 ... pointer 1 (hptr), 805 ... pointer 2 ( tptr), 1300 ... storage, 1301 ... storage control processing unit, 1302 ... log VOL, 1303 ... JNL VOL, 1304 ... network, 1305 ... remote copy, 1306 ... remote copy, 1400 ... DBMS, 1401 ... VOL for archive log, 402: Network, 1403 ... Remote copy, 1404 ... Transfer between servers, 1405 ... Read log, 1406 ... Log application, 1407 ... Archive, 1411 ... VOL for archive log, 1500 ... Log block, 1501 ... Write (1) area, 1502 Read (1) area, 1503 ... Write (2) area, 1504 ... Read (2) area, 1505 ... Log block read by the log application unit, 1600 ... Archive.

Claims (9)

A database management method in a storage system for copying data from a primary site database processing system to a secondary site,
The primary site includes a first computer on which a database processing system operates, a primary storage including a volume for recording a database and a volume for recording a log that is an update history of the database,
The secondary site includes a program for performing log application processing, a second computer on which the program operates, a secondary storage including a volume for recording a database and a volume for recording a log,
The primary site and the secondary site are connected by a network,
The primary storage and the secondary storage have a remote copy function,
In the log application process of transferring the log by remote copy of the primary storage at the primary site and applying the transferred log to the database of the secondary storage at the secondary site,
When writing in log block units consisting of a plurality of log records at the primary site and applying logs at the secondary site,
The secondary storage has a first volume and a second volume with respect to one transfer source volume of the primary storage,
The log written in the primary storage is appended to the first volume in the secondary storage in the update order by the first copy representing the remote copy, and the copy to the second volume is added to the first volume. Reflected in the second copy at a different timing from writing,
When applying logs at the secondary site,
Interrupting the second copy;
Reading a log block from the second volume;
Applying the read log block;
And a step of resuming the second copy after the log application process is interrupted when there is no log that can be read. The database management method according to claim 1,
When resuming the suspended second copy, the second copy is resumed after a predetermined time has elapsed. The database management method according to claim 1,
When resuming the interrupted second copy, the first volume is queried for information about writing added after the interruption of the second copy, and the amount of writing exceeds a predetermined constant value. A database management method, wherein the second copy is resumed. The database management method according to claim 1,
When receiving a switching instruction from an administrator or an application, the method includes first changing the state of the first copy representing the remote copy so that no new writing occurs,
After changing the state of the first copy, there are a step of interrupting the second copy, a step of reading and applying the log, and a step of inquiring whether there is an update to be reflected in the first volume. Have
If there is an update to be reflected, resuming the second copy, reading the log and applying,
If there is no update to be reflected, the method includes a step of canceling an undecided transaction after applying all readable logs,
A database management method, wherein the database is brought into a transaction consistent state. A storage system for copying data from a primary site database processing system to a secondary site,
The primary site has a first computer in which a database processing system operates, a first storage including a volume for recording a database and a volume for recording a log that is an update history of the database,
The secondary site includes a program that performs log application processing, a second computer that operates the program, a volume that records a database, and a second storage that includes a volume that records a log,
The primary site and the secondary site are connected by a network,
The first and second storages have a remote copy function, and a log recorded in the first storage is transferred to the second storage by a remote copy function,
The second storage at the transfer destination has a first volume and a second volume with respect to one of the volumes to be transferred in the first storage, and the second storage from the first storage The transfer is appended to the first volume, and the second copy from the first volume to the second volume is performed at a timing different from the remote copy that is the first copy,
In the log application process at the secondary site, the log is read from the second volume, and when the log is read, the second copy is suspended and then the log is read and applied, and the application of the read log is completed. Then, the storage system is set to resume the second copy. A database management method in a storage system for copying data from a primary site database processing system to a secondary site,
The primary site has a first computer in which a database processing system operates, a first storage including a volume for recording a database and a volume for recording a log that is an update history of the database,
The secondary site includes a program that performs log application processing, a second computer that operates the program, a volume that records a database, and a second storage that includes a volume that records a log,
The primary site and the secondary site are connected by a network,
In the process of reflecting the update applied to the first storage in the second storage,
The second storage at the transfer destination has a first volume and a second volume with respect to one of the volumes to be transferred in the first storage, and the second storage from the first storage The transfer is appended to the first volume, and the second copy from the first volume to the second volume is performed at a timing different from the remote copy,
A database management method, wherein an execution state of the second copy can be controlled from a user or an application, and the second copy is suspended / resumed from the user or an application. The database management method according to claim 6, wherein
A database management method comprising: inquiring an update amount transferred to the first volume after placing the second copy in a suspended state when the second copy is in a suspended state. A storage system for copying data from a primary site database processing system to a secondary site,
The primary site has a first computer in which a database processing system operates, a first storage including a volume for recording a database and a volume for recording a log that is an update history of the database,
The secondary site includes a program that performs log application processing, a second computer that operates the program, a volume that records a database, and a second storage that includes a volume that records a log,
The primary site and the secondary site are connected by a network,
In the process of reflecting the update applied to the first storage in the second storage,
The second storage at the transfer destination has a first volume and a second volume with respect to one of the volumes to be transferred in the first storage, and the second storage from the first storage The transfer is appended to the first volume, and the second copy from the first volume to the second volume is performed at a timing different from the remote copy,
A storage system comprising an interface for enabling the execution status of the second copy to be controlled by a user or application, and suspending / resuming the second copy from the user or application. The storage system according to claim 8, wherein
When the second copy is suspended, the storage system has an interface for inquiring about an update amount transferred to the first volume after the second copy is suspended.

Images