Frequently Asked Questions (FAQs)
Updated on November 27, 2024These are the frequently asked questions for Vultr Managed Databases for Caching.
Yes, all Managed Databases are backed up for disaster recovery purposes. You can use these backups to restore a cluster, which overwrites the current cluster's data. You can also fork a cluster from the backup, which creates a new cluster without modifying the existing cluster. You'll find those options in the Actions section of your cluster's Overview tab.
The databases do not have point-in-time recovery. When recovering or forking a Vultr Managed Database for Caching, you can choose from a list of periodic backups.
You can deploy Managed Databases in several node plans, which are a shorthand way of identifying the available size and number of nodes. We offer Hobbyist, Startup, Business, and Premium node plans.
After you deploy a Managed Database, look in the General Information section of your cluster's information page. The Node Plan appears below the Monthly Price. The plan name format is Vultr-Dbaas-[plan type]-[other internal information].
The node plan determines what backup and recovery options are available. See the previous section, "Is the database backed up?" for details.
Yes, you can deploy Vultr Managed Databases for Caching using the Vultr API or Vultr CLI.
Use the Change Plan menu on the Settings tab to scale your cluster up. To scale a cluster down, migrate or fork it to a new, smaller cluster.
You cannot create superuser accounts for managed databases. To create a standard user account, use the Vultr Customer Portal.
A cluster can only have one primary node, but you can configure multiple replica (read-only) nodes.
Maximum memory for Vultr Managed Databases for Caching is set to 70% of the available RAM (minus management overhead) plus 10% for the replication log.
We reserve memory because the following situations can happen:
- When a new Vultr Managed Databases for Caching node connects to the existing master, the master forks a copy of itself and sends current memory contents to the other node.
- Similar forking is done when Vultr Managed Databases for Caching persists its current state on disk. This happens every 10 minutes.
When Vultr Managed Databases for Caching creates a fork of itself, all the memory pages of the new process are identical to the parent and don't consume any extra memory. However, any changes in the parent process cause memory to diverge and the real memory allocation to grow.