CN105391790A - Database high-availability method similar to RAC One Node - Google Patents

Abstract

The present invention provides a kind of RAC? One? Node's database high-availability method integrates the resources of each physical machine into a large cluster; makes each database in different physical hosts connect to shared storage. The present invention overcomes rac? one? node only supports oracle? 11G functional defects, the perfect support for ORACLE? 10g and 11g realize the high availability of a single instance in an oracle non-cluster environment.

Description

High Availability Method of Database Like RAC One Node

technical field

The invention relates to a database high availability method, in particular to a RACOneNode-like database high availability method.

Background technique

High Availability (HA): The reliability of a computer system is measured by the mean time to failure (MTTF), that is, how long the computer system can run normally before a failure occurs. The higher the reliability of the system, the longer the mean time between failures. There are generally three ways to achieve high availability:

Master-slave mode (asymmetric mode), working principle: the main machine is working, and the standby machine is in the monitoring preparation state; when the main machine is down, the standby machine takes over all the work of the main machine. Or manually switch the service to run on the host, and the data consistency is resolved through the shared storage system.

Two-machine duplex mode (mutual backup and mutual assistance), working principle: two hosts run their own services at the same time and monitor each other. When any host fails, the other host immediately takes over all its work to ensure The work is real-time, and the key data of the application service system is stored in the shared storage system.

Cluster working mode (multi-server mutual backup mode), working principle: multiple hosts work together, each running one or several services, each defining one or more standby hosts for the service, when a host fails, run on it The service can be taken over by other hosts.

OracleRAC: It is the abbreviation of OracleRealApplicationCluster. The official Chinese document is generally translated as "real application cluster". Its appearance solves an important problem faced by traditional database applications: the contradiction between high performance, high scalability and low price.

The principle of the Oracle11G function RON (RACOneNode) is different from the previous HA database. RACOneNode is based on the RAC database and is managed through the Oracle cluster software (GRID). It only needs to start an instance of the RAC database. When the node running the instance needs to be maintained and shut down In this case, the database instance can be switched to run on other nodes in the cluster through onlinedatabaserelocation.

Contents of the invention

The present invention makes improvements to the problems existing in the above-mentioned prior art, that is, the technical problem to be solved by the present invention is to provide a method for high availability of a database like RACOneNode.

In order to solve the problems of the technologies described above, the present invention provides the following technical solutions:

A high-availability method for databases like RACOneNode, which integrates the resources of each physical machine into a large cluster; makes each database in different physical hosts connect to shared storage.

Unified management technology using GI management commands.

The integrated resources are resource items, and the resource items are: $SID resource, $SID.vip resource, $SID.lsnr resource, $SID.db resource and $SID.head resource.

$SID resource: It is the basis of the entire resource item. By defining this resource, other resources in the resource item depend on it, realizing the unified management of the resource item, and the stop, reset and switching operations of the $SID resource. Affects all other resources in the resource item.

$SID.vip resource: It is a VIP resource managed internally by OracleClusterware. The $SID.vip resource depends on network resources and $SID resources.

$SID.lsnr resource: It is the listener resource in the resource item, which is protected by the shell script act_lsnr.ksh. The $SID.lsnr resource depends on the $SID.vip resource.

$SID.db resource: it is a single instance data resource in the resource item, which is protected by the shell script act_db.ksh; the $SID.db resource depends on the $SID resource.

The $SID.head resource echoes the beginning and end of the $SID resource, encapsulates the entire resource item, and manages and maintains it as a whole; the SID.head resource is protected by the shell script act_rgh.ksh.

The beneficial effect of the present invention is that the present invention saves a large amount of server resources, realizes server clusters, and can greatly save the number of servers when the databases of small and medium-sized applications are migrated into the clusters. Statistics from multiple data centers of the State Grid show that if an application system that occupies less than 10% of server resources is deployed in a cluster, and the resource utilization rate of each node of the cluster is guaranteed to reach 70%, such a node can run 7 applications. For a four-node cluster, one of which is used as a backup machine, it can also run 21 applications, which saves the resources of 38 servers compared to HA data. Each additional node can double the resource utilization and reduce the number of servers.

Save a lot of license fees, build a database resource pool, and existing databases can be directly migrated into the pool. There is no license fee. For newly launched applications, you only need to purchase a license for a single library, and you do not need to purchase expensive RAC fees.

Flexible and scalable cluster structure, improving availability The cluster provided by GI can flexibly add and delete cluster nodes without affecting the normal operation of the business. Realize failover and online migration functions, effectively guarantee unplanned downtime and planned downtime.

Realize the existing oracle10GRACONENODE, saving database upgrade costs and development costs. At present, the database of many database data centers still adopts the oracle10G version. Based on ERON technology, it can realize the RACONE NODE technology unique to 11G, and does not require special downtime upgrades to improve the availability of the business system; there is a large gap between the database 11G and 10G Differences, database upgrades, require resetting of many parameters, and development between database codes.

Improve the level of automated operation and maintenance and reduce the cost of operation and maintenance. When the database is down, it can realize automatic migration and improve the level of automatic operation and maintenance; through the ERON cluster, reduce the number of server purchases, save electricity and computer room equipment costs, and improve operation and maintenance personnel Technology.

Description of drawings

The accompanying drawings are used to provide a further understanding of the present invention, and constitute a part of the description, and are used together with the embodiments of the present invention to explain the present invention, and do not constitute a limitation to the present invention. In the attached picture:

Fig. 1 is a schematic diagram of database deployment of the present invention;

Fig. 2 is a schematic diagram of dynamic migration of database deployment in the present invention;

Fig. 3 is a resource scheduling diagram of the present invention;

FIG. 4 is a resource association diagram of the present invention;

Fig. 5 is a flow chart of resource switching in the present invention;

Fig. 6 is the working flow diagram of the GIagent routine of the present invention;

Fig. 7 is a schematic diagram of a deployment scheme based on a conventional method oracle database;

Figure 8 is a schematic diagram of the oracle database deployment scheme based on the ERON method;

Fig. 9 is one of the schematic diagrams of the achievements of the present invention;

Fig. 10 is the second schematic diagram of the achievement of the present invention.

detailed description

As shown in Figures 1-10, a preferred embodiment of the present invention is disclosed.

The present invention, ERON (Extended RACONE NODE), integrates the resources of each physical machine to form a large cluster (cluster). It can integrate servers, improve failover capabilities, and provide loadbalance capabilities. In addition, it can realize database storage virtualization, standardize database environments, and avoid upgrade downtime and maintenance time.

As shown in Figure 1, assume that there are a total of 3 physical hosts, ServerA, ServerB, and ServerC. These 3 physical hosts form a singlecluster. On the 3 physical hosts, there can be 5 different single instance databases. DB1 and DB2 are located in On ServerA, DB3 is on ServerB, and DB4 and DB5 are on ServerC. Each database is connected to shared storage.

As shown in Figure 2, when ServerB where DB3 is located fails and cannot provide services, the agent process of GI detects and calls the OMotion routine to transfer the database instance on DB3 to Server without manual intervention.

ERON technology is a unified management technology based on the GridInfrastructure platform environment using GI management commands. For example, the database and monitoring service are registered in GI in the form of "resource item", so that the management of the database and monitoring service can be realized through resource item management (startup and shutdown).

The resource items in ERON technology are: $SID resource, $SID.vip resource, $SID.lsnr resource, $SID.db resource, $SID.head resource five resource items ($SID refers to the instance name of the database), Among them, except $SID.vip, the other four resources have written their own scripts for the state function realization and state protection of resource items. Among them, the associative relationship of the five resources is shown in FIG. 3 .

As shown in Figure 4, the single-instance database protected by GI is actually a resource item, which is a collection of related resources. Through the interaction between resources, the protection of the single-instance database is completed.

