Greetings,
* Ghislain ROUVIGNAC (g...@sylob.com) wrote:
> Our application don't write lot of data, so i don't think the time taken on
> replaying the WAL will be an issue for us.
That certainly makes things simpler.
Then again, if you are not writing a lot of data then you might consider
using s
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> Stephen Frost wrote:
> > The downside with any snapshot-style approach is that it means that when
> > you have a failure, you have to go through and replay all the WAL since
> > the last checkpoint, which is single-threaded and can take
Stephen,
Our application don't write lot of data, so i don't think the time taken on
replaying the WAL will be an issue for us.
For reliability, as you said, i was thinking in running a large pgbench
which writes a lot of data, while taking snapshots.
Then my idea was to restart from snapshots
Stephen Frost wrote:
> The downside with any snapshot-style approach is that it means that when
> you have a failure, you have to go through and replay all the WAL since
> the last checkpoint, which is single-threaded and can take a large
> amount of time.
>
> When doing your testing, I'd strongly
Greetings,
* Ghislain ROUVIGNAC (g...@sylob.com) wrote:
> Portworx says that on a running PostgreSQL it can:
>
>- replicate volumes for failover
>- take snapshots of volumes
>- backup volumes
The downside with any snapshot-style approach is that it means that when
you have a failure,
Hello,
We are working on integrating portworx on kubernetes as our volume provider
for PostgreSQL.
Portworx says that on a running PostgreSQL it can:
- replicate volumes for failover
- take snapshots of volumes
- backup volumes
There are some articles describing these capabilities:
