Обсуждение: COPY write load on primary impacting replica?
Hi: I have an issue where a big big big COPY is thrashing a disk on a DB, my idea was to fire up a read replica of this DB and point my users to it for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage caused by COPY on the primary.
Wondering if this is foolish, whether the WAL log stuff would cause equal disk usage on the replica.
Why not make the COPY in small batch and intervals of seconds between them?!
Like COPY 10000 and wait 60 seconds for another batch.
On Wed, 19 Jan 2022 at 22:28 Wells Oliver <wells.oliver@gmail.com> wrote:
Hi: I have an issue where a big big big COPY is thrashing a disk on a DB, my idea was to fire up a read replica of this DB and point my users to it for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage caused by COPY on the primary.Wondering if this is foolish, whether the WAL log stuff would cause equal disk usage on the replica.Thanks!
Licio Matos
On Wed, 2022-01-19 at 17:27 -0800, Wells Oliver wrote: > Hi: I have an issue where a big big big COPY is thrashing a disk on a DB, > my idea was to fire up a read replica of this DB and point my users to it > for SELECT (read) operations, thereby hopefully (?) avoiding the disk usage > caused by COPY on the primary. > > Wondering if this is foolish, whether the WAL log stuff would cause equal > disk usage on the replica. That is a feasible idea. Make sure to set "max_standby_streaming_delay" high enough that COPY won't get canceled. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com