rebuild queues

Rebuild stable queues to recover from a failed or missing partition.

Drop damaged partitions and replace them, if necessary, before you rebuild queues. A dropped partition may not actually be removed from the system until rebuild queues is executed.

rebuild queues disconnects all other Replication Servers from the Replication Server where it is executed. Connection attempts are refused until the queues are rebuilt.

rebuild queues clears all of the Replication Server’s stable queues, and “gives up” any damaged partitions in use.

If you start Replication Server in stand-alone mode (using the -M command line flag) and then execute rebuild queues, Replication Server goes into recovery mode.

While restoring messages to the rebuilt stable queues, Replication Server determines whether the data cleared from the queues was recovered or lost. Look for error messages in the log file of the Replication Server with the rebuilt queues and in the log files of Replication Servers that have direct routes from it. Loss detection may not complete immediately; it is necessary for new data to flow from each primary database or upstream site.

If loss is detected, you may need to re-create subscriptions or recover data from offline dumps.

If a subscription is materializing when you use rebuild queues, drop and re-create it. Even if the materialization appears to have completed successfully, some data may have been lost.

After queues are rebuilt, the Replication Server attempts to restore lost messages by requesting backlogged messages from Replication Servers that have routes to the current Replication Server.

You cannot rebuild queues for specific database connections or routes.