In a multi-master replication system, the master nodes participating in replication can reside on separate physical hosts. If any master node goes offline, the master nodes on the other hosts continue to synchronize transactions amongst themselves thereby ensuring consistency of the publication tables on the remaining active master nodes. When an offline master node is brought back online, pending transactions involving that master node are synchronized with the other master nodes of the replication system. No transaction data is lost between the master nodes.Thus, an inherent characteristic of multi-master replication systems is that each master 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 master node) of the multi-master replication system.Thus, should any master node go offline, the configuration information stored in the control schema is always available to the publication server in order to continue operation of the replication system.Though 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.The significance of the controller database and its proper usage to ensure high availability of the replication system are discussed in the following sections.At any given point in time during operation of the replication system, one of the publication databases of the master nodes is designated as the controller database.
• In the xDB Replication Console, when a master node is selected, the Controller database field in the Property window is set to Yes if this master node is the current controller database.
• In the xDB Replication Configuration file, the authentication and connection parameters are set to the controller database. See Section 126.96.36.199 for information on the xDB Replication Configuration file.When a replication system is in use, the xDB Replication Server, and particularly, the publication server component, accesses the currently designated controller database for any configuration information.Any changes that you make to the replication system configuration using the xDB Replication Console or the xDB Replication Server CLI are first updated in the control schema of the controller database, and then replicated by the xDB Replication Server to the other publication databases to keep such information consistent.Note: Replication history may take a longer period of time to replicate from the controller database to the other publication databases, therefore it is possible that some replication history may be lost if access to the controller database fails, and a switchover is made to another publication database to act as the controller database. See Section 7.4 for information on replication history.Therefore it is important that the controller database be accessible whenever the replication system is use.There may be circumstances where access to the controller database cannot be maintained such as scheduled maintenance that must be performed on the database server hosting the controller database or an unexpected network or system problem.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 xDB Replication Server automatically performs a connection to another online publication database to act as the controller database.The controller database authentication and connection information is modified accordingly in the xDB Replication Configuration file (see Section 188.8.131.52). Thus, any subsequent startups of the publication and subscription servers use this newly designated controller database.The controller database can be subsequently changed to use another publication database as described in sections 6.11.3 and 6.11.4.If at some point, the database server hosting the controller database must be taken 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, this switch can be made using the xDB Replication Console (see Section 7.7) or the xDB Replication Server CLI (see Section 8.3.26).After the switch has occurred, you can take the former controller database offline. Any pending transactions involving the former controller database will be applied after it is brought back online.If the publication server is not running, you can still change the controller database so that the publication server connects to a newly designated controller database when the publication server is started. See Section 6.11.4 for information on this method.If for some reason the currently designated controller database cannot be accessed by the publication server, certain symptoms may occur such as the following:
• If it is determined that the controller database is inaccessible, then you can switch the controller database role to another publication database by editing the xDB Replication Configuration file so it contains the connection information of another master node in the replication system. See Section 184.108.40.206 for information on the xDB Replication Configuration file.After the xDB Replication Configuration file has been modified, restart the publication server along with the subscription server if you are using that as well. See Section 5.2.1 for instructions on starting the publication server. See Section 5.3.1 for instructions on starting the subscription server.