$SID resource:

This resource is the basis of the entire resource item. By defining this resource, other resources in the resource item depend on it, and the unified management of resource items is realized. Stopping, resetting, and switching operations on this resource will affect all other resources in the resource item.

$SID.vip resource:

This is a VIP resource internally managed by OracleClusterware, so there is no need to write shell scripts to protect it. This resource depends on the network resource and the $SID resource described earlier. Typically, the network resource is ora.net1.network.

$SID.lsnr resource:

This is the listener resource in the resource item, which is protected by the shell script act_lsnr.ksh. This resource depends on the previous $SID.vip resource. In addition, because Ping An currently uses a shared OracleHOME and uses ACFS to provide this sharing mechanism, the listener resource also depends on the ACFS resource where the OracleHOME is located.

$SID.db resource:

This is a single-instance data resource in the resource item, which is protected by the shell script act_db.ksh. This resource depends on the previous $SID resource. Because Ping An currently uses a shared Oracle HOME and uses ACFS to provide this sharing mechanism, the database resources also depend on the ACFS resources where the corresponding Oracle HOME is located. In addition, since the data files of the database are stored in two disk groups, DATA_DG and FRA_DG, the database resources depend on these two resources.

$SID.head resource:

This resource echoes the previous $SID resource from beginning to end, and encapsulates the entire resource item for management and maintenance as a whole. This resource is protected by the shell script act_rgh.ksh. This script is similar to the script used to protect the $SID resource. It creates a local temporary file and checks the status of the resource based on the content of the temporary file.

This resource is at the top of the dependencies in the resource item, so its OFFLINE does not cause other resources in the resource item to also be set OFFLINE. However, switching of this resource can cause switching of the entire resource item. Therefore, for the switching of this resource, the same switching strategy as the listener resource is also adopted, that is, no restart or switching. Avoid handovers caused by this resource exception. Because this resource uses the same mechanism as the $SID resource, if there is a problem with this resource, the $SID resource may also have a problem at the same time. It would be more appropriate to leave control of the entire resource item to $SID at the bottom of the dependency.

As shown in Figure 5, the agnet work routine of GI checks the status of the resource item, and defines the restart or failvoer of the resource item according to the parameter of the resource through the change of the resource status.

Figure 5 is only for user-defined resources, and only considers the role of a single resource. Switches due to complex dependencies between resources are not taken into account.

After the OracleClusterware resource (hereinafter referred to as the resource) is abnormal, the Clusterware fails to check the resource. In this case, Clusterware will first determine whether the resource is allowed and needs to be restarted according to the RESTART_ATTEMPTS attribute value defined in the resource. The judgment is made based on the dynamic attribute value RESTART_COUNT and the static attribute value RESTART_ATTEMPTS of the current resource. For example, the current RESTART_COUNT is 2 (indicating that the resource has been restarted twice), and the defined value of RESTART_ATTEMPTS is 3, then Clusterware thinks that the resource can still be restarted on the local node, and will try to restart the resource and add 1 to the RESTART_COUNT value.

Note: RESTART_COUNT will increase regardless of whether the resource restarts successfully on the local node, and RESTART_COUNT will not be reset to 0 unless the resource is successfully started or reaches the resource's UPTIME_THRESHOLD.

If the restart of the resource on the local node fails, according to the definition of the resource, if the resource is allowed to run on multiple nodes in the Cluster, then Clusterware will switch the resource to run on other nodes according to the order of nodes defined in HOSTING_MEMBERS or SERVER_POOLS . If the resource cannot be successfully started on other nodes, Clusterware will continue to try to switch the resource until all nodes defined in HOSTING_MEMBERS or SERVER_POOLS have been tried. In this case, OracleClusterware will set the status of the resource to OFFLINE and stop monitoring the resource.

If the resource is successfully restarted on any node during the switchover, Clusterware will reset the resource's RESTART_COUNT to 0.

