| From: | John R Pierce <pierce(at)hogranch(dot)com> | 
|---|---|
| To: | pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: Monitoring Replication - Postgres 9.2 | 
| Date: | 2016-11-30 02:16:24 | 
| Message-ID: | c981fdb3-f2e0-3fe1-9e57-a7086b95a0b0@hogranch.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
On 11/29/2016 6:01 PM, Melvin Davidson wrote:
>
> There is no reason you can't execute a cron job on production to a 
> remote db.
>
> eg:
> contents of cron
> */5 * * * *      psql -U postgres -h 123.4.56.789 -d remote_db_name -f 
> /path_to/exec.sql
> ...
The OP wants to run queries on the master and the slave, and combine 
them.    Maybe the master could connect to the slave with dblink but I 
hate relying on that.
also, the perl/python script I'm envisioning would have some error 
handling, for instance, if a connection is broken, attempt to 
reconnect.   if the master is up and the slave is down, use NULL for the 
replication_delay since it can't be evaluated.   If the master is down 
after connection retries, panic.
since its using persistent connections, it could execute these queries 
more frequently and track min/max/average sample values over the 
duration of the logging interval.
etc/etc.
-- 
john r pierce, recycling bits in santa cruz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tobia Conforto | 2016-11-30 11:15:10 | About the MONEY type | 
| Previous Message | Melvin Davidson | 2016-11-30 02:01:17 | Re: Monitoring Replication - Postgres 9.2 |