Cleaning up replication configuration
Bravura Security Fabric records the details of application nodes that are part of an instance, in its backend database in the "servicelist" table; each time a service starts (or stops gracefully) on a node, it updates its record in that table.
Scheduled jobs which are configured to run on specific application nodes are stored in the "schedrun" table and refer to those nodes by their "guid", an alphanumeric string like "e6bf36ad-2cb6-4347-9d8c-52154d8234e6" which can be found in the "servicelist" table mentioned above.
The configuration for the database service (iddb) is stored in each application node in the instance’s service\iddb.cfg file.
After changing replication configuration, it is recommended to verify in these three places that the change was as expected:
"servicelist" table should contain only the nodes currently in replication.
"This table can be emptied (on all databases involved), and then the Database Service has to be restarted on all remaining application nodes, to re-populate the table.
"schedrun" table should contain rows for only current node guids.
If there are rows with guids for any old nodes, they have to be deleted.
Before deleting rows, ensure that scheduled jobs assigned only to those old nodes are reassigned to other nodes (by updating the "guid" field on those rows).
All direct-to-DB changes like the ones above must be done separately on all databases.
iddb.cfg files on all app nodes must be checked to ensure the correct nodes are set to data-replicate.
Any incorrect configuration must be corrected.