Re: Slot issues

Поиск
Список
Период
Сортировка
От Ravi Krishna
Тема Re: Slot issues
Дата
Msg-id 36CCE7FA-BD81-409F-AE79-224C1FB68053@aol.com
обсуждение исходный текст
Ответ на Re: [External] Re: Slot issues  (Vijaykumar Jain <vjain@opentable.com>)
Ответы Re: Slot issues  (Ravi Krishna <srkrishna1@aol.com>)
Список pgsql-general
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.

В списке pgsql-general по дате отправления:

Предыдущее
От: bhargav kamineni
Дата:
Сообщение: Re: Slot issues
Следующее
От: Ravi Krishna
Дата:
Сообщение: Re: Slot issues