Reviving an Eon Mode Database Cluster
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 can use a wizard in the Management Console to provision a new cluster and revive a database onto it from a browser. For details, see:
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.
If you do not know what version of Vertica created the database or are unsure how many nodes it had, see Finding Details About the Database that Created a Communal Storage Location below.
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 |
|
|
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:
|
Finding Details About the Database that Created a Communal Storage Location
To revive a database, you must know the version of Vertica that created it (so you can use the same or later version) and the number of nodes the cluster had when it shut down. If you do not know these details, you can determine them based on the contents of the communal storage location.
If you are not sure which version of Vertica created the database stored in a communal storage location, examine the cluster_config.json file. This file is stored in the communal storage location in the folder named metadata/databasename. For example, suppose you have a database named mydb stored in the communal storage location s3://mybucket/mydb. Then you can download and examine the file s3://mybucket/mydb/metadata/mydb/cluster_config.json.
In the cluster_config.json, the database version of Vertica that created the database is stored with the JSON key named DatabaseVersion near the top of the file:
{
"CatalogTruncationVersion" : 804,
"ClusterLeaseExpiration" : "2020-12-21 21:52:31.005936",
"Database" : {
"branch" : "",
"name" : "verticadb"
},
"DatabaseVersion" : "v10.1.0",
"GlobalSettings" : {
"TupleMoverServices" : -33,
"appliedUpgrades" : [. . .
In this example, you can revive the storage location using Vertica version 10.1.0 or later.
If do not know how many nodes the cluster had when it shut down, use the --display-only option of the admintools revive_db tool. Adding this option prevents admintools from reviving the database. Instead, it validates the files in the communal storage and reports details about the nodes that made up the database cluster. Part of this report is the number of nodes in the cluster:
$ admintools -t revive_db --display-only --communal-storage-location \
s3://mybucket/verticadb -d verticadb
Attempting to retrieve file: [s3://mybucket/verticadb/metadata/verticadb/cluster_config.json]
Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.
Expected layout of database after reviving from communal storage: s3://mybucket/verticadb
== Communal location details: ==
{
"communal_storage_url": "s3://mybucket/verticadb",
"num_shards": "3",
"depot_path": "/vertica/data",
. . .
You can use grep to find just the relevant line in the report:
$ admintools -t revive_db --display-only --communal-storage-location \
s3://mybucket/verticadb -d verticadb | grep 'Validated'
Validated 6-node database verticadb defined at communal storage s3://mybucket/verticadb.
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 parameter 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:
- Use SSH to access a cluster host as an administrator.
- Depending on your environment, run one of the following admintools command lines:
-
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