Redundancy system, redundancy method, and redundancy program

Abstract

A redundancy system (1) has an active CS separation DB (10A) and a spare CS separation DB (10B). The active CS separation DB (10A) and the spare CS separation DB (10B) each have, in a computation layer, a query processing unit (11) that uses calculation resources while being active, and, in a storage layer, a storage unit (15) that stores data and a transmission / reception unit (14) that performs transmission and reception of the data in the storage unit (15). In the storage layer of the active CS separation DB (10A), the transmission / reception unit (14A) transmits the data in the storage unit (15A) to the spare CS separation DB (10B) at a predetermined timing. When the spare CS separation DB (10B) is in standby and the computation layer is stopped, the transmission / reception unit (14B) receives the transmitted data and causes the received data to be stored in the storage unit (15B).

Description

Redundancy system, redundancy method, and redundancy program

[0001] The present invention relates to a redundancy system, a redundancy method, and a redundancy program.

[0002] Conventionally, for the purpose of disaster recovery (DR), etc., redundancy techniques such as cold standby, hot standby, and pilot light (see Non-Patent Document 1) that use primary and standby servers or clouds have been known.

[0003] In cold standby, components on the standby are stopped, and primary data is backed up at specified times such as daily, weekly, or monthly, and copied to the standby. When a failure occurs in the primary, components such as application servers and databases required to provide the system are started on the standby, the database is restored based on the backup data, and a failover is performed.

[0004] In hot standby, the same components as on the primary system are normally run on the standby system, and the database replication function is used to synchronize data between the primary and standby systems, maintaining an identical system between the primary and standby systems. When a failure occurs on the primary system, the components running on the standby system are used as is, and a failover is performed.

[0005] In pilot light, only the database runs in the standby region, and the database replication function is used to synchronize data between the primary and standby. If a failure occurs in the primary, the application server is started in the standby and a failover is performed by connecting to the database that has been running normally.

[0006] “AWS Disaster Recovery (DR) Architecture, Part III: Pilot Light and Warm Standby,” [online], December 2021, Amazon Web Services, [Retrieved December 18, 2023], Internet <URL:https: / / aws.amazon.com / jp / blogs / news / disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby / >

[0007] However, with conventional technology, there is a trade-off between availability and running costs, making it difficult to achieve redundancy while preventing a decrease in availability and running costs. For example, with cold standby, the database is stopped, which reduces running costs, but at the expense of reduced availability in terms of recovery point objective (RPO) and recovery time objective (RTO). With hot standby, continuous replication is performed using a standby database, achieving a high RPO and improving availability, but at the expense of higher running costs. Furthermore, with pilot light, running costs are reduced compared to hot standby, while availability is prevented from decreasing, but the effect of reducing running costs is limited.

[0008] The present invention has been made in view of the above, and has an object to enable redundancy while suppressing a decrease in availability and running costs.

[0009] In order to solve the above-mentioned problems and achieve the object, the redundancy system of the present invention is a redundancy system having an operating database and a spare database, wherein the operating database and the spare database each have, in a compute layer, a calculation unit that uses computational resources during operation, and in a storage layer, a memory unit that stores data and a transceiver unit that transmits and receives data from the memory unit, wherein, in the storage layer of the operating database, the transceiver unit transmits data from the memory unit of the operating database to the spare database at a predetermined timing, and when the spare database is in standby mode and the compute layer is stopped, in the storage layer of the spare database, the transceiver unit receives the transmitted data and stores it in the memory unit of the spare database.

[0010] According to the present invention, redundancy can be achieved while suppressing a decrease in availability and running costs.

[0011] FIG. 1 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 2 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 3 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 4 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 5 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 6 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 7 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 8 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 9 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 10 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 11 is a diagram for explaining an overview of the redundancy system of this embodiment. FIG. 12 is a schematic diagram illustrating a general configuration of the redundancy system of this embodiment. FIG. 13 is a diagram for explaining redundancy processing. FIG. 14 is a diagram for explaining redundancy processing. FIG. 15 is a diagram for explaining redundancy processing. FIG. 16 is a diagram for explaining redundancy processing. FIG. 17 is a diagram for explaining redundancy processing. Fig. 18 is a sequence diagram showing a redundancy processing procedure. Fig. 19 is a sequence diagram showing a redundancy processing procedure. Fig. 20 is a diagram for explaining an embodiment of a redundancy system. Fig. 21 is a diagram for explaining an embodiment of a redundancy system. Fig. 22 is a diagram for explaining an embodiment of a redundancy system. Fig. 23 is a diagram showing an example of a computer that executes a redundancy program.

[0012] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are designated by the same reference numerals.

[0013] [Overview of Redundancy Device] FIGS. 1 to 11 are diagrams for explaining an overview of the redundancy system of this embodiment. In the case of redundancy with a primary server / cloud and a standby server / cloud, under normal circumstances, as illustrated in FIG. 1, the primary server / cloud operates and transfers data to the standby. Furthermore, if a failure occurs in the primary, as illustrated in FIG. 2, a switch to the standby, i.e., a failover, is initiated. Then, as illustrated in FIG. 3, components are started in the standby and data is restored. This completes the failover and the switch to the standby, as illustrated in FIG. 4.

[0014] In this case, the availability of the redundant system is represented by three time indicators: the failover time and performance recovery time shown in FIG. 5(a), and the data lost time shown in FIG. 5(b). The failover time is the time from the start of failover to its completion. The performance recovery time is the time from the completion of failover until a certain level of performance is achieved. The data lost time indicates how far back data is rewound when failover is completed, and in the example shown in FIG. 5(b), it is 9 hours. The sum of the failover time and performance recovery time shown in FIG. 5(a) affects the achievement of RTO (Recovery Time Objective), and the data lost time shown in FIG. 5(b) affects RPO (Recovery Point Objective).

[0015] In cold standby, as shown in FIG. 6A, normal standby is stopped, and only data backups are taken periodically, such as daily. This lengthens the time it takes for the system to start up and perform (failover time, performance recovery time). While it is possible to reduce resource consumption and costs, it also lengthens the backup interval and the time it takes for data to be lost. In other words, all three time indicators are lengthened, reducing availability while also reducing costs. Thus, cold standby reduces the likelihood of a failure because many components are stopped to reduce running costs.

[0016] In contrast, in the hot standby configuration shown in Figure 6(b), all standby servers are started and synchronized with the same performance as the primary server even under normal circumstances. As a result, the time it takes to start up and demonstrate performance (failover time, performance recovery time) is short. On the other hand, because constant synchronization is performed to prevent data loss, data loss and time are reduced, but running costs due to resource consumption increase. In other words, all three time indicators are shortened, improving availability, but resource consumption is high and costs are high. In this way, with hot standby, running costs increase because the database is started to increase availability.

[0017] As described above, conventionally, a database cannot be partially stopped in order to retain data, and the entire database must be either started or stopped, resulting in a trade-off between availability and cost.

[0018] Therefore, in the redundant system of this embodiment, as illustrated in FIG. 7 , a loosely coupled architecture DB (hereinafter also referred to as a CS-separated DB) is applied to the DB portion, in which the DB portion is separated into a compute layer and a storage layer. The compute layer is a component that performs processing that requires computational resources, such as query analysis, and the storage layer is a group of components that perform processing necessary for data persistence. In the loosely coupled architecture DB illustrated in FIG. 7 , the compute layer and the storage layer have the flexibility to be able to scale independently. Furthermore, since there is no need to persistently store data other than in the storage unit, startup and shutdown are flexible, and it is possible to stop part of the DB.

[0019] In the redundant system of this embodiment, as illustrated in FIG. 8, the scalability of the loosely coupled architecture DB allows some of the DBs waiting on standby on the standby server / cloud to be stopped to reduce costs, thereby achieving high availability close to that of hot standby with low running costs close to that of cold standby.

[0020] Specifically, during normal operation, as shown in Figure 9, the standby server / cloud starts only a portion of the loosely coupled architecture database, and the minimum necessary persistence data is constantly transferred from the primary. This reduces resource consumption and running costs compared to when the entire database is started. Continuous transfer also reduces data loss.

[0021] When a failure occurs in the primary server, components of the loosely coupled architecture database that are not normally running are started and data is restored, as shown in the example of Figure 10. In this way, components that do not have persisted data can be started quickly. This completes the switchover to the standby server / cloud, i.e., failover, as shown in the example of Figure 11. In this way, it is possible to achieve failover that can withstand cloud-scale failures with low resource consumption and low running costs under normal circumstances.

[0022] [Configuration of Redundant System] Fig. 12 is a schematic diagram illustrating the overall configuration of a redundant system of this embodiment. As illustrated in Fig. 12, a redundant system 1 of this embodiment is configured with a primary server / cloud A in operation and a spare standby server / cloud B.

[0023] The primary server / cloud A and the standby server / cloud B are each configured to include a front-end server / application server 20 (20A, 20B) and a CS separated DB 10 (10A, 10B). In other words, the redundant system 1 includes a CS separated DB 10A as an active database and a CS separated DB 10B as a backup database.

[0024] Each device such as a server that constitutes these clouds and the CS separation DB10 has a control unit realized by a CPU (Central Processing Unit), NP (Network Processor), FPGA (Field Programmable Gate Array), etc., and executes processing programs stored in memory.

[0025] For example, while the redundant system 1 is in operation, the front-end server / application server 20 receives requests from the client terminal 30 and presents information to the client terminal 30. That is, the front-end server / application server 20A receives requests from the client terminal 30 and presents information to the client terminal 30. Meanwhile, the operation of the standby front-end server / application server 20B is stopped.

[0026] The CS-separated DB 10 is the loosely coupled architecture DB described above, and is configured to be separable into a compute layer and a storage layer. As illustrated in FIG. 12 , the compute layer corresponds to, for example, the query processing unit 11 (11A, 11B) described later. The storage layer corresponds to, for example, the transaction log processing unit 12 (12A, 12B), the page data creation / persistence processing unit 13 (13A, 13B), the transmission / reception unit 14 (14A, 14B), and the storage unit 15 (15A, 15B) described later.

[0027] While the redundant system 1 is in operation, the CS separated DB 10 performs the redundancy processing described below and transfers data in the storage unit 15A of the primary server / cloud A to the storage unit 15B of the standby server / cloud B to prepare for a failure of the primary server / cloud A. If a failure occurs in the primary server / cloud A, the redundant system 1 quickly starts up the front-end server / application server 20B of the standby server / cloud B and the compute layer of the CS separated DB 10B, and transitions them to operation (failover).

[0028] Specifically, as illustrated in Fig. 12, the control unit of each device constituting the CS separation DB 10 functions as each functional unit such as a query processing unit 11 (11A, 11B), a transaction log processing unit 12 (12A, 12B), a page data creation / persistence processing unit 13 (13A, 13B), a transmission / reception unit 14 (14A, 14B), and a compression / decompression unit 16 (16A, 16B). This allows the redundancy processing described below to be performed. Note that the control unit may also have other functional units.

[0029] The CS separation DB 10 also includes a storage unit 15. The storage unit 15 (15A, 15B) is implemented by a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 15 may be implemented by a network interface card (NIC) or the like, and may communicate with the control unit via a communication control unit (not shown) that controls communication between the control unit and an external device via a telecommunications line such as a local area network (LAN) or the Internet. In this embodiment, the storage unit 15 stores data to be stored.

[0030] This data includes persistent data to be stored persistently and page data that indicates information for managing the storage area of ​​this persistent data. The page data is created by the page data creation / persistence processing unit 13 (13A, 13B) described later in association with the persistent data.

[0031] The query processing unit 11 functions as a calculation unit and performs processing that utilizes calculation resources, such as query analysis, in the compute layer while the CS-separated DB 10 is running. Furthermore, the query processing unit 11 stops processing in the spare CS-separated DB 10B.

[0032] That is, when the primary server / cloud A is normally operating, the query processing unit 11A performs processing, while the query processing unit 11B stops operating. If a failure occurs in the primary server / cloud A, the compute layer of the CS separated DB 10B of the spare standby server / cloud B starts up the query processing unit 11B.

[0033] The transaction log processor 12 functions as a log processor and manages data change histories in the storage layers of the active CS separated DB 10A and the backup CS separated DB 10B. The transaction log processor 12 stops processing in the backup CS separated DB 10B. If a failure occurs in the primary server / cloud A, the storage layer of the CS separated DB 10B in the backup standby server / cloud B starts the transaction log processor 12B.

[0034] That is, while the CS-separated DB 10 is running, the transaction log processor 12 executes a WAL (Write Ahead Logging) service, which writes changes to data in the storage unit 15 before making the changes. The transaction log processor 12 can also be considered a process that utilizes computational resources. That is, while the primary server / cloud A is running under normal circumstances, the transaction log processor 12A performs a log write-ahead process to prepare for the risk of a DB failure. Meanwhile, the transaction log processor 12B of the standby server / cloud B is stopped. Then, if a failure occurs in the primary server / cloud A, the transaction log processor 12B is started in the standby server / cloud B.

[0035] In addition, in the CS separated DB 10B of the spare standby server / cloud B, the transaction log processor 12B does not necessarily have to be stopped.

[0036] The page data creation / persistence processing unit 13 creates data to be permanently stored in the storage unit 15. Specifically, the page data creation / persistence processing unit 13A of the running CS separation DB 10A performs a process of creating persistence data, which is the main data to be stored in the storage unit 15A, as persisted data, and a process of creating page data that indicates information for managing the storage area of ​​the persistence data. The page data creation / persistence processing unit 13A also stores the created persistence data and page data associated with the persistence data in the storage unit 15A.

[0037] Furthermore, as will be described later, if a failure occurs in the operating CS separation DB 10A, the page data creation / persistence processing unit 13B of the backup CS separation DB 10B restores the persistence data of the memory unit 15B based on the page data received from the memory unit 15A.

[0038] In addition, in the CS separated DB 10B of the spare standby server / cloud B, the page data creation / persistence processing unit 13B does not necessarily have to be activated.

[0039] The transmitter / receiver 14 transmits and receives data to and from the memory unit 15. Specifically, in the storage layer of the operating CS separation DB 10A, the transmitter / receiver 14A transmits data from the memory unit 15A of the operating CS separation DB 10A to the backup CS separation DB 10B at a predetermined timing.

[0040] In this case, when the spare CS separation DB 10B is in standby mode and the compute layer is stopped, in the storage layer of the spare CS separation DB 10B, the transmitter / receiver 14B receives the transmitted data and stores it in the memory unit 15B of the spare CS separation DB 10B.

[0041] Specifically, the data to be processed by the transmitter / receiver 14 includes persistent data to be permanently stored and page data indicating information for managing the storage area of ​​the persistent data. The transmitter / receiver 14B then transmits the page data and persistent data to the spare CS separation DB 10B.

[0042] 13 to 17 are diagrams for explaining the redundancy processing. First, as shown in Fig. 13, in an operating primary server / cloud A, the page data creation / persistence processing unit 13A of the CS separated DB 10A performs processing to create persistence data to be stored in the storage unit 15A as persisted data, and processing to create page data indicating information for managing the storage area for the persistence data.

[0043] Then, the page data creation / persistence processing unit 13A stores the persistence data (persistence-processed data) and the page data in the storage unit 15A (S4).Then, the transmitting / receiving unit 14A transfers the persistence data (persistence-processed data) and the page data (metadata) to the CS separation DB 10B of the spare standby server / cloud B (S3).

[0044] In the CS separation DB 10B of the spare standby server / cloud B, the page data received by the transceiver 14B is stored in the management area of ​​the page data creation / persistence processing unit 13B of the memory unit 15B, and the persistence data (persistence-processed data) is stored in the memory unit 15B.

[0045] Furthermore, if a failure occurs in the operating primary server / cloud A, as illustrated in Fig. 14, in the CS separated DB 10B of the spare standby server / cloud B, the page data creation / persistence processing unit 13B restores the persistence data stored in the memory unit B based on the received page data (S12). The query processing unit 11B and transaction log processing unit 12B are also started. This completes the failover, as illustrated in Fig. 15, and the system can continue processing using the standby server / cloud B.

[0046] As mentioned above, the page data creation / persistence processing unit 13B does not necessarily have to be activated in the CS separated DB 10B of the spare standby server / cloud B. In that case, only the transmitting / receiving unit 14B and the storage unit 15B are operating in the CS separated DB 10B under normal circumstances. When a failure occurs in the operating primary server / cloud A, the persistent data stored in the storage unit 15B is restored and the metadata is moved to the management area, thereby completing the failover.

[0047] Furthermore, as described above, the transaction log processing unit 12B does not necessarily have to be stopped in the CS separated DB 10B of the spare standby server / cloud B. In this case, in the CS separated DB 10B under normal circumstances, at least the processing of the query processing unit 11B is stopped.

[0048] Furthermore, there are no particular limitations on the timing of data transmission and reception by the transmitter / receiver 14. For example, as illustrated in Fig. 13, after the page data creation / persistence processing unit 13A stores data in the storage unit 15A, the transmitter / receiver 14A may transfer the persisted data to the spare CS separation DB 10B (S3). Alternatively, as illustrated in Fig. 16, before the page data creation / persistence processing unit 13A stores data in the storage unit 15A, the transmitter / receiver 14A may transfer the persisted data to the spare CS separation DB 10B (S3).

[0049] The CS separation DB 10 may also include a compression / decompression unit 16. Specifically, as illustrated in Fig. 17, the compression / decompression unit 16A compresses data in the storage unit 15A in the operating CS separation DB 10A. In this case, the transmission / reception unit 14A transmits the compressed data to the backup CS separation DB 10B (S3).

[0050] In addition, in the spare CS separation DB 10B, the compression / decompression unit 16B decompresses the received compressed data, stores the page data in the management area of ​​the page data creation / persistence processing unit 13B of the memory unit 15B, and stores the persistence data (persistence-processed data) in the memory unit 15B.

[0051] The compression / decompression unit 16A may be located inside the primary server / cloud A, and does not necessarily have to be located inside the CS separation DB 10A. Similarly, the compression / decompression unit 16B may be located inside the standby server / cloud B, and does not necessarily have to be located inside the CS separation DB 10B.

[0052] [Redundancy Processing] Next, the redundancy processing by the redundancy system 1 according to this embodiment will be described with reference to Fig. 18 and Fig. 19. Fig. 18 is a sequence diagram showing the redundancy processing procedure. Fig. 18 illustrates the redundancy processing procedure in the CS separation DB 10 of the redundancy system 1 under normal circumstances. The sequence of Fig. 18 is started, for example, when a user performs an operation input to instruct the start of the process.

[0053] In the primary server / cloud A, the front-end server / application server 20 is running. Accordingly, in the CS separated DB 10A, the query processing unit 11A is running (step S1). In addition, the transaction log processing unit 12 is running.

[0054] The page data creation / persistence processing unit 13A creates data to be permanently stored in the storage unit 15 (step S2). Specifically, the page data creation / persistence processing unit 13A performs a process of creating persistent data to be stored in the storage unit 15A as persisted data, and a process of creating page data indicating information for managing the storage area of ​​the persistent data.

[0055] Next, the page data creation / persistence processing unit 13A stores the data in the storage unit 15A (step S4). Specifically, the page data creation / persistence processing unit 13A stores the persistence data in the storage unit 15A and also stores the page data in the management area of ​​the page data creation / persistence processing unit 13A in the storage unit 15A.

[0056] Furthermore, the transmitting / receiving unit 14A transfers the persistence data (persistence-processed data) and page data (metadata) to the CS separation DB 10B of the spare standby server / cloud B (step S3).

[0057] In the CS separation DB 10B of the standby server / cloud B, the transmitter / receiver 14B receives the transmitted data and stores it in the memory unit 15B of the standby CS separation DB 10B (step S5). Specifically, the transmitter / receiver 14B stores the received persistence data in the memory unit 15B, and also stores the page data in the management area of ​​the page data creation / persistence processing unit 13B of the memory unit 15B.

[0058] 19 illustrates an example of a redundancy processing procedure in the CS separation DB 10 of the redundant system 1 when a failure occurs. The sequence in FIG. 19 is started, for example, when a failure is detected in the primary server / cloud A.

[0059] When the CS separated DB 10B of the standby server / cloud B detects a failure in the primary server / cloud A by being notified or the like (step S11), the page data creation / persistence processing unit 13B restores the data in the storage unit B (step S12). Specifically, the page data creation / persistence processing unit 13B restores the persistence data stored in the storage unit B based on the received page data.

[0060] The query processing unit 11B is also started (step S13), and the transaction log processing unit 12B is also started, thereby completing the failover (step S14), and the system can continue processing on the standby server / cloud B.

