Nutanix NCP-DB flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

NDB appliance deployment

NDB runs as a Nutanix VM deployed via Prism or the deployer image; it hosts the NDB server, PostgreSQL repository, and orchestration engine, and registers with Prism Element and Prism Central.

NDB agent

A service installed on every managed database VM that executes provisioning, snapshot, clone, and patch operations locally; without it, the VM shows as unreachable in NDB.

Time machine

The logical container for one database's lifecycle in NDB, recording its snapshots, log captures, clones, and retention; clone refresh and PITR operate through the source time machine.

NDB repository database

The built-in PostgreSQL database on the NDB VM that stores all metadata: registered clusters, databases, snapshots, SLAs, users, and task history.

NDB supported engines

NDB provisions and manages PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle (single instance and RAC), and MongoDB replica sets, each with engine-specific profiles.

Network profile

Defines VLAN, IP pool, gateway, DNS, and subnet for provisioned database VMs; provisioning fails without a valid network profile and available IPs.

Software profile

Maps a database engine version to its installation media; NDB ships defaults and administrators can upload custom binaries to serve as patch or upgrade targets.

SLA policy

Defines snapshot frequency, retention count, log capture interval, and application consistency; every database must be attached to an SLA for automated protection.

Register database server

Installing the NDB agent on a VM and adding it to NDB so it can host provisioned databases; unregistered VMs cannot receive provisioning operations.

NDB initial setup wizard

Post-deployment configuration on the NDB VM: set admin password, register Prism Element/Central, choose the storage container, and configure the NFS backup share.

Provisioning source options

A new database can be created empty, cloned from an existing snapshot at a point in time, or cloned from an existing database; the source time machine defines available points.

Copy-on-write clone

NDB clones are copy-on-write from a Nutanix snapshot on the same cluster; cross-cluster cloning requires the snapshot to be replicated to the target cluster first.

Clone independence

A clone is a full database VM with its own time machine; it can be refreshed from the source but does not inherit the source's SLA unless explicitly attached.

Asynchronous provisioning

Provisioning runs as an NDB task with per-step status; a failed step such as agent registration leaves the database in an error state requiring cleanup before retry.

Patch profile

Defines OS and database engine patches to apply; NDB snapshots the database first if configured, applies the patch, and can roll back on failure.

Engine upgrade

A major version change (for example PostgreSQL 13 to 15) distinct from patching; it requires a compatible software profile and a pre-upgrade snapshot for rollback.

Scale-up versus scale-out

Scale-up changes vCPU, RAM, or storage on the existing node; scale-out adds nodes and is supported only by engines like SQL Server Always On or Oracle RAC.

Maintenance window

A schedule that restricts when automated patching and snapshot operations run; manual operations outside the window remain allowed unless policy explicitly blocks them.

Snapshot-based backup

NDB backups are Nutanix snapshots governed by SLA frequency and retention; they can be replicated to a remote cluster or object store for disaster recovery.

Log capture for PITR

Continuous transaction log shipping at the SLA log interval, enabling restore to any point between snapshots within the retention window.

Restore in place

A destructive restore that overwrites the existing database with a snapshot or PITR point; restore to a new database instead creates a clone and leaves the original untouched.

PITR prerequisites

Point-in-time recovery requires log capture enabled on the source time machine, a base snapshot, and log retention covering the requested timestamp.

Snapshot retention

Each SLA defines how many snapshots and how many days of logs to keep; pruning older snapshots also limits the earliest point available for PITR.

Clone refresh

Replaces a clone's data with a newer snapshot from its source time machine while keeping the clone's name, IP, and network; the clone is briefly unavailable during refresh.

Refresh pre-snapshot

Before refreshing a clone, NDB snapshots the clone's current state so the previous data can be recovered if the refresh operation fails.

Snapshot deletion dependency

A snapshot cannot be deleted while a clone is actively based on it; NDB blocks deletion until the clone is refreshed to a different snapshot or deleted.

Cross-cluster data copy

Moves snapshots between NDB clusters for DR or test/dev; the destination cluster must be registered and have compatible storage and network profiles.

NDB RBAC roles

Admin has full control; Operator provisions and operates but cannot manage users or infrastructure; Developer uses and clones existing databases; Viewer is read-only.

Project scoping

Projects group databases and users; a user's effective permissions are the union of global and project-scoped roles, with the most permissive role winning.

Directory integration

LDAP or Active Directory integration lets AD groups map to NDB roles, so group membership drives permissions without per-user NDB accounts.

NDB audit history

NDB records user actions such as provision, clone, delete, and patch in its task history; Prism logs VM-level operations for correlation during investigations.

SLA compliance alert

An alert raised when a scheduled snapshot or log capture is missed or fails, indicating the database is no longer protected as its SLA policy requires.