000025512 - How to perform a consistently successful replica package distribution

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000025512
Applies ToPush DB
RSA ACE/Server 5.0.x (no longer supported as of 8-15-2004)
RSA ACE/Server 5.1 (no longer supported as of 7-14-2006)
RSA ACE/Server 5.1.1 (no longer supported as of 7-14-2006)
RSA ACE/Server 5.2
IssueHow to perform a consistently successful replica package distribution
ResolutionFollow these steps to perform a consistently successful replica package distribution:

NOTE 1: Only attempt to automatically push a new database to servers which have successfully reconciled at least once

NOTE 2: Do not try to automatically push a replica package after performing a database merge

Steps for Automatic Push DB:

1. Delete the /ace/data/replica_package directory

2. Start ACE administration and make sure that "allow automatic push-db" is enabled.

3. Stop ACE Administration

4. Stop the ACE database brokers

5. Create the replica_package

6. Restart the ACE/Server

7. Add a test user in ACE Administration and verify the user is copied to the replica servers. If this procedure fails, then follow the Manual Distribution procedure below.

Steps for Successful Manual Distribution of a replica_package:

1. Make sure that allow push-db is activated in ACE/Administration

2. Stop the Primary ACE/Server

3. If there are no Agent Hosts assigned to the replica as Acting Master or Acting Slave, remove the replica from the replica table

4. Re-add the replica to the replica table

NOTE: The decision to remove a replica from the replica table in the first pass is strictly dependant on whether the time and effort to reassign Acting Master / Acting Slave designations is greater than the time and effort of re-performing the push. Sometimes it is necessary to remove the replica from the replica table to re-establish replication. RSA's experience is that this is required about 20 percent of the time. There are a number of causes, including license/encryption mismatch, version mismatch, catastrophic failure, interrupting a Push DB before it has completed successfully.

5. Generate a new replica package

6. In the /ace/data/replica_package/license directory, edit the sdrepnodes.txt file and you should see the hostname of the replicas which the package is good for and other data. If you do not see data here, it is probable that you have failed to have the allow push-db assisted recover switch enabled in ACE administration when you generated the package. Reconciliation will fail if this file is not valid.

7. Start ACE administration ONLY and disable automatic Push DB. On UNIX, sdconnect start (ONLY - no aceserver start) > sdadmin , on NT DO NOT start the ACE/Server. Next, with the ACE/Server completely stopped, open a Host-Mode administration session.

8. Start the ACE/Server Primary

9. Stop the Replica

10. Copy the contents of /ace/data/replica_package/license and  /ace/data/replica_package/database directories to the replica's /ace/data directory

11. Run configuration management on Windows (sdsetup -config on UNIX). Change the THIS SERVER value to the identity of the replica.

12. If this fails for any replica you did not remove from the Replica Table, make a note of which Agent Hosts have Acting Master or Acting Slave designations, and for which Replicas. You must rerun the procedure and remove that replica from the replica table this time.

Once you have removed and re-added the replicas from the replica table, you must use ACE administration to reassign the Acting Master Acting Slave designations. Acting Master and Acting Slave associations are removed from Agent Hosts when the replica is removed from the replica table to ensure referential integrity of the database.

If this procedure fails, check the system logs for indications of why you are failing to replicate. You probably have one of the following issues:

- version mismatch
- network communications
- name resolution
Legacy Article IDa15720