Shutting Down and Reviving An Eon Mode Database

An Eon Mode database keeps an up-to-date version of its data and metadata in its communal storage location. After you shut down the database, it continues to reside in communal storage, so you can terminate compute nodes. When you are ready to use the database again, you can revive the database and provision new compute nodes.

You can also drop a database and then revive it and start your Vertica database.

Vertica uses the existing data to restore the database in the same state it was in before you shut it down. You do not need to wait for data to be copied; queries initially fetch data from communal storage as the compute nodes begin to fill their depots.

With the Vertica Management Console on AWS, you can use a wizard to provision a new cluster and revive a database onto it from a browser. See Reviving an Eon Mode Database on AWS in MC for the Management Console revive process.

Databases can be revived using admintools (described below) or through Management Console.

If you need to revive your database on a previously existing cluster, you must revive it using admintools, not MC. For example, use admintools if you stopped a cluster whose hosts use instance storage where data is not persistently stored, and plan to bring back the database on the same cluster.

Vertica persists catalog data in communal storage, updating it every few minutes. Nonetheless, before shutting down your database you should make sure your metadata is up to date on communal storage. To do so, see Synchronizing Metadata.

Revive the Database Using Admintools

Use the following process to revive your Eon Mode database on an existing cluster using admintools.

Using the same communal storage location for multiple running databases causes data corruption. To avoid corruption, never use the revive functionality to simultaneously run the same Eon Mode database on different clusters.

Prerequisites: 

  • In addition to the following, for Eon Mode in an on-premise storage option like Pure Storage, create an auth_params.conf file and set the awsauth and awsendpoint parameters with your credentials and the IP address and port of your on-premise S3 server.
    • awsauth = key:secret
awsendpoint = IP:port

    If you choose not to use TLS with your storage option, you must set awsenablehttps to 0 (default: 1).

    awsenablehttps = 0
  • In addition to the following, for Eon Mode in a cloud storage option, such as AWS:
    • A cluster whose hosts are in the same region as your communal storage location's bucket (To use a cluster in a new region, you must first clone the previous communal storage location to a bucket in the new region)
    • Amazon key pair for SSH access to an instance in the cluster
  • Communal storage location of the stopped Eon Mode database you plan to revive
  • Username and password of the Eon Mode database you plan to revive
  • A cluster with no other running databases
  • IP addresses of all hosts on the cluster

To revive the database:

  1. Use SSH to access a cluster host as an administrator.

  2. For Eon Mode on a cloud storage option such as AWS, run the following:

    $ admintools -t revive_db --communal-storage-location=s3://<directory> -s $HOSTLIST --force -d $DATABASENAME
  3. For Eon Mode on a on-premise storage option such as Pure Storage, run the following: 
    $ admintools -t revive_db -x auth_params.conf --communal-storage-location=s3://<directory> -s $HOSTLIST --force -d $DATABASENAME

Initial queries after revive will read from communal storage, which may take longer. As the database begins to fetch data to depot storage, queries will run faster.