Reviving an Eon Mode Database Cluster

If you have terminated your Eon Mode database's cluster, but have not deleted the database's communal storage, you can revive your database. Reviving the database restores it to the state it was in before you shut it down. The revival process involves creating a new database cluster and configuring it to use the database's communal storage location. See Stopping, Starting, Terminating, and Reviving Eon Mode Database Clusters for more information.

You revive a database using either the Management Console or admintools.

You must use admintools to revive a database onto an existing cluster. The MC only revives databases onto newly-provisioned clusters. 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.

You cannot revive a database from a communal storage location that is currently running on another cluster. The revive process fails if it detects that there is a cluster already running the database. Having two instances of a database running on separate clusters and using the same communal storage location would lead to data corruption.

Reviving Using the Management Console

You use a wizard in Management Console to provision a new cluster and revive a database onto it from a browser. For details, see Reviving an Eon Mode Database on AWS in MC.

Revive Using admintools

You can use admintools to revive your Eon Mode database on an existing cluster. This existing cluster must:

  • Have the same version (or later version) of Vertica installed on it. You can repurpose an existing Vertica cluster whose database you have shut down. Another option is to create a cluster from scratch by manually installing Vertica (see Installing Manually).
  • Contain the same number of nodes the database cluster had when it shut down.

In addition to the database cluster, you must also have:

  • The name of the database to revive (note that the database name is case sensitive)
  • The URL and credentials for the database's communal storage location
  • The user name and password of the database administrator
  • IP addresses of all cluster hosts

Before starting the revive process, verify the following conditions are true for your Eon Mode environment:

Eon environment Revived database requirements
All
  • The uppermost directories of the catalog, data, and depot directories on all nodes exist and are owned by the database dbadmin
  • The cluster has no other database running on it

S3: AWS, on‑premises

The following configuration parameters are set:

If migrating to an on-premises database, set configuration parameter AWSEnableHttps to be compatible with the database TLS setup: AWSEnableHttps=1 if using TLS, otherwise 0. If settings are incompatible, the migration returns with an error.
GCP

The following configuration parameters are set:

Creating a Parameter File

For Eon Mode on-premises and GCP deployments, you must create a configuration file to pass the parameters listed in the table to admintools. Traditionally this file is named auth_params.conf although you can choose any file name you want.

For on-premises Eon Mode databases, this parameter file is the same one you used when initially installing the database. See the following links for instructions on creating a parameter file for the communal storage solution you are using for your database:

To revive an Eon Mode database on GCP manually, create a configuration file to hold the GCSAuth paramater and optionally, the GCSEnableHttp parameter.

You must supply the GCSAuth parameter to enable Vertica to read from the communal storage location stored in GCS. The value for this parameter is the HMAC access key and secret:

GCSAuth = HMAC_access_key:HMAC_secret_key

See Creating an HMAC Key for more information about HMAC keys.

If your Eon Mode database does not use encryption when accessing communal storage on GCS, then disable HTTPS access by adding the following line to auth_params.conf:

GCSEnableHttps = 0

Running the revive_db Tool

Use the admintools revive_db tool to revive the database:

  1. Use SSH to access a cluster host as an administrator.
  2. Depending on your Eon environment, run admintools from the command line as follows:

    • AWS:

      $ admintools -t revive_db \
 --communal-storage-location=s3://communal_store_path \
 -s host1_ip,... -d database_name
    • On-premises using Pure Storage or MinIO: 
      $ admintools -t revive_db -x auth_params.conf \
  --communal-storage-location=s3://communal_store_path \ 
  -s host1_ip,... -d database_name
    • GCP: 
      $ admintools -t revive_db -x auth_params.conf \
  --communal-storage-location=gs://communal_store_path \
  -s host1_ip,... -d database_name

This example revives a six-node on-premises database :

$ admintools -t revive_db -x auth_params.conf \
   --communal-storage-location=s3://mybucket/mydir \
   -s 172.16.116.27,172.16.116.28,172.16.116.29,172.16.116.30,\
   172.16.116.31,172.16.116.32 -d VMart

The following example demonstrates reviving a three-node database hosted on GCP:

$ admintools -t revive_db -x auth_params.conf \
--communal-storage-location gs://mybucket/verticadb \
-s 10.142.0.35,10.142.0.38,10.142.0.39 -d VerticaDB

Attempting to retrieve file: 
   [gs://mybucket/verticadb/metadata/VerticaDB/cluster_config.json]
Validated 3-node database VerticaDB defined at communal storage 
  gs://mybucket/verticadb .
Cluster lease has expired.
Preparation succeeded all hosts
Calculated necessary addresses for all nodes.
Starting to bootstrap nodes. Please wait, databases with a large 
  catalog may take a while to initialize.
>>Calling bootstrap on node v_verticadb_node0002 (10.142.0.38)
>>Calling bootstrap on node v_verticadb_node0003 (10.142.0.39)
Load Remote Catalog succeeded on all hosts
Database revived successfully.

See Also

Concept Link IconSee Also