====Slony Trouble====

If updates aren't going through, check that external hosts can connect through ssh tunnel
%%telnet 127.0.0.1 20001 
psql -h 127.0.0.1 -p20001 -Upgsql pvsadmin%%

If the connection hangs, then tunnel probably needs to be restarted from poprocks
%%systemctl restart tunnel-out%%

monitor slon progress by tailing logs
%%tail -F /var/lib/pgsql/9.2/data/pg_log/postgresql-* | grep slon%%

Check current slon progress.  Each needs to run on their respective master DBs.
%%SELECT * FROM _admin_cluster.sl_status;
SELECT * FROM _whitefront_cluster.sl_status;%%

When at a total loss, try restarting slon, it can't hurt...
%%systemctl restart slony_admin
systemctl restart slony_whitefront%%

===== Unverified =====

Use the 'SYNC # processing' to gage where the slave is at, compare to _admin_cluster.sl_event.ev_seqno.  This is a simple counter.

If slony failed while doing a slonik command involving ALTER/DROP TABLE, then check for deadlocks in /var/log/messages.  If deadlocks are present, restart postgresql on deadlocked host. It's not a great idea to do DDL type commands while postgresql is doing a lot of write traffic, because of how slony messes with internals, so save such commands after hours or with admin down. 

Continued log entries like "Slony-I: log switch to sl_log_2 still in progress - sl_log_1 not truncated" indicate that something is holding up the log switch - logs will not switch unless the nodes are in sync. If this has happened right after a slony upgrade, then make sure slony functions on all nodes have been updated. Otherwise, check the above (tunnel, logs, etc.)

----
CategoryITMisc