Aiven-Open / Aiven-Open/pghoard

partial WAL files with recovery

Aperta
#147 3 commenti 1 reazione 0 assegnatari Vedi su GitHub
Lingua principale
Python
Stelle
1.4k
Fork
111
Merge medio
1g 5h
PR unite (30g)
2

Descrizione

I'm currently playing/testing with pghoard in Docker (thank you guys to open source this work) and it seems that for now pgboard is not yet able to transparently manage .partial file (this is also a [limitation of Barman](http://docs.pgbarman.org/release/1.6.1/#limitations-of-partial-wal-files-with-recovery)). Of course users can manually copy the latest partial file (making sure that the .partial suffix is removed) to the destination for recovery. In my case (testing only on S3) I made a simple:

```
cp /data/site/xlog_incoming/xy.partial /data/site/xlog_incoming/xy
```

and once the restoration is complete, I remove this file to the destination (my S3 bucket) to allow pg_receivexlog to continue streaming transaction log if the goal was just to grab a consistant copy/snapshot of the PG cluster at a specific timestamp/txid.

I wondered if eventually it would be a good idea to automate this process and add a third remote directory called e.g. xlog-partial to upload this .partial file every X seconds or manually force a synchronization via `pghoard_archive_sync`? This way the download process could also look to see if a file .partial exists in this directory to recover this partial WAL through the `pghoard_postgres_command`.

In case of a crash of the server where pghoard is running, we'll lose only the X seconds between two .partial file upload.

What do you think? Perhaps there is already a way/plan to do this?

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.