github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-22 22:56:29 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

repmgrd: improve promotion script failure handling

Browse Source 
While scanning for a new primary following a promotion script failure,
repmgrd was treating a witness server as a potential new primary
and would attempt to "follow" it. Fortunately "repmgr standby follow"
would do the right thing and choose the actual primary, if available,
otherwise do nothing, so the cluster would eventually end up in the
correct state, albeit for the wrong reason.

By skipping the witness server as a potential new primary,
repmgrd will do the right thing if the original primary does come
back online, i.e. resume monitoring as before.
This commit is contained in:
Ian Barwick
2018-10-16 11:27:40 +09:00
parent 726299f7ef
commit f471316504
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
repmgrd-physical.c
View File

@@ -1008,6 +1008,13 @@ monitor_streaming_standby(void)
continue;
}
/* skip witness node - we can't possibly "follow" that */
if (cell->node_info->type == WITNESS)
{
continue;
}
cell->node_info->conn = establish_db_connection(cell->node_info->conninfo, false);
if (PQstatus(cell->node_info->conn) != CONNECTION_OK)
@@ -1030,6 +1037,7 @@ monitor_streaming_standby(void)
follow_new_primary(follow_node_id);
}
}
clear_node_info_list(&sibling_nodes);
}
}
@@ -2386,6 +2394,8 @@ follow_new_primary(int new_primary_id)
RecordStatus record_status = RECORD_NOT_FOUND;
bool new_primary_ok = false;
log_verbose(LOG_DEBUG, "follow_new_primary(): new primary id is %i", new_primary_id);
record_status = get_node_record(local_conn, new_primary_id, &new_primary);
if (record_status != RECORD_FOUND)