Fast Switchover in Data Guard, some suggestions for Failover

Fast Switchover in Data Guard, some suggestions for Failover

In fact, Failover and Switchover are both a headache and a key process for everyone to deal with disasters.

Assume that you are sleeping in the middle of the night, and you are awakened by an alert call to learn that a server is down due to a fault. In this case, we will generally follow the process below:

1) check whether the original node is available. check whether there are exceptions in ILO and storage.

2) If the original node can be restarted, try to immediately restore the business, and then analyze the root cause, whether it is caused by hardware aging or hardware failure. If the problem is found to have a great impact, you can use Switchover

3) if the original node cannot be restarted, you need to consider Failover. If the IP address can be directly replaced in the same data center, the remote data center needs to be developed in combination, and the system O & M needs to modify the application connection IP address.

4) Work with the system, develop, and check whether the business is recovered.

At this time, there are several problems.

1) The firewall information of the original database is not found in the slave database after the Failover. In this case, a temporary solution is to disable the firewall and allow applications to connect to it. Collect the connection server information and ports in the background, and enable the firewall after collecting the information to a certain extent, another method is to enable the firewall from the historical backup.

2) After Switchover and Failover, check whether the multiple listening ports of the master and slave databases are consistent. Otherwise, connection problems may occur due to different application connection ports.

3) Some db links are unavailable after the master/Slave database is switched. The reason is that the host name configuration in tnsnames. ora is not uniform and permissions are missing.

There are more details, such as inconsistent comparison parameter files and inconsistent Kernel Parameter files, which may cause configuration problems and performance problems.

Therefore, we need to quickly switch Swithover, Failover, and data. In addition to the switchover, this extra work takes much more time than switching.

Of course, I have also analyzed the command switching method and written script aids. Basically, the difference between Switchover and Failover is very small. It is transparent for the slave database, but it is only a State sign. Therefore, we can simplify some content of switchover and Failover. In fact, the main difference in operations is whether to modify the IP address. switchover may replace the IP address, failover may modify the slave database IP address to the original master database IP address.

This does not seem to be uniform. In fact, further analysis is required if we use the host name in listenerora, tnsnames. ora, you only need to mark it once in/etc/hosts, and modify the configuration of/etc/hosts after replacement. Otherwise, the configuration is not modified.

Other information will be clearer and synced in advance.

There may be a problem, that is, the master database is already an online business. How can this problem be unified and handled improperly? This is right, if you are not sure about the master database, do not modify the information of the master database. The master database cannot be changed, but the slave database can. Therefore, we can standardize the configuration at the slave database level to ensure that the configuration information is standard and standard in the slave database. In this way, in the face of downtime events, our operations and mixing are simple, and we can decide whether it is switchover or failover. All other information is modified and synchronized in advance.

As for what other aspects need to be considered, we have considered all aspects in the figure, which can be used as a way to standardize the slave database.