Switchover/Switchback in PostgreSQL 9.3
PostgreSQL 9.3 has two key software updates making switchover/switchback easier in High Availability configurations.
First, let’s address the software patches and their descriptions:
1. First patch was committed by Fujii Masao.
With this patch, the walsender process tries to send all outstanding WAL records to the standby in replication when the user shuts down the master.
This means:
a. All WAL records are synced between two servers after the clean shutdown of the master
b. After promoting the standby to new master, the user can restart the stopped master as new standby without a fresh backup from new master.
2. Second patch was committed by Heikki Linnakangas in PostgreSQL 9.3.
Before PostgreSQL version 9.3, streaming replication used to stop replicating if the timeline on the primary didn’t match the standby. This generally happens when the user promotes one of the standbys to become the new master. Promoting a standby always results in an increment of timeline ID and after that increment, other standbys will refuse to continue replicating.
With this patch in PostgreSQL 9.3, the standby asks the primary for any timeline history files that are missing from the standby when it connects – if the standby recovery.conf file has the following setting:
recovery_target_timeline='latest'
The missing files are sent using a new replication command TIMELINE_HISTORY, and stored in the standby's pg_xlog directory. Using the timeline history files, the standby can follow the latest timeline present in the primary, just as it can follow new timelines appearing in an archive WAL directory.
Because of above patches, if the user performs the following sequence of steps then switchover/switchback can be easily achieved:
To switchover from Master to Standby, use following steps:
On Master:
1. Use any one of following stop options for clean shutdown.
2. Before promoting standby:
3. Have the proper archive location and archive_command setting accessible to old Master.
Following is a presentation I delivered at a recent BPUG Meet (Boston PostgreSQL User Group) to discuss switchover/switchback.
First, let’s address the software patches and their descriptions:
1. First patch was committed by Fujii Masao.
Patch commit# 985bd7d49726c9f178558491d31a570d47340459
With this patch, the walsender process tries to send all outstanding WAL records to the standby in replication when the user shuts down the master.
This means:
a. All WAL records are synced between two servers after the clean shutdown of the master
b. After promoting the standby to new master, the user can restart the stopped master as new standby without a fresh backup from new master.
2. Second patch was committed by Heikki Linnakangas in PostgreSQL 9.3.
Patch commit# abfd192b1b5ba5216ac4b1f31dcd553106304b19
Before PostgreSQL version 9.3, streaming replication used to stop replicating if the timeline on the primary didn’t match the standby. This generally happens when the user promotes one of the standbys to become the new master. Promoting a standby always results in an increment of timeline ID and after that increment, other standbys will refuse to continue replicating.
With this patch in PostgreSQL 9.3, the standby asks the primary for any timeline history files that are missing from the standby when it connects – if the standby recovery.conf file has the following setting:
recovery_target_timeline='latest'
The missing files are sent using a new replication command TIMELINE_HISTORY, and stored in the standby's pg_xlog directory. Using the timeline history files, the standby can follow the latest timeline present in the primary, just as it can follow new timelines appearing in an archive WAL directory.
Because of above patches, if the user performs the following sequence of steps then switchover/switchback can be easily achieved:
To switchover from Master to Standby, use following steps:
On Master:
1. Use any one of following stop options for clean shutdown.
pg_ctl stop --pgdata=data_dire --mode=fast or pg_ctl stop --pgdata=data_directory --mode=smart
2. Before promoting standby:
. Make sure all WAL send by Master applied on Standby. Use following functions to verify it: * pg_last_xlog_receive_location() * pg_last_xlog_replay_location()
3. Have the proper archive location and archive_command setting accessible to old Master.
Following is a presentation I delivered at a recent BPUG Meet (Boston PostgreSQL User Group) to discuss switchover/switchback.
Comments
Post a Comment