Ensuring high availability v7

In a multi-master replication system, the primary nodes participating in replication can reside on separate physical hosts. If any primary node goes offline, the primary nodes on the other hosts continue to synchronize transactions among themselves, which ensures consistency of the publication tables on the remaining active primary nodes. When an offline primary node is brought back online, pending transactions involving that primary node are synchronized with the other primary nodes of the replication system. No transaction data is lost between the primary nodes.

Thus, an inherent characteristic of multi-master replication systems is that each primary node serves as a backup for the other nodes, and any such node can provide consistent publication data to applications.

Similarly, the complete, multi-master replication system configuration information (that is, the control schema and its control schema objects) is stored in each publication database (that is, every primary node) of the multi-master replication system.

If any primary node goes offline, the configuration information stored in the control schema is always available to the publication server so that the replication system operation can continue.

Although every publication database contains a copy of the control schema, the publication database designated as the controller database has special significance to the operation of the replication system.

Significance of the controller database

Throughout operation of the replication system, one of the publication databases of the primary nodes is designated as the controller database.

You can identify the controller database in either of these ways:

• In the Replication Server console, when you select a primary node, the Controller database field in the Property window is set to Yes if this primary node is the current controller database.
• In the Replication Server configuration file, the authentication and connection parameters are set to the controller database. See Replication Server configuration file for details.

When a replication system is in use, the Replication Server, and particularly the publication server component, accesses the currently designated controller database for configuration information.

Any changes that you make to the replication system configuration using the Replication Server console or CLI first update the control schema of the controller database. Then they are replicated by the Replication Server to the other publication databases to keep such information consistent.

It's important that the controller database be accessible whenever the replication system is use.

Automatic switchover of the controller database

If the publication server is currently running with its connection to the controller database and that database suddenly becomes inaccessible such as with a network or system problem, the Replication Server automatically performs a connection to another online publication database to act as the controller database There is no apparent disruption in the operation of the Replication Server.

Modify the controller database authentication and connection information accordingly in the Replication Server configuration file (see Replication Server configuration file). Any later startups of the publication and subscription servers use this newly designated controller database.

You can later change the controller database to use another publication database as described in Switching an active controller database and Restarting with an alternate controller database.

Switching an active controller database

If you must take the database server hosting the controller database offline for maintenance or some other reasons, you can switch the role of the controller database to another publication database.

If the publication server is currently running, you can make this switch using the Replication Server console (see Switching the controller database) or the Replication Server CLI (see Setting the controller (setascontroller)).

After the switch, you can take the former controller database offline. Any pending transactions involving the former controller database are applied after it is brought back online.

If the publication server isn't running, you can still change the controller database so that the publication server connects to a newly designated controller database when the publication server starts. See Restarting with an alternate controller database for information on this method.

Restarting with an alternate controller database

If the publication serveran can't access the currently designated controller database, symptoms such as the following might occur:

• The Replication Server console is unresponsive or the Replication Server CLI commands fail unpredictably.
• The publication server isn't running and you can't successfully start it.

If you can't access the controller database, then you can switch the controller database role to another publication database. Edit the Replication Server configuration file so it contains the connection information of another primary node in the replication system. See Replication Server configuration file for more information.

After you modify the Replication Server configuration file, restart the publication server and the subscription server if you are using that. See Registering a publication server for instructions on starting the publication server. See Registering a subscription server for instructions on starting the subscription server.

• On this page
• Significance of the controller database
• Automatic switchover of the controller database
• Switching an active controller database
• Restarting with an alternate controller database