Search Postgresql Archives

RE: Replication: slave server has 3x size of production server?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





De: Adrian Klaver <adrian.klaver@xxxxxxxxxxx>
Enviado: sábado, 22 de fevereiro de 2020 15:50
Para: Edson Richter <edsonrichter@xxxxxxxxxxx>; pgsql-general <pgsql-general@xxxxxxxxxxxxxx>
Assunto: Re: Replication: slave server has 3x size of production server?
 
On 2/22/20 10:05 AM, Edson Richter wrote:
>     ------------------------------------------------------------------------
>
>     *De:* Adrian Klaver <adrian.klaver@xxxxxxxxxxx>
>     *Enviado:* sábado, 22 de fevereiro de 2020 14:33
>     *Para:* Edson Richter <edsonrichter@xxxxxxxxxxx>; pgsql-general
>     <pgsql-general@xxxxxxxxxxxxxx>
>     *Assunto:* Re: Replication: slave server has 3x size of production
>     server?
>     On 2/22/20 9:25 AM, Edson Richter wrote:
>     > Hi!
>     >
>     > I've a database cluster created at 9.6.10 linux x64 server rhel. I made
>     > progressive upgrades, first upgrading slave and then upgrading master.
>     > Actually both are running 9.6.17.
>     > Current production server has 196Gb in size.
>     > Nevertheless, the replicated (slave) server has 598 Gb in size.
>     > Replication server has 3x size of production server, is that normal?
>
>     How are you measuring the sizes?
>
>
> This is the command:
>
> du --max-depth 1 -h pgDbCluster
>
>
> Production:
>
> du --max-depth 1 -h pgDbCluster
>
> 56M     pgDbCluster/pg_log
> 444K    pgDbCluster/global
> 4,0K    pgDbCluster/pg_stat
> 4,0K    pgDbCluster/pg_snapshots
> 16K     pgDbCluster/pg_logical
> 20K     pgDbCluster/pg_replslot
> 61M     pgDbCluster/pg_subtrans
> 4,0K    pgDbCluster/pg_commit_ts
> 465M    pgDbCluster/pg_xlog
> 4,0K    pgDbCluster/pg_twophase
> 12M     pgDbCluster/pg_multixact
> 4,0K    pgDbCluster/pg_serial
> 195G    pgDbCluster/base
> 284K    pgDbCluster/pg_stat_tmp
> 12M     pgDbCluster/pg_clog
> 4,0K    pgDbCluster/pg_dynshmem
> 12K     pgDbCluster/pg_notify
> 4,0K    pgDbCluster/pg_tblspc
> 196G    pgDbCluster
>
>
> Slave:
>
> du -h --max-depth 1 pgDbCluster
>
> 403G    pgDbCluster/pg_xlog
> 120K    pgDbCluster/pg_log
> 424K    pgDbCluster/global
> 0       pgDbCluster/pg_stat
> 0       pgDbCluster/pg_snapshots
> 4,0K    pgDbCluster/pg_logical
> 8,0K    pgDbCluster/pg_replslot
> 60M     pgDbCluster/pg_subtrans
> 0       pgDbCluster/pg_commit_ts
> 0       pgDbCluster/pg_twophase
> 11M     pgDbCluster/pg_multixact
> 0       pgDbCluster/pg_serial
> 195G    pgDbCluster/base
> 12M     pgDbCluster/pg_clog
> 0       pgDbCluster/pg_dynshmem
> 8,0K    pgDbCluster/pg_notify
> 12K     pgDbCluster/pg_stat_tmp
> 0       pgDbCluster/pg_tblspc
> 598G    pgDbCluster

So the WAL logs are not being cleared.

What replication method is being used?

What are the settings for the replication?

Streaming replication. Initiated via pg_basebackup.

Settings on master server:

# - Sending Server(s) -
# Set these on the master and on any standby that will send replication data.
max_wal_senders = 2             # max number of walsender processes (change requires restart)
wal_keep_segments = 25          # in logfile segments, 16MB each; 0 disables
#wal_sender_timeout = 60s       # in milliseconds; 0 disables
max_replication_slots = 2       # max number of replication slots (change requires restart)
#track_commit_timestamp = off   # collect timestamp of transaction commit (change requires restart)
# - Master Server -
# These settings are ignored on a standby server.
#synchronous_standby_names = '' # standby servers that provide sync rep number of sync standbys and comma-separated list of application_name from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is delayed



Settings on slave server:

# - Standby Servers -
# These settings are ignored on a master server.
hot_standby = on                        # "on" allows queries during recovery (change requires restart)
max_standby_archive_delay = -1          # max delay before canceling queries when reading WAL from archive; -1 allows indefinite delay
max_standby_streaming_delay = -1        # max delay before canceling queries when reading streaming WAL; -1 allows indefinite delay
wal_receiver_status_interval = 10s      # send replies at least this often 0 disables
hot_standby_feedback = on               # send info from standby to prevent query conflicts
wal_receiver_timeout = 0                # time that receiver waits for communication from master in milliseconds; 0 disables
wal_retrieve_retry_interval = 5s        # time to wait before retrying to retrieve WAL after a failed attempt


Regards,

Edson

>
>
> Edson
>

--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux