[HACKERS] Re: new high availability feature for the system with bothasynchronous and synchronous replication - Mailing list pgsql-hackers

From Higuchi, Daisuke
Subject [HACKERS] Re: new high availability feature for the system with bothasynchronous and synchronous replication
Date
Msg-id 1803D792815FC24D871C00D17AE95905AD90E2@g01jpexmbkw24
Whole thread Raw
In response to [HACKERS] new high availability feature for the system with both asynchronousand synchronous replication  ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
Responses Re: [HACKERS] Re: new high availability feature for the system withboth asynchronous and synchronous replication
Re: [HACKERS] Re: new high availability feature for the system withboth asynchronous and synchronous replication
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] help to identify the reason that extension's C function returns array get segmentation fault
Next
From: Alvaro Herrera
Date:
Subject: [HACKERS] BRIN de-summarize ranges