Re: Archiving Data to Another DB?
От | Ron |
---|---|
Тема | Re: Archiving Data to Another DB? |
Дата | |
Msg-id | b7757e4a-1378-7876-5940-5342bb9e6140@gmail.com обсуждение исходный текст |
Ответ на | Archiving Data to Another DB? (Don Seiler <don@seiler.us>) |
Ответы |
Re: Archiving Data to Another DB?
|
Список | pgsql-general |
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. -- Angular momentum makes the world go 'round.
В списке pgsql-general по дате отправления: