4.4. Log Shipping - Slony-I with Files

4.4.1. Usage Hints

• You don't want to blindly apply SYNC files because any given SYNC file may not be the right one. If it's wrong, then the result will be that the call to setsyncTracking_offline() will fail, and your psql session will ABORT, and then run through the remainder of that SYNC file looking for a COMMIT or ROLLBACK so that it can try to move on to the next transaction.

  But we know that the entire remainder of the file will fail! It is futile to go through the parsing effort of reading the remainder of the file.

  Better idea:

  • The table, on the log shipped node, tracks which log it most recently applied in table sl_archive_tracking.

    Thus, you may predict the ID number of the next file by taking the latest counter from this table and adding 1.

  • There is still variation as to the filename, depending on what the overall set of nodes in the cluster are. All nodes periodically generate SYNC events, even if they are not an origin node, and the log shipping system does generate logs for such events.

    As a result, when searching for the next file, it is necessary to search for files in a manner similar to the following:

    ARCHIVEDIR=/var/spool/slony/archivelogs/node4
    SLONYCLUSTER=mycluster
    PGDATABASE=logshipdb
    PGHOST=logshiphost
    NEXTQUERY="select at_counter+1 from \"_${SLONYCLUSTER}\".sl_archive_tracking;"
    nextseq=`psql -d ${PGDATABASE} -h ${PGHOST} -A -t -c "${NEXTQUERY}"
    filespec=`printf "slony1_log_*_%20d.sql"
    for file in `find $ARCHIVEDIR -name "${filespec}"; do
       psql -d ${PGDATABASE} -h ${PGHOST} -f ${file}
    done

4.4.2. find-triggers-to-deactivate.sh

It was once pointed out ( Bugzilla bug #19) that the dump of a schema may include triggers and rules that you may not wish to have running on the log shipped node.

The tool tools/find-triggers-to-deactivate.sh was created to assist with this task. It may be run against the node that is to be used as a schema source, and it will list the rules and triggers present on that node that may, in turn need to be deactivated.

It includes logtrigger and denyaccess triggers which will may be left out of the extracted schema, but it is still worth the Gentle Administrator verifying that such triggers are kept out of the log shipped replica.

4.4.3. slony_logshipper Tool

As of version 1.2.12, Slony-I has a tool designed to help apply logs, called slony_logshipper. It is run with three sorts of parameters:

• Options, chosen from the following:

  • h

    display this help text and exit

  • v

    display program version and exit

  • q

    quiet mode

  • l

    cause running daemon to reopen its logfile

  • r

    cause running daemon to resume after error

  • t

    cause running daemon to enter smart shutdown mode

  • T

    cause running daemon to enter immediate shutdown mode

  • c

    destroy existing semaphore set and message queue (use with caution)

  • f

    stay in foreground (don't daemonize)

  • w

    enter smart shutdown mode immediately

• A specified log shipper configuration file

  This configuration file consists of the following specifications:

  • logfile = './offline_logs/logshipper.log';

    Where the log shipper will leave messages.

  • cluster name = 'T1';

    Cluster name

  • destination database = 'dbname=slony_test3';

    Optional conninfo for the destination database. If given, the log shipper will connect to this database, and apply logs to it.

  • archive dir = './offline_logs';

    The archive directory is required when running in "database-connected" mode to have a place to scan for missing (unapplied) archives.

  • destination dir = './offline_result';

    If specified, the log shipper will write the results of data massaging into result logfiles in this directory.

  • max archives = 3600;

    This fights eventual resource leakage; the daemon will enter "smart shutdown" mode automatically after processing this many archives.

  • ignore table "public"."history";

    One may filter out single tables from log shipped replication

  • ignore namespace "public";

    One may filter out entire namespaces from log shipped replication

  • rename namespace "public"."history" to "site_001"."history";

    One may rename specific tables.

  • rename namespace "public" to "site_001";

    One may rename entire namespaces.

  • post processing command = 'gzip -9 $inarchive';

    Pre- and post-processing commands are executed via system(3).

  An "@" as the first character causes the exit code to be ignored. Otherwise, a nonzero exit code is treated as an error and causes processing to abort.

  Pre- and post-processing commands have two further special variables defined:

  • $inarchive - indicating incoming archive filename

  • $outnarchive - indicating outgoing archive filename

• error command = ' ( echo "archive=$inarchive" echo "error messages:" echo "$errortext" ) | mail -s "Slony log shipping failed" postgres@localhost ';

  The error command indicates a command to execute upon encountering an error. All logging since the last successful completion of an archive is available in the $errortext variable.

  In the example shown, this sends an email to the DBAs upon encountering an error.

• Archive File Names

  Each filename is added to the SystemV Message queue for processing by a slony_logshipper process.