DSA Replication broken - IVR_IMPORTED_CVE_FIXLET_MAP lock timeout blocking FillDB

Usage and Config Platform
1

Hi everyone,

I'm currently dealing with an issue where our DSA replication connection has broken and FillDB is getting completely locked up. I'm hoping someone here might have run into this before.

The Problem: In the BigFix Administration Tool under the Replication tab, the primary server shows <connection broken>.

When reviewing the FillDB.log, we are seeing a constant stream of timeouts specifically for a massive vulnerability mapping table:

Error: Replication failed for server 'XXX': A replication lock request for IVR_IMPORTED_CVE_FIXLET_MAP (Exclusive) timed out.

The Impact: Because FillDB is stuck trying to replicate this large table, it is causing a severe traffic jam for standard client reporting. Further down in the FillDB.log, we can see normal endpoint data getting blocked:

A replication lock request for COMPUTER_REGISTRATIONS (Exclusive) timed out. A replication lock request for COMPUTERS (Exclusive) timed out. Unable to parse chunk of compressed file in buffer; discarding chunk.

Because of this lock, our endpoints cannot process their updated status into the database.

What we are currently trying:

  1. Increasing the ReplicationTimeout in BESAdmin Advanced Options (e.g., to 1200 or 1800 seconds) and restarting FillDB.

  2. Verifying that SQL Server and the ODBC DSNs on both servers are explicitly configured to use TCP/IP instead of Named Pipes for faster data transfer.

My Question for the Community: Has anyone else experienced this persistent replication lock on IVR_IMPORTED_CVE_FIXLET_MAP?

If increasing the timeout doesn't push the transfer through, is there a specific SQL command, setting, or alternative method to safely clear this lock and force the replication to complete so FillDB can process normal client reports again?

Any advice or insight would be greatly appreciated!

2

These are not errors, are part of the normal replication activity and can never totally disappear.

Just means that is performed an activity ( run an action, a client is registering, … ) on a server is in the meantime attempting to replicate from the database of another server … one of the two activities can win, the second must lose … and what has been supposed have to lose is the replication activity … this because once the next replication activity will be performed the replication continue with the stuff is still to replicate and nothing is lost or impacted because the interruption tracked with that warning message …

The only thing can be done in these scenario, is useful especially the first replication has never completed, can be add the UnInterruptibleReplicationSeconds settings increasing the timeout with which the FillDB wait before to fail … see the following tech note for details:

2 Likes
3

Hi @gpoliafico,

Thank you so much for this detailed explanation! This perfectly clears up what we were seeing in the logs.

It makes complete sense that the local endpoint traffic was constantly interrupting the replication, especially since the IVR_IMPORTED_CVE_FIXLET_MAP table was so massive and needed more time than usual to cross over.

I really appreciate you taking the time to break down the mechanics behind this—it was exactly what we needed to push past the bottleneck. Thanks again!