What are the different transaction log options available with DXgrid?

Products

• CA Directory
• CA Security Command Center
• CA Data Protection (DataMinder)
• CA User Activity Reporting

Issue/Introduction

Description:

There are three different transaction log operating modes. Each state has it's own benefits, and each customer needs to fully understand and test each of the three transaction log modes in order to see which configuration works for them.

Solution:

CA Directory r12.0SP1 has a proprietary datastore technology known as "DXgrid". This datastore has a transaction log feature, that is used by the DSA to recover transactions that have not been written to the DXgrid datastore file after a failure. The transaction log is used in much the same way as a relational database uses a journal file.

The CA Directory DXgrid transaction log has three operating modes. Each mode will affect how the transaction log is used by the DSA. See below for an explanation of each mode, and the configuration parameter used to set the respective mode.

The transaction log can be operated in one of the following modes:

1. Synchronously flushed to disk: This mode is where the transaction log is enabled and EVERY write operation processed by the DSA is flushed to disk immediately before the write confirmation is sent to the LDAP client. This is the default state for the transaction log mechanism. No configuration change needs to be made to enable this mode. This guarantees that a data DSA can recover even after a machine or OS failure. This is suggested for environments which are expected to support a write/modify performance of at most a few hundred updates per second (performance metrics will vary depending on disk speed) and may not be closely monitored by system administrators for failure.
   
   
2. Flushing of the transaction log is disabled: This is where the transaction log is enabled, but updates are NOT immediately flushed to disk. The flushing of the transaction log is performed by the operating system independently of the DSA. Writes that are confirmed by the DSA may not be written to disk straight away. This guarantees that a data DSA can recover when a DSA fails (e.g. core dumps) but does not guarantee recovery on a machine or OS failure. This may be considered for environments which are expected to support a write/modify performance of thousands of updates per second (performance metrics will vary depending on disk speed) and is closely monitored by system administrators for failure.
   
   To enable this mode, add the following configuration command to the data DSA's initialization (.dxi) file:
   
   set disable-transaction-log-flush = true;
   
   
3. Total disabling of transaction log: This is where the transaction log is disabled completely. A customer would rely on MW-DISP recovery or a manual synchronization of data in the event of a server crash as there is no guarantee of recovery on data DSA, machine or OS failure, but provides optimal write/modify performance. This is suggested for environments which are expected to support very high volume concurrent write/modify performance of many thousands of updates per second (performance metrics will vary depending on disk speed) and is closely monitored by system administrators for failure.
   
   To enable this mode, add the following configuration command to the data DSA's initialization (.dxi) file:
   
   set disable-transaction-log = true;
   
   Once the configuration change is made, stop and start the DSA to activate the change.
   
   Please refer to TEC479507 (CA Directory r12 Data Replication and Recovery Best Practice) for more detailed information.

Environment

Release:
Component: ETRDIR