On 03/06/2014 10:43 AM, Israel Brewster wrote:
On Mar 6, 2014, at 9:03 AM, Adrian Klaver <adrian.kla...@aklaver.com> wrote:
Well something is happening. See my notes on logging below to help track down
the cause.
Yep.
Might be good to explain your archive setup.
Ok, here goes: We have the primary system which receives the data and handles
all requests for said data. There is also a hot standby server keep in sync
with streaming replication. The WALs are archived to a NFS share on this
machine.
Once an hour a python script runs that a) Selects all unsynced records from the
postgresql db, b) stores a subset of them in our permanent archive, and c)
marks the previously selected records as synced (UPDATE data SET syncd=true
WHERE id in (...) )
Additionally, I have a) a script that runs at 8:00pm every evening that uses
pg_dump to dump the contents of the database to a backup file, and b) a script
that runs at 8:00 each morning that rsync's various config files and scripts
(such as my data retrieval scripts) from the primary machine to a backup
location on the secondary machine.
None of the scripts run anywhere near the apparent 4:40ish cutoff time for my
data
Are all the scripts running from one machine?
If so, have you checked that the times are set correctly on the various
machines?
Make sense? Probably not the best setup, but then that's what happens when you
figure out stuff for yourself rather than having formal training :-) I'm
DEFINITELY open to suggestions :-)
'Makes sense' is context sensitive. It really depends on what you want
to achieve. My procedure is to define the end result first and then work
backwards from there.
I'll get those in the config, and we'll see what happens tomorrow morning.
Hopefully that will give more information. Thanks for the link and information!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
