Re: Archiving Data to Another DB?

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Archiving Data to Another DB?
Date: 2018-04-11 17:37:08
Message-ID: 0581fbc0-f85e-5a46-3b04-98eda54bd481@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 04/11/2018 10:24 AM, Ron wrote:
>
>
> On 04/11/2018 11:15 AM, Don Seiler wrote:
>> Let's say I have two DBs: main (9.6.6) and archive (10.2).
>>
>> I have a table in main where I want to archive data older then 60
>> days. For various reasons, the table is not partitioned, so for now
>> we must use DELETE. The destination table in the archive DB is
>> partitioned with the new Pg10 partitioning.
>>
>> My initial plan was to have a stored procedure on the archive DB use
>> postgres_fdw to do an INSERT INTO / SELECT to select the data
>> remotely and insert into the local archive table. It would then issue
>> a single DELETE command to remotely remove the data from the main DB.
>> However I found that doing this resulted in the main DB calling
>> thousands (perhaps millions if it's one-per-row) of individual DELETE
>> statements based on a ctid column. Aside from WAL behavior concerns,
>> it is flooding my postgresql server logs since I log any DML.
>>
>> On top of that, I'm told that a remote DELETE wouldn't be
>> transactional, so if I were to compare inserted rows vs deleted rows
>> and found a mismatch, I couldn't just rollback the DELETE. I plan to
>> verify this with a small test case later but for now I'll assume this
>> to be true.
>>
>> Right now I'm thinking of falling back to the far-less-elegant method
>> of dumping the data to a flat file via COPY, running psql to connect
>> to the archive DB remotely and running a COPY to load the data (or
>> maybe transferring the flat file to the archive DB to load it there,
>> offloading that part of the workload), then deleting the data from
>> the main DB. I could capture the rows dumped in a control table and
>> compare the rows deleted against that and then rollback the delete if
>> necessary.
>>
>> Like I said, not elegant, but I don't want to risk losing data that
>> wasn't successfully archived to the archive DB. I'm very interested
>> to hear what others might be doing for tasks like this.
>
> It might not be elegant, but a COPY / DELETE / LOAD is granular, so
> you can restart at any point.
>
>
I might be inclined to COPY/LOAD/check/DELETE

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2018-04-11 17:58:10 Re: Archiving Data to Another DB?
Previous Message David G. Johnston 2018-04-11 16:37:45 Re: Archiving Data to Another DB?