Обсуждение: Slot issues
Hi Team,
I am getting this ERROR while starting my second slave server
PANIC: too many replication slots active before shutdown
HINT: Increase max_replication_slots and try again.
max_replication_slots on my master is 2 and one of them is already active for another slave,
do i need to increase this parameter for the need of working of another slave ? if so whats the reason ?
Thanks
Bhargav K
I guess max_replication_slots has to > current total slots in use. (and not >= )
from the doc, it says defaults are 10, any reason why you have set it to 2. You need to set it at a value higher than number of slots active.
also, i guess changing this parameter would require a server restart.
Vijay
On Mon, Oct 15, 2018 at 12:16 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:
Hi Team,I am getting this ERROR while starting my second slave serverPANIC: too many replication slots active before shutdownHINT: Increase max_replication_slots and try again.max_replication_slots on my master is 2 and one of them is already active for another slave,do i need to increase this parameter for the need of working of another slave ? if so whats the reason ?ThanksBhargav K
Am 14.10.2018 um 20:45 schrieb bhargav kamineni: > I am getting this ERROR while starting my second slave server > > PANIC: too many replication slots active before shutdown > HINT: Increase max_replication_slots and try again. > > max_replication_slots on my master is 2 and one of them is already > active for another slave, > do i need to increase this parameter for the need of working of > another slave ? if so whats the reason ? please check on the master how many slots are in use: select * from pg_replication_slots ; please also tell us the exact version you are using. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
Am 14.10.2018 um 21:02 schrieb Vijaykumar Jain: > from the doc, it says defaults are 10, that's only valid for version 10, not for 9.x. Default was 0. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
Am 14.10.2018 um 21:07 schrieb bhargav kamineni: > Postgres version is 9.5.14 , currently only one slot is there and it > is active that's strange. Please check if this setting is active (select from pg_settings). Please check also max_wal_senders. no futher ideas at the moment :-( Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
ok my bad.
i just set one of the 9.6.9 versions to have max_replication_slots =2 and still i had to slots active.
ostgres=# table pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
-------------------------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------
a02 | | physical | | | t | 13719 | | | 2/D30000D0 |
a03 | | physical | | | t | 13720 | | | 2/D30000D0 |
(2 rows)
postgres=# show max_replication_slots;
max_replication_slots
-----------------------
2
(1 row)
yep it should work with 2.
Regards,Vijay
On Mon, Oct 15, 2018 at 1:02 AM Vijaykumar Jain <vjain@opentable.com> wrote:
I guess max_replication_slots has to be greater than active replication slots.maybe you need to increase max_replication_slots to 3 to have 2 active slots.Regards,VijayOn Mon, Oct 15, 2018 at 12:54 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:for 9.x. Default was 0. we have set max_replication_slot =2 , one is already being used , postgres should use second slot for another server but dono why its throwing errorOn Mon, 15 Oct 2018 at 00:32, Vijaykumar Jain <vjain@opentable.com> wrote:I guess max_replication_slots has to > current total slots in use. (and not >= )from the doc, it says defaults are 10, any reason why you have set it to 2. You need to set it at a value higher than number of slots active.also, i guess changing this parameter would require a server restart.Regards,VijayOn Mon, Oct 15, 2018 at 12:16 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:Hi Team,I am getting this ERROR while starting my second slave serverPANIC: too many replication slots active before shutdownHINT: Increase max_replication_slots and try again.max_replication_slots on my master is 2 and one of them is already active for another slave,do i need to increase this parameter for the need of working of another slave ? if so whats the reason ?ThanksBhargav K
from your master, can you give us the output of
select * from pg_replication_slots;
maybe some stray slot exists that you may not be aware of ?
Regards,
Vijay
On Mon, Oct 15, 2018 at 1:08 AM Vijaykumar Jain <vjain@opentable.com> wrote:
ok my bad.i just set one of the 9.6.9 versions to have max_replication_slots =2 and still i had to slots active.ostgres=# table pg_replication_slots;slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn-------------------------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------a02 | | physical | | | t | 13719 | | | 2/D30000D0 |a03 | | physical | | | t | 13720 | | | 2/D30000D0 |(2 rows)postgres=# show max_replication_slots;max_replication_slots-----------------------2(1 row)yep it should work with 2.Regards,VijayOn Mon, Oct 15, 2018 at 1:02 AM Vijaykumar Jain <vjain@opentable.com> wrote:I guess max_replication_slots has to be greater than active replication slots.maybe you need to increase max_replication_slots to 3 to have 2 active slots.Regards,VijayOn Mon, Oct 15, 2018 at 12:54 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:for 9.x. Default was 0. we have set max_replication_slot =2 , one is already being used , postgres should use second slot for another server but dono why its throwing errorOn Mon, 15 Oct 2018 at 00:32, Vijaykumar Jain <vjain@opentable.com> wrote:I guess max_replication_slots has to > current total slots in use. (and not >= )from the doc, it says defaults are 10, any reason why you have set it to 2. You need to set it at a value higher than number of slots active.also, i guess changing this parameter would require a server restart.Regards,VijayOn Mon, Oct 15, 2018 at 12:16 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:Hi Team,I am getting this ERROR while starting my second slave serverPANIC: too many replication slots active before shutdownHINT: Increase max_replication_slots and try again.max_replication_slots on my master is 2 and one of them is already active for another slave,do i need to increase this parameter for the need of working of another slave ? if so whats the reason ?ThanksBhargav K
postgres=# select * from pg_replication_slots ;
slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn
----------------------------------+--------+-----------+--------+----------+--------+------------+------+--------------+---------------
replication_slot | | physical | | | t | 23185 | | | 7642/B07AC830
(1 row)
On Mon, 15 Oct 2018 at 01:34, Vijaykumar Jain <vjain@opentable.com> wrote:
from your master, can you give us the output ofselect * from pg_replication_slots;maybe some stray slot exists that you may not be aware of ?Regards,VijayOn Mon, Oct 15, 2018 at 1:08 AM Vijaykumar Jain <vjain@opentable.com> wrote:ok my bad.i just set one of the 9.6.9 versions to have max_replication_slots =2 and still i had to slots active.ostgres=# table pg_replication_slots;slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn-------------------------+--------+-----------+--------+----------+--------+------------+------+--------------+-------------+---------------------a02 | | physical | | | t | 13719 | | | 2/D30000D0 |a03 | | physical | | | t | 13720 | | | 2/D30000D0 |(2 rows)postgres=# show max_replication_slots;max_replication_slots-----------------------2(1 row)yep it should work with 2.Regards,VijayOn Mon, Oct 15, 2018 at 1:02 AM Vijaykumar Jain <vjain@opentable.com> wrote:I guess max_replication_slots has to be greater than active replication slots.maybe you need to increase max_replication_slots to 3 to have 2 active slots.Regards,VijayOn Mon, Oct 15, 2018 at 12:54 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:for 9.x. Default was 0. we have set max_replication_slot =2 , one is already being used , postgres should use second slot for another server but dono why its throwing errorOn Mon, 15 Oct 2018 at 00:32, Vijaykumar Jain <vjain@opentable.com> wrote:I guess max_replication_slots has to > current total slots in use. (and not >= )from the doc, it says defaults are 10, any reason why you have set it to 2. You need to set it at a value higher than number of slots active.also, i guess changing this parameter would require a server restart.Regards,VijayOn Mon, Oct 15, 2018 at 12:16 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:Hi Team,I am getting this ERROR while starting my second slave serverPANIC: too many replication slots active before shutdownHINT: Increase max_replication_slots and try again.max_replication_slots on my master is 2 and one of them is already active for another slave,do i need to increase this parameter for the need of working of another slave ? if so whats the reason ?ThanksBhargav K
Hi, On 2018-10-15 00:15:53 +0530, bhargav kamineni wrote: > Hi Team, > > I am getting this ERROR while starting my second slave server > > PANIC: too many replication slots active before shutdown > HINT: Increase max_replication_slots and try again. > > max_replication_slots on my master is 2 and one of them is already active > for another slave, > do i need to increase this parameter for the need of working of another > slave ? if so whats the reason ? You're getting that error on the standby, not the primary, right? In all likelihood the problem is that you copied over replication slots to your standby server, but that *on the standby* haven't set max_replication_slots high enough. Greetings, Andres Freund
I got his on standby, could you please explain in detail about
--but that *on the standby* haven't set max_replication_slots high enough.
Thanks,
Bhargav
On Mon, 15 Oct 2018 at 01:50, Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2018-10-15 00:15:53 +0530, bhargav kamineni wrote:
> Hi Team,
>
> I am getting this ERROR while starting my second slave server
>
> PANIC: too many replication slots active before shutdown
> HINT: Increase max_replication_slots and try again.
>
> max_replication_slots on my master is 2 and one of them is already active
> for another slave,
> do i need to increase this parameter for the need of working of another
> slave ? if so whats the reason ?
You're getting that error on the standby, not the primary, right? In
all likelihood the problem is that you copied over replication slots to
your standby server, but that *on the standby* haven't set
max_replication_slots high enough.
Greetings,
Andres Freund
i guess he is trying to confirm if the value of max_replication_slot is the same on all the master and the standby nodes.
Regards,
also,
I am trying to shoot in the dark.
can you give the output of (on master)
ls /var/lib/postgresql/<pg_version>/main/pg_replslot/*
also the value of max_replication_slot on the master and all the standby's.
also, how are you creating the replication slot?
can you share the query?
also pls share the content of the recovery.conf on the standby nodes (both currently running and currently not running).
you can scribble company secret stuff.
Vijay
On Mon, Oct 15, 2018 at 1:58 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:
I got his on standby, could you please explain in detail about--but that *on the standby* haven't set max_replication_slots high enough.Thanks,BhargavOn Mon, 15 Oct 2018 at 01:50, Andres Freund <andres@anarazel.de> wrote:Hi,
On 2018-10-15 00:15:53 +0530, bhargav kamineni wrote:
> Hi Team,
>
> I am getting this ERROR while starting my second slave server
>
> PANIC: too many replication slots active before shutdown
> HINT: Increase max_replication_slots and try again.
>
> max_replication_slots on my master is 2 and one of them is already active
> for another slave,
> do i need to increase this parameter for the need of working of another
> slave ? if so whats the reason ?
You're getting that error on the standby, not the primary, right? In
all likelihood the problem is that you copied over replication slots to
your standby server, but that *on the standby* haven't set
max_replication_slots high enough.
Greetings,
Andres Freund
ok wait, you data directory path may be different :)
i mean wherever your pg data dir is, from there find pg_replslot folder and list the contents of it.
Regards,
Vijay
On Mon, Oct 15, 2018 at 2:10 AM Vijaykumar Jain <vjain@opentable.com> wrote:
i guess he is trying to confirm if the value of max_replication_slot is the same on all the master and the standby nodes.also,I am trying to shoot in the dark.can you give the output of (on master)ls /var/lib/postgresql/<pg_version>/main/pg_replslot/*also the value of max_replication_slot on the master and all the standby's.also, how are you creating the replication slot?can you share the query?also pls share the content of the recovery.conf on the standby nodes (both currently running and currently not running).you can scribble company secret stuff.Regards,VijayOn Mon, Oct 15, 2018 at 1:58 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:I got his on standby, could you please explain in detail about--but that *on the standby* haven't set max_replication_slots high enough.Thanks,BhargavOn Mon, 15 Oct 2018 at 01:50, Andres Freund <andres@anarazel.de> wrote:Hi,
On 2018-10-15 00:15:53 +0530, bhargav kamineni wrote:
> Hi Team,
>
> I am getting this ERROR while starting my second slave server
>
> PANIC: too many replication slots active before shutdown
> HINT: Increase max_replication_slots and try again.
>
> max_replication_slots on my master is 2 and one of them is already active
> for another slave,
> do i need to increase this parameter for the need of working of another
> slave ? if so whats the reason ?
You're getting that error on the standby, not the primary, right? In
all likelihood the problem is that you copied over replication slots to
your standby server, but that *on the standby* haven't set
max_replication_slots high enough.
Greetings,
Andres Freund
pg_replslot # ls -lrth
total 4.0K
drwx------ 2 postgres postgres 4.0K Oct 14 14:55 replication_slot
On Mon, 15 Oct 2018 at 02:11, Vijaykumar Jain <vjain@opentable.com> wrote:
ok wait, you data directory path may be different :)i mean wherever your pg data dir is, from there find pg_replslot folder and list the contents of it.Regards,VijayOn Mon, Oct 15, 2018 at 2:10 AM Vijaykumar Jain <vjain@opentable.com> wrote:i guess he is trying to confirm if the value of max_replication_slot is the same on all the master and the standby nodes.also,I am trying to shoot in the dark.can you give the output of (on master)ls /var/lib/postgresql/<pg_version>/main/pg_replslot/*also the value of max_replication_slot on the master and all the standby's.also, how are you creating the replication slot?can you share the query?also pls share the content of the recovery.conf on the standby nodes (both currently running and currently not running).you can scribble company secret stuff.Regards,VijayOn Mon, Oct 15, 2018 at 1:58 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:I got his on standby, could you please explain in detail about--but that *on the standby* haven't set max_replication_slots high enough.Thanks,BhargavOn Mon, 15 Oct 2018 at 01:50, Andres Freund <andres@anarazel.de> wrote:Hi,
On 2018-10-15 00:15:53 +0530, bhargav kamineni wrote:
> Hi Team,
>
> I am getting this ERROR while starting my second slave server
>
> PANIC: too many replication slots active before shutdown
> HINT: Increase max_replication_slots and try again.
>
> max_replication_slots on my master is 2 and one of them is already active
> for another slave,
> do i need to increase this parameter for the need of working of another
> slave ? if so whats the reason ?
You're getting that error on the standby, not the primary, right? In
all likelihood the problem is that you copied over replication slots to
your standby server, but that *on the standby* haven't set
max_replication_slots high enough.
Greetings,
Andres Freund
Hi, Please try to quote properly. On 2018-10-15 01:57:53 +0530, bhargav kamineni wrote: > I got his on standby, could you please explain in detail about > --*but that *on the standby* haven't set max_replication_slots high enough* > . What is max_replication_slots set to on the new standby? If you created the new basebackup using rsync, and didn't exclude pg_replication_slot, it'll have copied the slots from the primary. And thus needs a high enough max_replication_slots to work with them. - Andres
Yeah i have used rsync , Got it now will increase the max_replication_slots to high enough , Thank you Andres Freund :-)
On Mon, 15 Oct 2018 at 02:40, Andres Freund <andres@anarazel.de> wrote:
Hi,
Please try to quote properly.
On 2018-10-15 01:57:53 +0530, bhargav kamineni wrote:
> I got his on standby, could you please explain in detail about
> --*but that *on the standby* haven't set max_replication_slots high enough*
> .
What is max_replication_slots set to on the new standby?
If you created the new basebackup using rsync, and didn't exclude
pg_replication_slot, it'll have copied the slots from the primary. And
thus needs a high enough max_replication_slots to work with them.
- Andres
Sorry Bhargav.
Regards,
I tried to simulate the scenarios,
3 node cluster
1primary, 2hot standby
given:
max_replication_slots = 2 on primary, and i try to create 2 hot standby -> runs fine.
max_replication_slots = 1 on primary, and i try to create 2 hot standby -> gives PANIC, increase replication slots. (the standby only cries with replication slot does not exist, not increase number of replication slots)
max_replication_slots = 2 on primary, and max_replication_slots=1 on hot standby, delete recovery.conf and recover from pg_baseback works fine.
max_replication_slots = 2 on primary, on standby i try to use a replication_slot already existing, it gives correct error of slot in use and not increase replication slot error.
my pg_replslot folder is consistent of the replication slots i have on the master.
so i guess, i'll leave it to the experts.
but i still do not understand why would you get that error on standby, unless you are doing cascading replication.
I'll watch this thread to see how this is resolved.
Thanks,
Vijay
Vijay
On Mon, Oct 15, 2018 at 2:41 AM Andres Freund <andres@anarazel.de> wrote:
Hi,
Please try to quote properly.
On 2018-10-15 01:57:53 +0530, bhargav kamineni wrote:
> I got his on standby, could you please explain in detail about
> --*but that *on the standby* haven't set max_replication_slots high enough*
> .
What is max_replication_slots set to on the new standby?
If you created the new basebackup using rsync, and didn't exclude
pg_replication_slot, it'll have copied the slots from the primary. And
thus needs a high enough max_replication_slots to work with them.
- Andres
ah that explains.
Thanks andres.
I do not use rsync, hence was not able to reproduce i guess :)
Regards,
Vijay
On Mon, Oct 15, 2018 at 2:46 AM bhargav kamineni <bhargavpostgres@gmail.com> wrote:
Yeah i have used rsync , Got it now will increase the max_replication_slots to high enough , Thank you Andres Freund :-)On Mon, 15 Oct 2018 at 02:40, Andres Freund <andres@anarazel.de> wrote:Hi,
Please try to quote properly.
On 2018-10-15 01:57:53 +0530, bhargav kamineni wrote:
> I got his on standby, could you please explain in detail about
> --*but that *on the standby* haven't set max_replication_slots high enough*
> .
What is max_replication_slots set to on the new standby?
If you created the new basebackup using rsync, and didn't exclude
pg_replication_slot, it'll have copied the slots from the primary. And
thus needs a high enough max_replication_slots to work with them.
- Andres
Hi, As I just wrote: > On Mon, 15 Oct 2018 at 02:40, Andres Freund <andres@anarazel.de> wrote: > > Please try to quote properly. On 2018-10-15 02:45:51 +0530, bhargav kamineni wrote: > Yeah i have used rsync , Got it now will increase the max_replication_slots > to high enough , Thank you Andres Freund :-) You probably afterwards want to drop those slots from the new standby. See the following section from the docs: https://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP-DATA "It is often a good idea to also omit from the backup the files within the cluster's pg_replslot/ directory, so that replicationslots that exist on the master do not become part of the backup. Otherwise, the subsequent use of the backup tocreate a standby may result in indefinite retention of WAL files on the standby, and possibly bloat on the master if hotstandby feedback is enabled, because the clients that are using those replication slots will still be connecting to andupdating the slots on the master, not the standby. Even if the backup is only intended for use in creating a new master,copying the replication slots isn't expected to be particularly useful, since the contents of those slots will likelybe badly out of date by the time the new master comes on line." Greetings, Andres Freund
> You probably afterwards want to drop those slots from the new standby.
> See the following section from the docs:
>https://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP-DATA
"It is often a good idea to also omit from the backup the files within the cluster's pg_replslot/ directory, so that replication slots that exist on the master do not become part of the backup. Otherwise, the subsequent use of the backup to create a standby may result in indefinite retention of WAL files on the standby, and possibly bloat on the master if hot standby feedback is enabled, because the clients that are using those replication slots will still be connecting to and updating the slots on the master, not the standby. Even if the backup is only intended for use in creating a new master, copying the replication slots isn't expected to be particularly useful, since the contents of those slots will likely be badly out of date by the time the new master comes on line."
Since i already synced the pg_repslot to standby ,Is it okay if i remove the pg_repslot directory befor starting postgresql service ?
On Mon, 15 Oct 2018 at 02:54, Andres Freund <andres@anarazel.de> wrote:
Hi,
As I just wrote:
> On Mon, 15 Oct 2018 at 02:40, Andres Freund <andres@anarazel.de> wrote:
> > Please try to quote properly.
On 2018-10-15 02:45:51 +0530, bhargav kamineni wrote:
> Yeah i have used rsync , Got it now will increase the max_replication_slots
> to high enough , Thank you Andres Freund :-)
You probably afterwards want to drop those slots from the new standby.
See the following section from the docs:
https://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP-DATA
"It is often a good idea to also omit from the backup the files within the cluster's pg_replslot/ directory, so that replication slots that exist on the master do not become part of the backup. Otherwise, the subsequent use of the backup to create a standby may result in indefinite retention of WAL files on the standby, and possibly bloat on the master if hot standby feedback is enabled, because the clients that are using those replication slots will still be connecting to and updating the slots on the master, not the standby. Even if the backup is only intended for use in creating a new master, copying the replication slots isn't expected to be particularly useful, since the contents of those slots will likely be badly out of date by the time the new master comes on line."
Greetings,
Andres Freund
When I read all such posts related to replication I realize how backward is PG's replication architecture specially when compared to DB2. This is how it is done in Db2 to set up replication. 1. take a full backup on the primary. 2. restore the backup on the other machine (aka standby) 3. start the instance on the standby machine as a standby and point to primary as the master 4. that's it. Db2 will fetch the relevant WAL (active) logs and start applying the logs to catch up. 5. Once it has caught up with the primary, it is in PEER mode. To failover from master to slave On the standby issue db2 takeover database dbname that's it. it will flip master and standby and reverse their roles. [ I am aware that why it is impossible in PG to reverse roles like this ] Long time back I use to work in SQL Server and the setup of mirroring was as simple as DB2. Negative of db2 replication: In DB2 replication, lot of restriction on standby to be used as a read-only. One DDL statement or stats collection in the primary will put the standby in replay only mode where it will kick out all sessions on standby until DDL/stats is applied on standby also. Note: My knowledge of db2 replication is bit dated as I have not worked on it since 2014. I love PG, but definitely replication management can be better.
The best part in Db2 HADR is that when the standby is catching up with the master after a long time, it will start from the last LSN and fetch it from the primary WAL directory (active logs ). If not found, it will look for it in the archived logs and start applying from there until the current point. No rep slot business.
Hi, On 2018-10-15 03:18:35 +0530, bhargav kamineni wrote: > > You probably afterwards want to drop those slots from the new standby. > > See the following section from the docs: > > > > https://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP-DATA > "It is often a good idea to also omit from the backup the files within the > cluster's pg_replslot/ directory, so that replication slots that exist on > the master do not become part of the backup. Otherwise, the subsequent use > of the backup to create a standby may result in indefinite retention of WAL > files on the standby, and possibly bloat on the master if hot standby > feedback is enabled, because the clients that are using those replication > slots will still be connecting to and updating the slots on the master, not > the standby. Even if the backup is only intended for use in creating a new > master, copying the replication slots isn't expected to be particularly > useful, since the contents of those slots will likely be badly out of date > by the time the new master comes on line." > > Since i already synced the pg_repslot to standby ,Is it okay if i remove > the pg_repslot directory befor starting postgresql service ? You can do that, but the nicer way probably is to just remove them via sql once started. Something like SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots; Greetings, Andres Freund
Hi, On 2018-10-14 17:52:30 -0400, Ravi Krishna wrote: > The best part in Db2 HADR is that when the standby is catching up with the master after a long time, it will > start from the last LSN and fetch it from the primary WAL directory (active logs ). If not found, it will look for it > in the archived logs and start applying from there until the current > point. Uh, it works precisely the same in postgres. > No rep slot business. You're not forced to use slots. Their purpose is to allow to force the primary to keep necessary resources around. Which also allows to get rid of the archive in some setups. Greetings, Andres Freund
> > You're not forced to use slots. Their purpose is to allow to force the > primary to keep necessary resources around. Which also allows to get rid > of the archive in some setups. Thanks. Disclaimer: We don't use replication as we piggy back on AWS HA. The reason why I posted this is because majority of replication related messages in this forum is about slots :-)
What was the whole point of this divergence :)
We use replication slots and it is for this reason we are able to scale our applications by redirecting reads and writes backed by haproxy and pgbouncer. with the health check of replication lag. It works awesome and at a much much lower cost to what aws used to charge us for. (1 master, 3 slaves .. that goes to 7-8 during peak days)
With the use of logical replication we were able to create a multimaster mesh that allowed the writes to certain tables across the ocean and all regions subscribed to it.
As a result, at any given time all 5 availability. Zones had same data and we would sustain an occasional WAN outage between two DCs.
We use around 300 Postgres servers, everything managed via puppet and foreman.
And I have not seen any single issue w r t the one reported for any of our setups.
So I guess it is generalising just based out of some threads :)
I do not use db2 but there has never been a need for one in my company as we have multiple design patterns of Postgres architecture based of requirements.
On Mon, 15 Oct 2018 at 3:46 AM Ravi Krishna <srkrishna1@aol.com> wrote:
>
> You're not forced to use slots. Their purpose is to allow to force the
> primary to keep necessary resources around. Which also allows to get rid
> of the archive in some setups.
Thanks.
Disclaimer: We don't use replication as we piggy back on AWS HA.
The reason why I posted this is because majority of replication related messages in this forum
is about slots :-)
Vijay
> On 14 Oct 2018, at 23:10 , Andres Freund <andres@anarazel.de> wrote: > > If you created the new basebackup using rsync, and didn't exclude > pg_replication_slot, it'll have copied the slots from the primary. And > thus needs a high enough max_replication_slots to work with them. Thanks for pointing this out, after I’ve cleared the pg_replslot/ on the cascaded standby, it just “works” ;)