Using databases with Hot-Standby.

1) Introduction

Hot-Standby is an E3 feature that allows implementing of the concept of fail-over in a supervisory system. This means you can have two servers running simultaneously: the main server and the secondary server, the latter working as a backup for the first one. If the main server fails, the backup server immediately takes over. When the backup server is on hold, it is called Standby.

2) Understanding Hot-Standby

Servers in Hot-Standby can be switched manually (via E3 Server) or automatically. The automatic switch occurs when the backup server detects, via communication tests with that server, that the main server is not running anymore. You can also configure the automatic switch to happen whenever the I/O channel fails, or whenever any other local failure is detected by the application.

To implement Hot-Standby, E3 allows its servers to be configured in different statuses:

• Active – This is the server running the application. Only one server can be active in a Domain at a given moment.
• Standby – The standby server remains on hold while the application is being loaded, but not being executed. It monitors the active server and takes over as soon as there is no response from the active server.
• Inactive – An inactive server is declared on the Domain, but it is not selected as either main or standby server. It monitors all changes in the Domain file, and can be activated at any time.
• In maintenance – The server in maintenance does not take part in any event of the Domain. This status is useful to indicate that a server is being set up, but is not ready to take over.

3) Working with databases

Hot-Standby guarantees the application’s continuity, but when using databases, it is also necessary to ensure that access to the database is continued. This can be accomplished in two different ways.

In the first one, both applications access the same database. Access to the database is enabled in the application by setting up the DBServer object in both servers (main and standby) with the same location parameters of the database on the network.

Figure 1: Domain with Hot standby accessing the same database server

Notice that, to keep the system running, it is important that the database be in a separate machine, accessible to both servers. In this case, the database’s continuity control happens outside E3.

In the second one, data is recorded in two different databases. The databases can be in different servers, but it is best that both run locally in the servers, main and standby, for security and speed reasons. Thus, we can guarantee that the databases will always be accessible, because the machine that is running the application is also running the databases.

Figure 2 – Main and Standby domains, each accessing its own database server

In this case, we must ensure the synchronism between both the main and the backup application’s databases. E3 supports this option via DBServer‘s EnableSynchronization property. When active, all data recorded in the main database are updated on standby database almost immediately, in the smallest amount of time possible.

One important detail is that if the main application cannot send data to the standby server, these data will be stored locally in disk, to be sent later (when communication between computers is reestablished). This ensures uniformity between the tables generated by the application.

4) Final Remarks

The goal of Hot-Standby is to guarantee the application’s continuity, with little loss due to process halts. The scope of the tool, however, is to ensure the application’s execution; any other commands must be issued directly by the programmer.