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: | Raw Message | Whole Thread | 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 |