Directing the Enforcer to an Alternate Host

The enforcer runs in a broker and compares the state of the domain against the requirements for the database . The enforcer starts additional processes as needed. When a host is experiencing a problem that prevents the enforcer from starting new database processes, the enforcer will continue to retry starting the process. This can be managed by the automation retry and back-off policy. This topic describes how to direct the enforcer to give up on a host and use an available, alternate host.

Here is an example of when you might need to direct the enforcer to give up on a host. Suppose you have a three (3) host domain and a minimally redundant database with two transaction engines (TEs) and two storage managers (SMs). On one of the hosts that is currently running a storage manager, there is a disk failure of some sort, perhaps the archive is no longer available for some reason or you no longer have write permission to it. The enforcer will continue to attempt to start the SM over and over again, even though the SM exits immediately. The enforcer will not automatically start an SM on the third available host. The database will remain in an UNMET state and will not be redundant.

On the host, where the SM is incurring errors and the SM retry loop is in effect, update the automation retry and back-off policy, to have some maximum retry value. Set stopOnMaxRetry to false in order to allow migration to a new host later.

At some point, the enforcer gives up on the SM on that host. Note that the SM maximum process scale out requirement considers known reachable or unreachable archive locations in the durable domain configuration and not just running SM processes. This is why you do not see a third SM starting up if SM_MAX=2. Now increment the template variable value SM_MAX=3: