When an in-place restore of a multi-node PostgreSQL HA cluster to a previous point in time is triggered through NDB, how does NDB handle the Patroni consensus layer during the recovery process?
A.
NDB promotes all cluster nodes to simultaneous read-write primary leaders to accelerate the ingestion of archived transaction logs.
B.
NDB leaves Patroni fully active so that it can stream live application traffic to the standby nodes while the primary is being overwritten.
C.
NDB temporarily pauses Patroni cluster monitoring and places the cluster in maintenance mode during the restore operation.
D.
NDB deletes the Patroni configuration and recreates it from backup after the restore has completed.
Patroni continuously monitors PostgreSQL HA members and can promote a standby when it determines that the leader has failed. During an in-place point-in-time restore, NDB intentionally stops normal cluster automation: it pauses Patroni monitoring and places the cluster in maintenance mode while the database state is rewound. This prevents Patroni from interpreting controlled shutdowns or role changes as failures and initiating an unwanted promotion. After recovery and cluster validation, normal Patroni management can resume. Nutanix documents Patroni as the component responsible for monitoring PostgreSQL instances and performing automated failover, which explains why its automation must be suspended during this coordinated recovery operation. NDB neither promotes every node nor deletes and rebuilds the Patroni configuration. Therefore, option C is correct. Nutanix Patroni overview
Contribute your Thoughts:
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit