Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Intuitive comparison of Common Database disaster recovery techniques

2025-02-22 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

At present, it is an information society, the importance of database is self-evident. This paper examines and compares various database disaster recovery technologies from the point of view of ordinary users rather than manufacturers (not talking about RPO, RTO, MDT, MTBF, MTTR and other professional terms), hoping to help the majority of users to be less fooled, take fewer detours, and avoid unnecessary economic losses and system accidents.

For the majority of users, they are most concerned about the following two points:

a. Whether there are two logically consistent data: if a disaster recovery solution has two logically consistent data, then when the failure occurs, the user data is safe and the availability of the system is guaranteed. Having two 'logically consistent' data is a must for a qualified disaster recovery plan. Please note that we are talking about 'logical data', not 'physical data'. Please read on patiently what is logical data and what is physical data.

b. There is no load balancing read-write separation: load balancing read-write separation, especially the separation of OLTP and OLAP, is recognized by the industry as one of the effective means to improve database performance.

In the current market, the disaster recovery technologies related to ORACLE and SQLSERVER are roughly as follows:

RAID I

Fig. 1 schematic diagram of RAID I principle

a. An instance of DB (thick red ellipse in the figure)

b. A logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. No load balancing read-write separation

Dual machine hot standby

Fig. 2 schematic diagram of dual-computer hot standby principle

a. An instance of DB (thick red ellipse in the figure)

b. A logical data (medium thick red ellipse in the figure)

c. Two physical data (RAID) (reddish ellipse in the figure)

d. No load balancing read-write separation

Double machine and double cabinet

Fig. 3 schematic diagram of the principle of dual machines and double cabinets

a. An instance of DB (thick red ellipse in the figure)

b. A logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. No load balancing read-write separation

Double active storage

Fig. 4 schematic diagram of the principle of double active storage

a. An instance of DB (thick red ellipse in the figure)

b. A logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. No load balancing read-write separation

Oracle RAC

Fig. 5 schematic diagram of Oracle RAC principle

a. Two DB instances (bold red ellipse in the figure)

b. A logical data (medium thick red ellipse in the figure)

c. Two physical data (RAID) (reddish ellipse in the figure)

d. Separation of read and write from load balancing

Oracle DG

Fig. 6 schematic diagram of Oracle DG principle

a. Two DB instances (bold red ellipse in the figure)

b. Two logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. Manual load balancing read-write separation, the target side can be queried

SQL Server Mirror

Fig. 7 schematic diagram of SQL Server mirroring principle

a. Two DB instances (bold red ellipse in the figure)

b. Two logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. There is no read-write separation of load balancer, and the target library cannot be accessed.

SQL Server AlwaysOn

Fig. 8 schematic diagram of SQL Server AlwaysOn principle

a. Two DB instances (bold red ellipse in the figure)

b. Two logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. Manual load balancing read-write separation, the target side can be queried

DBTwin double active cluster

Fig. 9 schematic diagram of DBTwin dual-active cluster principle

a. Two DB instances (bold red ellipse in the figure)

b. Two logical data (medium thick red ellipse in the figure)

c. Two physical data (fine red ellipse in the figure)

d. Automatic load balancing read-write separation

The comprehensive comparison is as follows:

Table A Comprehensive comparison of disaster recovery techniques for various databases

To sum up, when a failure occurs, if a scheme has' two logical data that are consistent in real time', then the scheme is undoubtedly ideal; if there is only one logical data, although there are two physical data, however, because the physical data only maintains the "physical consistency" at the sector or block or even volume level, and lacks the logical protection of database transactions, the final database integrity is still at risk.

In terms of user data security, the following is sorted from high to low:

Maximum: two pieces of logical data that are consistent in real time. Second highest: two logical data, but there is a short data delay. Third: one logical data, but there are two physical data. Minimum: a logical data, but also only one physical data.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report