slony_logshipping(1)

✨ NAME ✨

slony_logshipping — the slony_logshippping daemon 💖 (yes bestie, that's three p's, that's canon, we do not touch it)

---

🦋 slony_logshipper TOOL 🦋

okay so slony_logshipper is this icon tool that's literally built to help apply logs. it runs as a daemon and it just sits there scanning the archive directory for new .SQL files, and then it applies them to the target database. main character behaviour fr fr. 💅

it can be run with three sorts of parameters:

---

🎀 OPTIONS 🎀

• 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 config file is made up of the following specs, and every single one of them matters:

• 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 you give it, 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, so it has 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";

you can filter out single tables from log shipped replication

• ignore namespace "public";

you can filter out entire namespaces from log shipped replication

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

you can rename specific tables.

• rename namespace "public" to "site_001";

you can 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. iconic, honestly.

• Archive File Names

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

---

no cap: everything above is exactly what the page says — same options, same config keys, same variables, same warnings. we did not edit, merge, or invent a single one. 💖

sign-off time, bestie 🫶 — this whole thing lives in the Slony-I 2.2.11 Documentation set (that's the source + version, right there), and it was dated 19 September 2024. and yes, the page is literally called slony_logshipping(1). slay. ✨🌈👑