Database Lifecycle Operations (Patching, Upgrades, Scaling)
What the exam tests
This domain covers patching, engine upgrades, and scaling while preserving recoverability.
Core rules
- Use NDB patch operations so the server can run prechecks, take a snapshot, and update metadata. Manual patching breaks managed state.
- Patch the database engine and the operating system through supported workflows; order depends on engine and release notes.
- Take a protected snapshot or clone before a major upgrade. A minor patch may be reversible; a major upgrade often is not.
- Scale compute vertically by changing vCPU and memory; expect a reboot and capacity check on the AHV cluster.
- Scale storage only within supported limits; plan for snapshot and log growth, not just current data.
- Maintenance windows reduce surprise downtime but do not eliminate it for single-instance databases.
Worked example
A PostgreSQL minor patch is due. The administrator confirms the target version is supported, creates an on-demand snapshot, runs the NDB patch precheck, schedules a window, and applies the patch. NDB stops the database, updates binaries, restarts it, and validates the agent. If validation fails, the pre-patch snapshot is the rollback point. For a major version upgrade, the safer pattern is a new provisioned database plus replication or dump/restore, not an in-place patch.
Traps
Do not patch the OS outside NDB and expect the next NDB patch to succeed. Do not scale down storage; NDB and Nutanix do not treat that as a routine operation. Do not ignore engine compatibility with the agent. Do not assume a snapshot is a rollback plan unless restore has been tested.