Replica, Failover and Lifecycle Fixes for Managed Databases
Standbys, planned changes, deletions and several database pages now behave the way you would expect.
What's changed
- Planned changes to a PostgreSQL database with a standby now switch over to it instead of restarting the primary, including when the standby was added after creation
- Adding a standby or read replica to a PostgreSQL or MariaDB database no longer stalls before the new server can start
- Adding a replica, editing a database, saving its parameter group or expanding its storage no longer restarts an older PostgreSQL database as a side effect
- The API's add and remove replica endpoints now actually scale managed PostgreSQL instead of answering success and changing nothing, and removing anything but the newest replica returns a clear error
- A refused replica or scaling request shows its reason and the node list stays on screen, on database and cache pages
- Turning on public access updates the host, port and connection string on the Connectivity tab without a reload, and a name that would clash with another engine's database in the same project is refused up front instead of getting stuck provisioning
- Deleting a database no longer flips it to Error, with a notification to your team, before the deletion completes