Multimaster Mesh administration

This section explains how to administer and maintain a Multimaster Mesh. It does not document how to configure SA for a Multimaster Mesh. For more information about Multimaster architecture and planning for and installing a Multimaster Mesh, see the SA 10.51Get started section and the SA 10.51 Install section.

Built-in redundancy of the Multimaster Mesh

Each SA core manages one data center. Each data center is represented as a facility in SA. A multimaster mesh is two or more SA cores managing an equal number of facilities. A multimaster mesh can optionally include one or more SA satellites. An SA satellite is a “mini” SA core that manages a smaller number of servers than a full SA core.

The multimaster mesh configuration of SA is designed for redundancy, reliability, and high availability. A multimaster mesh consists of multiple synchronized cores. All data on each core is synchronized with every other core so that if one core goes down, the other cores handle all requests and jobs.

A multimaster mesh also provides load balancing for better performance.

What Are Multimaster Mesh conflicts?

In a multimaster mesh (which by definition consists of two or more SA cores), when SA users perform any action on any core, each core forwards the transaction details to all the other cores in the mesh to keep them all synchronized. If two users perform overlapping or conflicting actions on two different cores, when the cores forward the transactions to the other cores, a conflict will occur.

SA can detect these kinds of conflicts, notify you when they occur, and help you resolve them.

The SA core itself cannot resolve the conflicts. SA administrators must use the Multimaster Tools in the SA Client to resolve the conflicts at the target databases when they occur to ensure that the transactions are not lost.

1. To view conflicts, see Viewing the state of the Multimaster Mesh .
2. To resolve conflicts, see Resolving mesh conflicts .
3. You can also use the System Diagnosis tools in the SA Client to view information about the health of the multimaster components. For more information, see Diagnostic tests.

How does SA handles mesh conflicts?

Each SA core manages one facility. When an SA core (the source core) sends a transaction to another core (the destination core) and a conflict occurs, SA detects the conflict and the following occurs:

1. The transaction is canceled.
2. All SA database rows affected by the transaction are locked, thereby preventing further changes to those rows.
3. The source core propagates the transaction lock to all other cores in the mesh, thereby locking the rows in all cores.
4. An alert message with the conflict information is emailed to a user-configured mailing list. For more information, see Multimaster email alerts.
5. Both the source core and the destination core continue to the next transaction.

If either the source core or the destination core encounters an exception that prevents it from going to the next transaction, it sends an email to the user-configured mailing list describing the problem and shuts down.

To manually resolve conflicts and unlock the database rows, see Resolving mesh conflicts .

In general, when you resolve conflicts, apply updates so that the target always reflects the most current data based on the time stamp of the originating changes.

When you cannot follow one of the preceding guidelines, attempt to preserve the intent of the transaction. Contact the users who are generating the transactions and determine what types of changes in the managed environment each user was trying to make.