[HACKERS] Re: new high availability feature for the system with bothasynchronous and synchronous replication

Поиск
Список
Период
Сортировка
От Higuchi, Daisuke
Тема [HACKERS] Re: new high availability feature for the system with bothasynchronous and synchronous replication
Дата
Msg-id 1803D792815FC24D871C00D17AE95905AD90E2@g01jpexmbkw24
обсуждение исходный текст
Ответ на [HACKERS] new high availability feature for the system with both asynchronousand synchronous replication  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Ответы Re: [HACKERS] Re: new high availability feature for the system withboth asynchronous and synchronous replication  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: [HACKERS] Re: new high availability feature for the system withboth asynchronous and synchronous replication  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi all, 

I create POC patch for my proposal of new feature for high availability. 
I want to discuss about this feature. But this feature might be PG11 
because discussion is not enough. 

This patch enables walsender for async to wait until walsender for sync confirm 
WAL is flashed to Disk. This feature is activated when GUC parameter 
"async_walsender_delay" is set on. 

I write the case when this feature is useful (this is the same as I wrote before): 
1. Primary and synchronous standby are in the same center; called main center. 
2. Asynchronous standby is in the another center; called backup center. 
   (The backup center is located far away from the main center. If replication 
   mode is synchronous, performance will be deteriorated. So, this replication 
   must be Asynchronous. )
3. Asynchronous replication is performed in the backup center too. 
4. When primary in main center abnormally stops, standby in main center is 
   promoted, and the standby in backup center connects to the new primary.

                [Main center]
|--------------------------------------------|
| |----------|  synchronous     |----------| |
| |          |    replication   |          | |
| | primary  | <--------------> | standby1 | |
| |----------|                  |----------| |
|----||--------------------------------------|
     ||
     || asynchronous
     ||   replication
     ||
     ||        [Backup center]
|----||--------------------------------------|
| |----------|  asynchronous    |----------| |
| |          |    replication   |          | |
| | standby2 | <--------------> | standby3 | |
| |----------|                  |----------| |
|--------------------------------------------|

When the load in the main center becomes high, although WAL reaches standby in 
backup center, WAL may not reach synchronous standby in main center for various 
reasons. In other words, standby in the backup center may advance beyond 
synchronous standby in main center.

When the primary abnormally stops and standby in main center promotes, two 
standbys in backup center must be recovered by pg_rewind. However, it is 
necessary to stop new primary for pg_rewind. If pg_basebackup is used, 
recovery of backup center takes some times. This is not high availability.

Regards, 
Daisuke Higuchi 


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] help to identify the reason that extension's C function returns array get segmentation fault
Следующее
От: Alvaro Herrera
Дата:
Сообщение: [HACKERS] BRIN de-summarize ranges