[0061] [Effects] As described above, the redundant system 1 of this embodiment has an active CS-separated DB 10A and a standby CS-separated DB 10B. The active CS-separated DB 10A and the standby CS-separated DB 10B each have, in the compute layer, a query processing unit 11 that uses computational resources during operation, and, in the storage layer, a memory unit 15 that stores data and a transceiver unit 14 that transmits and receives data from the memory unit 15. In the storage layer of the active CS-separated DB 10A, the transceiver unit 14A transmits data from the memory unit 15A to the standby CS-separated DB 10B at a predetermined timing. When the standby CS-separated DB 10B is on standby and the compute layer is stopped, the transceiver unit 14B receives the transmitted data and stores it in the memory unit 15B.

[0062] Furthermore, when a failure occurs in the primary server / cloud A, the compute layer of the CS separated DB 10B of the spare standby server / cloud B starts up the query processing unit 11B.

[0063] The data includes persistent data to be stored persistently and page data indicating information for managing a storage area for the persistent data. The transmitter / receiver 14A then transmits the page data and the persistent data to the spare CS separation DB 10B.

[0064] As a result, in the redundant system 1, the DB is a CS-separated DB, and at least some processing, such as the query processing unit 11B, can be stopped in standby mode, reducing resource consumption and running costs compared to starting the entire DB. Furthermore, continuous transfer reduces data loss. In this way, it is possible to achieve high availability close to that of hot standby with low running costs close to that of cold standby.

[0065] Furthermore, in the operating CS separation DB 10A, the compression / decompression unit 16A compresses the data in the storage unit 15A. In this case, the transmission / reception unit 14A transmits the compressed data to the backup CS separation DB 10B. This reduces the amount of data transmitted and received, further reducing running costs.

[0066] Furthermore, in the storage layers of the operating CS separated DB 10A and the backup CS separated DB 10B, the transaction log processor 12 manages the data change history. If a failure occurs in the primary server / cloud A, the storage layer of the CS separated DB 10B in the backup standby server / cloud B starts the transaction log processor 12B. This makes it possible to further reduce running costs.

[0067] Furthermore, the page data creation / persistence processing unit 13B does not necessarily have to be activated in the CS separated DB 10B of the spare standby server / cloud B. This makes it possible to further reduce running costs.

[0068] [Example] Figures 20 to 22 are diagrams illustrating an example of a redundant system. In this example, the effectiveness of the CS-separated DB (minimum hot standby) of the above embodiment, as illustrated in Figure 20(a), was evaluated and compared with that of the cold standby system, as illustrated in Figure 20(b). Specifically, a load was applied to the primary system for 20 minutes using TPC-B (pgbench), and then a failover to the standby system was performed. The evaluation indices compared were the failover time from when the standby system starts up components until the DB server becomes connectable, and the performance recovery time after failover until the standby DB achieves 50% of the normal performance of the primary system.

[0069] 20, both the primary and standby virtual machines were used. The DB was Neon release-4245, the cloud was Google Cloud, the VM instance was e2-highmem-4, the virtual CPU was 4, the memory was 32 GB, and the disk was a standard persistent disk of 256 GB.

[0070] In this case, as shown in the example of Figure 21, the failover time was 2.0 seconds shorter for minimum hot standby, and it was confirmed that the failover time was reduced by using components that had already been started. On the other hand, it was confirmed that there was almost no difference in performance recovery time, at 0.15 seconds.

[0071] We also calculated and compared the running costs of minimum hot standby and cold standby. Specifically, we calculated the running costs for a data size of 100 GB per month based on CPU / memory / storage usage. As a result, as shown in Figure 22, the running costs for minimum hot standby were 2.6 times higher than those for cold standby. This is thought to be because the costs associated with CPU / memory usage are more significant for 100 GB.

[0072] However, because the CPU / memory usage shown in a in Fig. 22 is not affected by the data size, the storage cost becomes more dominant as the data size increases shown in β in Fig. 22. Therefore, it is expected that the difference with cold standby becomes smaller as the data size increases, and minimum hot standby becomes more effective.

[0073] [Program] A program written in a computer-executable language may be created to execute the processes executed by each device in the redundancy system 1 according to the above embodiment. In one embodiment, each device in the redundancy system 1 can be implemented by installing a redundancy program that executes the above redundancy process as packaged software or online software on a desired computer. For example, by executing the above redundancy program on an information processing device, the information processing device can function as each device in the redundancy system 1. The information processing device referred to here includes desktop and notebook personal computers. Other examples of information processing devices include mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants). The functions of each device in the redundancy system 1 may also be implemented on a cloud server.

[0074] 23 is a diagram showing an example of a computer that executes a redundancy program. The computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0075] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1031. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to a mouse 1051 and a keyboard 1052, for example. The video adapter 1060 is connected to a display 1061, for example.

[0076] Here, the hard disk drive 1031 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. The various pieces of information described in the above embodiments are stored in the hard disk drive 1031 or the memory 1010, for example.

[0077] The redundancy program is stored in the hard disk drive 1031 as, for example, a program module 1093 in which commands to be executed by the computer 1000 are written. Specifically, the program module 1093 in which each process executed by each device in the redundancy system 1 described in the above embodiment is written is stored in the hard disk drive 1031.

[0078] Data used for information processing by the redundancy program is stored as program data 1094, for example, in the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the hard disk drive 1031 into the RAM 1012 as necessary, and executes each of the above-described procedures.

[0079] The program module 1093 and program data 1094 related to the redundancy program are not limited to being stored in the hard disk drive 1031, and may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041. Alternatively, the program module 1093 and program data 1094 related to the redundancy program may be stored in another computer connected via a network such as a LAN or a WAN (Wide Area Network), and read by the CPU 1020 via the network interface 1070.

[0080] Although the present invention has been described above as an embodiment, the present invention is not limited to the description and drawings that form part of the disclosure of the present invention. In other words, other embodiments, examples, and operational techniques that can be made by those skilled in the art based on the present invention are all included in the scope of the present invention.

[0081] 1 Redundant system 10, 10A, 10B CS separated DB 11, 11A, 11B Query processing unit (calculation unit) 12, 12A, 12B Transaction log processing unit 13, 13A, 13B Page data creation / persistence processing unit 14, 14A, 14B Transmission / reception unit 15, 15A, 15B Storage unit 16, 16A, 16B Compression / decompression unit 20, 20A, 20B Front-end server / application server 30 Client terminal A Primary server / cloud B Standby server / cloud

Claims

1. A redundancy system having an operating database and a spare database, wherein the operating database and the spare database each have, in a compute layer, a calculation unit that uses computational resources during operation, and in a storage layer, a memory unit that stores data and a transceiver unit that transmits and receives data from the memory unit, wherein, in the storage layer of the operating database, the transceiver unit transmits data from the memory unit of the operating database to the spare database at a predetermined timing, and when the spare database is on standby and the compute layer is stopped, in the storage layer of the spare database, the transceiver unit receives the transmitted data and stores it in the memory unit of the spare database.

2. The redundant system according to claim 1, wherein, when a failure occurs in the operating database, the compute layer of the spare database starts up the calculation unit.

3. The redundant system described in claim 1, further comprising a compression unit for compressing data in the memory unit in the database in operation, and a transmission / reception unit in the database in operation for transmitting the compressed data to the backup database.

4. The redundant system described in claim 1, characterized in that the data includes persistent data to be permanently stored and page data indicating information for managing the storage area of the persistent data, and the transceiver unit transmits the page data and the persistent data to the spare database, respectively.

5. The redundant system described in claim 1, further comprising a log processing unit in the storage layers of the operating database and the backup database for managing the change history of the data, wherein when a failure occurs in the operating database, the storage layer of the backup database activates the log processing unit.

6. A redundancy method executed by a redundancy system, wherein the redundancy system has a database in operation and a spare database, each of the database in operation and the spare database having a compute layer that uses computing resources during operation and a storage layer that stores data, the redundancy method comprising: a transmission step in which the storage layer of the database in operation transmits data in a memory unit of the database in operation to the spare database at a predetermined timing; and a storage step in which, when the spare database is in standby mode and the compute layer is stopped, the storage layer of the spare database receives the transmitted data and stores it in the memory unit of the spare database.

7. A redundancy program that causes a computer to execute a redundancy method, wherein an operating database and a spare database each have a compute layer that uses computing resources during operation and a storage layer that stores data, and the redundancy program includes: a transmission step in which the storage layer of the operating database transmits data in the memory unit of the operating database to the spare database at a predetermined timing; and a storage step in which, when the spare database is in standby mode and the compute layer is stopped, the storage layer of the spare database receives the transmitted data and stores it in the memory unit of the spare database.

Images