Re: Mysterious DB reset

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Israel Brewster <israel(at)eraalaska(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Mysterious DB reset
Date: 2014-03-06 19:03:20
Message-ID: 5318C678.40106@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03/06/2014 10:43 AM, Israel Brewster wrote:
> On Mar 6, 2014, at 9:03 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)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!
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Israel Brewster 2014-03-06 19:09:54 Re: Mysterious DB reset
Previous Message Israel Brewster 2014-03-06 18:43:32 Re: Mysterious DB reset