Deleting replication slot on slave resolve the issue, now WAL-files
removing automaticaly ! Thanks a lot for your answers !
ср, 17 мар. 2021 г. в 10:59, Andrew Anderson :
> But maybe there is a way to fix this ? Rebuilding slave from master with
> erasing ${PGDATA} on slave does not help.
>
> вт,
But maybe there is a way to fix this ? Rebuilding slave from master with
erasing ${PGDATA} on slave does not help.
вт, 16 мар. 2021 г. в 16:56, Laurenz Albe :
> On Tue, 2021-03-16 at 16:11 +0200, Andrew Anderson wrote:
> > postgres=# show wal_keep_segments;
> > wal_keep_segments
> >
So, right now I have configuration of replication slots:
On master:
postgres=# select * from pg_replication_slots ;
slot_name | plugin | slot_type | datoid | database | temporary |
active | active_pid | xmin | catalog_xmin | restart_lsn |
confirmed_flush_lsn
--++--
Andrew Anderson writes:
>> What's using it?
> As I think, streaming replication is using this slot. Does anybody know how
> to fix it ?
Unless you need another replica that's downstream of the standby,
you should not be maintaining a replication slot on the standby.
There may be a way to have a
You're right, restart_lsn on slave does not changes.
> What's using it?
As I think, streaming replication is using this slot. Does anybody know how
to fix it ?
вт, 16 мар. 2021 г. в 17:44, Tom Lane :
> Andrew Anderson writes:
> >> - replication slot (you said that is not it)
>
> > The replicatio
Andrew Anderson writes:
>> - replication slot (you said that is not it)
> The replication slot is the same on master:
> postgres=# select * from pg_replication_slots ;
> slot_name | plugin | slot_type | datoid | database | temporary |
> active | active_pid | xmin | catalog_xmin | restart_
On Tue, 2021-03-16 at 16:11 +0200, Andrew Anderson wrote:
> postgres=# show wal_keep_segments;
> wal_keep_segments
> ---
> 32
> (1 row)
Ok, then I am out of ideas.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
> - replication slot (you said that is not it)
The replication slot is the same on master:
postgres=# select * from pg_replication_slots ;
slot_name | plugin | slot_type | datoid | database | temporary |
active | active_pid | xmin | catalog_xmin | restart_lsn |
confirmed_flush_lsn
On Tue, 2021-03-16 at 15:31 +0200, Andrew Anderson wrote:
> вт, 16 мар. 2021 г. в 14:21, Laurenz Albe :
> > On Tue, 2021-03-16 at 09:49 +0200, Andrew Anderson wrote:
> > > 2021-03-16 09:44:03.997 EET [97581] [] [] [] []DEBUG: attempting to
> > > remove WAL segments older than log file 000
In pg_wal catalog there is no file by that name:
$ ls pg_wal/ | grep 013E0097
$
but there is files with very old time of creation:
$ ls -lart pg_wal/
total 30933220
-rw--- 1 postgres postgres 299 Dec 30 05:44
0002013E0097.0108.backup
-rw--- 1 postgres
On Tue, 2021-03-16 at 09:49 +0200, Andrew Anderson wrote:
> 2021-03-16 09:44:03.997 EET [97581] [] [] [] []DEBUG: attempting to remove
> WAL segments older than log file 013E0097
That was the entry I was hoping to see.
So, are all older WAL segments deleted or recycled?
Is that
postgres=# show checkpoint_timeout;
checkpoint_timeout
5min
(1 row)
Added log_checkpoints = on to postgresql.conf on slave, and here is the log
from slave:
2021-03-16 09:43:42.509 EET [97581] [] [] [] []DEBUG: checkpointer updated
shared memory configuration values
2021-03
The situation didn't changes, WAL segments not removing automatically. The
streaming replication works fine, here is the log files:
from master:
2021-03-16 06:28:51.787 EET [94341] [walreceiver] [pgadmin] [[unknown]]
[2.2.2.2]DEBUG: write 145/ED10A8E8 flush 145/ED10A8E8 apply 145/ED10A8E8
2021-03
On Tue, 2021-03-16 at 09:33 +0200, Andrew Anderson wrote:
> The situation didn't changes, WAL segments not removing automatically.
> The streaming replication works fine, here is the log files:
>
> from master:
> [log with debug2, but without WAL segment delete messages]
Could you set "log_checkp
> Never, ever, remove WAL files manually.
> A crash might render your database unrecoverable.
You're right, it's not a good idea.
> You'll have to figure out what is blocking WAL removal.
This is my favorite dream!
> Are there archive failures reported in "pg_stat_archiver" and the log?
master=#
On Thu, 2021-03-11 at 09:43 +0200, Andrew Anderson wrote:
> > Never, ever, remove WAL files manually.
> > A crash might render your database unrecoverable.
> You're right, it's not a good idea.
>
> > You'll have to figure out what is blocking WAL removal.
> This is my favorite dream!
>
> > Are th
On Wed, 2021-03-10 at 14:34 +0200, Forum Writer wrote:
> Have Streaming replica with 2 hosts, master and slave with PostgreSQL 10.6.
> Replica works fine and data from master copying to slave without any problem,
> but on slave have a problem: wal-files in catalog ${PGDATA}/pg_wal is not
> removi
Hello,
Have Streaming replica with 2 hosts, master and slave with PostgreSQL 10.6.
Replica works fine and data from master copying to slave without any
problem,
but on slave have a problem: wal-files in catalog ${PGDATA}/pg_wal is not
removing authomaticaly and may be collects over some years.
Bot
18 matches
Mail list logo
