public inbox for [email protected]help / color / mirror / Atom feed
Re: Export operation efficiency in read replica 5+ messages / 4 participants [nested] [flat]
* Re: Export operation efficiency in read replica @ 2025-03-20 12:58 Siraj G <[email protected]> 0 siblings, 2 replies; 5+ messages in thread From: Siraj G @ 2025-03-20 12:58 UTC (permalink / raw) To: Laurenz Albe <[email protected]>; +Cc: [email protected] Hello Laurenz As per my understanding coming to a proper conclusion wrt RPO with export operation is challenging. Eg., the export started at x and ended at z, the time stamp here for many data sets is different. Moreover, I do not think there is an incremental way available for export, correct? Please correct me if my understanding is wrong. Although I do agree the primary choice of backup to be storage based, we wanted to have export backups as well as a secondary. Concerning the impact taking export on read only.. Would you think we may run into recovery issues on the replica side or anything that would prevent the operation from being successful? Regards Siraj On Thu, Mar 20, 2025 at 5:29 PM Laurenz Albe <[email protected]> wrote: > On Thu, 2025-03-20 at 17:22 +0530, Siraj G wrote: > > I have a DB with 1TB in size serving needs of one of our critical > > applications. I have a requirement to take export of the DB on a > > daily basis, but want to carry out this operation in read replica. > > The postgresql version is: 16.6 > > > > What would be the RPO of such backup? > > Depends on the speed of disk and network and on what an RPO is. > > > What would be the impact on the READ REPLICA with a long running > > export operation? > > Potentially severe. > > You could look into storage technologies that allow you to take > a snapshot and clone it. > > Yours, > Laurenz Albe > ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Export operation efficiency in read replica @ 2025-03-20 14:04 Adrian Klaver <[email protected]> parent: Siraj G <[email protected]> 1 sibling, 1 reply; 5+ messages in thread From: Adrian Klaver @ 2025-03-20 14:04 UTC (permalink / raw) To: Siraj G <[email protected]>; Laurenz Albe <[email protected]>; +Cc: [email protected] On 3/20/25 05:58, Siraj G wrote: > Hello Laurenz > > As per my understanding coming to a proper conclusion wrt RPO You still have not defined what RPO is. -- Adrian Klaver [email protected] ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Export operation efficiency in read replica @ 2025-03-20 16:03 Laurenz Albe <[email protected]> parent: Siraj G <[email protected]> 1 sibling, 0 replies; 5+ messages in thread From: Laurenz Albe @ 2025-03-20 16:03 UTC (permalink / raw) To: Siraj G <[email protected]>; +Cc: [email protected] On Thu, 2025-03-20 at 18:28 +0530, Siraj G wrote: > As per my understanding coming to a proper conclusion wrt RPO with > export operation is challenging. Eg., the export started at x and > ended at z, the time stamp here for many data sets is different. > Moreover, I do not think there is an incremental way available for export, correct? You are talking about "pg_dump", right? A dump is always consistent, no matter how long it takes. But if you want to take a daily dump of a 1TB database, you are doing something wrong. You should change the requirements. Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Export operation efficiency in read replica @ 2025-03-21 13:52 Guillaume Lelarge <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 1 reply; 5+ messages in thread From: Guillaume Lelarge @ 2025-03-21 13:52 UTC (permalink / raw) To: [email protected] On 20/03/2025 15:04, Adrian Klaver wrote: > On 3/20/25 05:58, Siraj G wrote: >> Hello Laurenz >> >> As per my understanding coming to a proper conclusion wrt RPO > > You still have not defined what RPO is. > I guess the OP is talking about Recovery Point Objective, which is one of two important parameters WRT to disaster recovery. It's the maximum data loss you agree on with your backup solution. That mostly depends on the database context, something we can't tell. And according to how much you agree to lose (one minute of activity? one hour?), you then can choose between pg_dump or PITR backups. But with a 1TB-database, I wouldn't dare using pg_dump. PITR backup is the only option. -- Guillaume Lelarge Consultant https://dalibo.com ^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Export operation efficiency in read replica @ 2025-03-21 14:07 Siraj G <[email protected]> parent: Guillaume Lelarge <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Siraj G @ 2025-03-21 14:07 UTC (permalink / raw) To: Guillaume Lelarge <[email protected]>; +Cc: [email protected] Thank you everyone! On Fri, Mar 21, 2025 at 7:23 PM Guillaume Lelarge < [email protected]> wrote: > On 20/03/2025 15:04, Adrian Klaver wrote: > > On 3/20/25 05:58, Siraj G wrote: > >> Hello Laurenz > >> > >> As per my understanding coming to a proper conclusion wrt RPO > > > > You still have not defined what RPO is. > > > > I guess the OP is talking about Recovery Point Objective, which is one > of two important parameters WRT to disaster recovery. It's the maximum > data loss you agree on with your backup solution. That mostly depends on > the database context, something we can't tell. And according to how much > you agree to lose (one minute of activity? one hour?), you then can > choose between pg_dump or PITR backups. > > But with a 1TB-database, I wouldn't dare using pg_dump. PITR backup is > the only option. > > > -- > Guillaume Lelarge > Consultant > https://dalibo.com > > > ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-03-21 14:07 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-20 12:58 Re: Export operation efficiency in read replica Siraj G <[email protected]> 2025-03-20 14:04 ` Adrian Klaver <[email protected]> 2025-03-21 13:52 ` Guillaume Lelarge <[email protected]> 2025-03-21 14:07 ` Siraj G <[email protected]> 2025-03-20 16:03 ` Laurenz Albe <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox