Error: "2913: Replication failed" and replication of database profile to the Cloud Detection Server fails

book

Article ID: 195506

calendar_today

Updated On:

Products

Data Loss Prevention Cloud Detection Service Data Loss Prevention Cloud Service for Email Data Loss Prevention Data Loss Prevention Cloud Package

Issue/Introduction

Replication fails when indexing EDMs, IDMs, or LDAP, and you see the following error in the console:

Code: 2913
Summary: Replication failed
Detail: Replication of database profile "NAME_of_Profile" version X to server failed. Please re index the profile. Check the detection server controller log for more details.

Looking at the Index and Replication Status details for the index indicated, all on-premise Detection Servers have successfully received the latest version.

However, any DLP Cloud Detection Server (CDS) is not receiving the latest version, if any, and shows as being one or more versions behind the other servers.

Cause

There are frequently a few issues for Index replication to the CDS. Before proceeding, confirm that the profiles are as "error-free" as possible. For an LDAP index (of a Directory Connection), that means having little or no bad entries in Active Directory.

Starting in DLP 15.1, these error thresholds are configurable, as per the following entries in the Indexer.properties file on DLP Enforce:

First entry:

# The percentage of corrupted and ignored records allowed for active directory index 
com.vontu.profiles.directoryconnection.index.corruption.error.threshold=0

Second entry:

# Number of attempts to reconnect to active directory service
com.vontu.profiles.directoryconnection.reconnect.retries=0

For EDM and IDM profiles, the error threshold is configurable in the profile itself; increasing this threshold may resolve the issues.

For an EDM index, in particular, there should be a low percentage of errors with respect to the number of rows in the profile; the default is 1%. 

Note: If the server in question is a newly enrolled DLP Cloud Detection Server, the indexing process has to be free of errors. See New Cloud Detection or Cloud Email server added to DLP is not detecting data uploads or accepting emails.

Environment

  • Release: 15.x
  • Component: DLP Enforce, but specifically with Cloud Detection Service

Resolution

First issue - index files are corrupt or missing

When index files are corrupt and/or missing, according to what "should" be replicated, ensure that EDM information in the DB corresponds to the indexed files on the file system.

  1. Execute this query from Enforce as the "protect" user:
      select infosourceid, version, filesize, NUMBEROFSUBINDEXES from INDEXEDINFOSOURCE order by infosourceid, version desc;
  2. Compare the results of this query with the index files in the file system, which are located in the index folder.

Second issue - "is_active" index setting (database problem)

A bug was found in DLP 14.6 wherein the "is_active" flag for the latest version of a specific index is not set correctly, having more than one version indicated as being the latest or "active" index. This causes replication failures, but only for indexes being replicated to Cloud Detectors.

A symptom of this database issue is that new indexes created against the same profile or Directory Connection will work initially, but subsequent re-indexing will fail with the errors noted above.

To address this issue, execute the appropriate query from DLP Enforce, as "protect" user:

For Directory Connection index:

Select dcs.name as Connection_Name, iis.infosourceid as Source_ID, iis.version as Index_Version, iis.isactive as Is_Active
from indexedinfosource iis
join directoryconnectionsource dcs ON iis.infosourceid = dcs.infosourceid
where iis.isactive = 1
order by connection_name, index_version, is_active;

For an EDM:

Select ds.name as EDM_Name, iis.infosourceid as Source_ID, iis.version as Index_Version, iis.isactive as Is_Active
from indexedinfosource iis
join datasource ds ON iis.infosourceid = ds.infosourceid
where iis.isactive = 1
order by edm_name, index_version, is_active;

For an IDM

Select ds.name as IDM_Name, iis.infosourceid as Source_ID, iis.version as Index_Version, iis.isactive as Is_Active
from indexedinfosource iis
join docsource ds ON iis.infosourceid = ds.infosourceid
where iis.isactive = 1
order by idm_name, index_version, is_active;

If the same SourceID (EDM or other index) has more than one "active" index against multiple versions of the index, the last column for ALL versions of that index will have “1”. This indicates that the state is set to "is_active", which confirms the problem.

If this is confirmed, please open a case with Technical Support, as there will be a fix for this issue in a future release of DLP.