Copyright (c) 2005 - 2017 Franz, Incorporated

Last updated 19 June 2017 at 15:32

• Documentation Index
  • Release Notes
  • Quick Start
  • Introduction
  • Setup and Configuration
    • Download
    • Server Installation
    • Server Configuration and Control
    • WebView
    • Database Upgrading
  • Server Management
    • Performance Tuning
    • Deleting Duplicate Triples
    • Purging Deleted Triples
    • Auditing
    • Replication
    • Point-in-Time Recovery
    • Transaction Log Archiving
    • Security Overview
    • Security Implementation
  • Tools
    • agtool
    • Data Loading
    • Data Export
    • Backup and Restore
    • Querying
    • RDFS++
    • Materializer
  • Details
    • AllegroGraph Indices
    • Full-text Indices
    • Encoded IDs
    • Connection Pooling
    • N-dimensional Geospatial Overview
    • 2-D Geospatial
    • Temporal
    • Social Network
    • JavaScript
    • Datatypes
    • Data Conversion (Rapper)
    • Stored Procedures
    • Triple Attributes
  • Querying
    • SPARQL documentation summary
    • SPARQL Reference
    • SPIN
    • SPARQL Magic Properties
    • Prolog
  • 3rd-party tools
    • Solr text Indices
    • MongoDB integration
    • Callimachus support
    • TopBraid Composer Plugin
    • Cloudera
  • Client APIs
    • Gruff
    • REST/HTTP interface
    • HTTP reference
    • Javadocs (Sesame and Jena)
    • Python API
    • Lisp Reference
    • JavaScript
  • Tutorials
    • N-dimensional Geospatial
    • SPARQL Tutorial
    • Java Sesame
    • Java Jena
    • Python Sesame
    • Lisp
    • Prolog
    • More...
  • Other
    • Suggested Reading
    • Conferences and Seminars
    • Source Code on Github
    • Community Resources
    • Amazon EC2
    • Copyrights
    • Change History
  • Franz, Inc.

Introduction

The AllegroGraph transaction log archiver is a built-in feature for managing transaction log files. Transaction logs are created in the directory specified by the TransactionLogDir configuration parameter (or the main database directory if TransactionLogDir is not specified). Unless they are moved or removed by the transaction log archiver, the number and total size of the transaction logs will grow without bound.

Configuration Parameters

The transaction log archiver is controlled by a set of catalog-specific configuration parameters. Configuration parameters are described in Server Configuration and Control.

TransactionLogRetain <action-name>

<action-name> is one of:

recovery - Transaction logs are deleted if not needed for the recovery process that is run when a database is opened. This will ensure that the newest transaction log with a checkpoint is retained and logs older than that are deleted. This is the default behavior starting in release 4.2.1.

archive - This is like action-name recovery except that instead of deleting transaction log files that are not needed, the unneeded files are moved to the directory specified by the TransactionLogArchive parameter.

replication - Like archive except that the transaction log archiver does not archive transaction logs until all replication jobs that might need them are finished with them. We discuss this below.

all - Keep all transaction logs in the main directory where they were created. (This was the default behavior in releases prior to 4.2.1 The new default behavior is recovery.)

TransactionLogArchive <directory>

Specifies the archive <directory> for transaction logs.

TransactionLogReplicationJobname <jobname>

This parameter can be given more than once. It specifies an important replication jobname. If TransactionLogRetain is set to replication then the transaction log archiver will hold off on archiving transaction logs needed by important replication jobs. If a replication jobname is not listed as important then the archiver may archive the log file before it can be used for replication and the replication will fail.

If the jobname is an asterisk (*) or this parameter is not given then all jobs are considered important.

Replication jobnames are set with the --jobname argument to agraph-replicate. See the Replication and Warm Standby document for more information.

Examples

The transaction log archiver is configured by parameters in the <Catalog> or <RootCatalog> sections of the agraph.cfg file. (For additional information about agraph.cfg, see the Server Configuration document.)

Here are examples of configuration entries for different scenarios. The examples show these entries being added to the root catalog.

If you don't care about replication or point-in-time recovery and just wish to keep the minimum number of transaction logs on the disk:

<RootCatalog>  
    TransactionLogRetain recovery  
    ....  
</RootCatalog>  

If you care about point-in-time restore and you want to save all transaction logs, use the following configuration.

<RootCatalog>  
    TransactionLogRetain archive  
    TransactionLogArchive /arch/root-tlogs/  
    ....  
</RootCatalog> 

If you care about point-in-time restore and replication, then use a configuration like the next example. Here we imagine two replication jobs we care about, one called second-repl and one called third-repl. A key detail here is that this retention mode assumes that replication will eventually be started, and so it effectively operates as mode all until that happens. You should not use this setting in a catalog containing repositories that aren't going to be replicated.

<RootCatalog>  
    TransactionLogArchive /arch/root-tlogs/  
    TransactionLogRetain replication  
    TransactionLogReplicationJobname second-repl  
    TransactionLogReplicationJobname third-repl  
    ...  
</RootCatalog> 

If you just went to keep all transaction logs with the database, thus allowing for point-in-time restore or replication, use the next example. The amount of space used in the database directory will continue to grow as more transaction logs are added and none are removed.

<RootCatalog>  
    TransactionLogRetain all  
    ....  
</RootCatalog>