Note: Resource switching caused by unsuccessful resource restart has nothing to do with the dynamic resource attribute FAILURE_COUNT. OracleClusterware will not increase the FAILURE_COUNT value because of the resulting resource switching.

When the resource check fails, if the number of restarts of a resource has reached the defined RESTART_ATTEMPTS value or the resource is not running at all on the local node for restart attempts (by setting RESTART_ATTEMTPS=0), then Clusterware will determine whether the resource can be switched. Whether a resource can be switched is determined by the resource's dynamic attribute FAILURE_COUNT and the resource's static attribute FAILURE_THRESHOLD. If the FAILURE_COUNT value of a resource has reached the defined FAILURE_THRESHOLD, the resource is not allowed to switch. In this case, Clusterware will reset the resource's FAILURE_COUNT attribute to 0, set the resource status to OFFLINE and stop monitoring the resource. If the FAILURE_COUNT of the resource has not reached the defined FAILURE_THRESHOLD value, Clusterware will switch resources according to the order of nodes defined in the resource attribute HOSTING_MEMBERS or SERVER_POOLS. If the switch is successful, reset the RESTART_COUNT of the resource to 0; if the switch is unsuccessful, continue to try the resource switch according to the steps in point 2.

Note: The resource's dynamic attribute FAILURE_COUNT will only be incremented when the resource's RESTART_ATTEMPTS value is reached to switch. In other words, OracleClusterware considers the resource failed on the local node only in this case.

The dynamic property value FAILURE_COUNT of a resource is not like RESTART_COUNT, which can be reset to 0 after the resource is successfully started or the resource is successfully started using the crsctlstartres command. FAILURE_COUNT will only be reset after it reaches the FAILURE_THRESHOLD defined in the resource or exceeds the defined FAILURE_INTERVAL time limit. set to 0. In the first case, that is, when FAILURE_THRESHOLD is reached, Clusterware will set the resource status to OFFLINE and stop monitoring the resource; in the second case, Clusterware will still monitor the resource and switch the resource when needed.

As shown in Figure 6, the GIAgent routine workflow. Figure 6 is only for user-defined resources, and only considers the role of a single resource. It does not take into account the resource start-stop and switching caused by the complex dependencies among various resources. Figure 6 describes how OracleClusterwareAgentFramework manages resources, and under what circumstances call the entry point (EntryPoint) of which resources.

ClusterwareAgent will periodically call the CHECK routine of the resource to check the resource according to the resource definition attribute CHECK_INTERVAL. If the check times out, (this is controlled by SCRIPT_TIMEOUT), if there is an ABORT routine, then call the ABORT routine; if not, the Agent process exits. Because the status of the resource cannot be detected successfully to determine whether the resource is healthy, Clusterware will set the status of the resource to INTERMEDIATE, and the column of detailed status information is CHECKTIMEDOUT.

If the call to the resource's CHECK routine returns an error, it means that the check on the resource failed and an exception occurred on the resource. In this case, Clusterware will perform corresponding operations on resources according to the resource switching process described above.

In the case of restarting a resource, the Agent starts the resource by calling the resource's START routine. If the START routine times out (this is controlled by START_TIMEOUT or SCRIPT_TIMEOUT), in the case of an ABORT routine, the Agent calls the ABORT routine; if not, the Agent process exits.

After calling the START routine, the Agent will immediately call the CHECK routine to check the status of the resource. If the check succeeds, the resource starts successfully and runs well; if the check fails, it means that the start of the resource fails, and the Agent will call the CLEAN routine of the resource to clean up the resource on the local node, and then decide whether to clean the resource according to the specific situation. switch.

In the process of calling the STOP routine to stop the resource, if the STOP routine returns successfully, the Agent will call the CHECK routine to check the resource situation. If the CHECK return fails, it means that the resource has been stopped. This is a normal situation, and Clusterware will update the resource status set to OFFLINE.

In the process of calling the STOP routine to stop resources, if a timeout occurs (this is controlled by STOP_TIMEOUT or SCRIPT_TIMEOUT), if there is an ABORT routine, the Agent calls the ABORT routine, otherwise the Agent process exits. Regardless of whether STOP returns failure or timeout, the Agent will call the CHECK routine to check the resource status, and regardless of whether the CHECK routine returns success or failure, the Agent will call the CLEAN and CHECK routines to clean up the resource, and finally set the resource status to OFFLINE .

As shown in Table 1, the nine functions of the present invention, such as host exception, application exception, and GI suite exception, are tested and verified, and the cluster architecture is adopted to realize the failover function and online migration function of ERON technology.

Table 1

Ordinary five different business systems, oracle database deployment as shown in Figure 7:

Due to high business requirements, business systems A and B each use 2 servers and use RAC clusters; business systems C, D, and E each use 1 server, and a total of 7 servers are required.

As shown in Figure 8, using the ERON of the present invention, first cluster servers A, B, and C; then deploy business systems B and C on server A; deploy D and E on server B; deploy A on server C. A total of 3 servers are used to achieve high availability of business systems. It not only saves the cost of software and hardware, but also reduces the space occupation and energy consumption of the server room. At the same time, it is conducive to centralized deployment and centralized management.

The actual test data are shown in Figures 9 and 10: After the five business systems are moved into the resource pool, it can be seen from important performance indicators such as CPU, I/O, and memory:

The CPU load is below 10%, the I/O IOPS is around 200, and the performance of the resource pool is quite stable;

The resource pool is rich in resources and can be migrated to more business systems.

Some indicators of the database AWR are shown in Table 2:

Table 2

The data shows the stable operation indicators of the database from the dimensions of parsing times, logical reads, and physical reads:

During the implementation process, five sets of databases of different versions were upgraded to 10.2.0.5, which improved the performance and stability of the database.

The database has two primary nodes and one standby node in the cluster, which improves the high availability of the original single-instance database.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still understand the foregoing embodiments The recorded technical solutions are modified, or some of the technical features are equivalently replaced. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims (8)

1. the database high availability method of a kind RACOneNode, is characterized in that, the resource consolidation of each physical machine is got up, and becomes a large cluster; Each database Connection Sharing in different physical hosts is stored.

2. the database high availability method of class RACOneNode according to claim 1, is characterized in that: utilize the administration order of GI to carry out unified management technology.

3. the database high availability method of class RACOneNode according to claim 1 and 2, it is characterized in that, the resource integrated is resource items, and resource items is respectively: $ SID resource, $ SID.vip resource, $ SID.lsnr resource, $ SID.db resource and $ SID.head resource.

4. the database high availability method of class RACOneNode according to claim 3, it is characterized in that, $ SID resource: the basis being whole resource items, by defining this resource, all it is depended on to make other resources in resource items, achieve the unified management to resource items, to the stopping of $ SID resource, to reset and handover operation to have influence in resource items other all resources.

5. the database high availability method of class RACOneNode according to claim 3, it is characterized in that, $ SID.vip resource: be a VIP resource by OracleClusterware internal control, $ SID.vip Resource Dependence is in Internet resources and $ SID resource.

6. the database high availability method of class RACOneNode according to claim 3; it is characterized in that; $ SID.lsnr resource: be the monitor resource in resource items, protected by shell script act_lsnr.ksh, $ SID.lsnr Resource Dependence is in $ SID.vip resource.

7. the database high availability method of class RACOneNode according to claim 3, is characterized in that, $ SID.db resource: be the single instance data resource in resource items, protected by shell script act_db.ksh; $ SID.db Resource Dependence is in $ SID resource.

8. the database high availability method of class RACOneNode according to claim 3, is characterized in that, $ SID.head resource, echoes, be encapsulated by whole resource items, integrally carry out management maintenance with $ SID resource head and the tail; SID.head resource is protected by shell script act_rgh.ksh.