Copyright (c) 2005 - 2016 Franz, Incorporated

Last updated 19 February 2016 at 16:24

• 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
    • 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
  • 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 utility for managing transaction log files. Transaction logs are created in the main database directory. Unless they are moved or removed by the transaction log archiver, the 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 a transaction log archive directory . (See 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. (It is best if the archive is on the same filesystem as the actual database. That way the transaction logs can be moved rather than copied. Unfortunately, this is not always possible.)

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

If you care about point-in-time restore and replication, then use a setting like the next example. Here we imagine two replication jobs we care about, one called second-repl and one called third-repl. This will keep the space on the database disk to a minimum as unneeded transaction logs are archived.

<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 need for space on the database disk will continue to grow as more transaction logs are added and none are removed.

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