Reviving an Eon Mode database on AWS in MC
Important
You can also revive a database using admintools. You must use admintools in order to revive a database on an existing cluster. 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.If Management Console has been installed using a CloudFormation template from the AWS Marketplace, you can use the Provision and Revive wizard in Management Console.
During a revive of your database, when you select a Vertica version that is higher than the version of the original database in the communal storage, Vertica upgrades your database to match the Vertica version you selected. This upgrade may cause the database revive to take longer. To bypass this upgrade, select the Vertica version of your original database.
Note
After upgrading a Vertica database, you can not revert to an earlier version.Prerequisites
-
Communal storage location (an AWS S3 bucket) of the stopped Eon Mode database you plan to revive. For guidance, see Viewing and managing your cluster.
-
Username and password of the Eon Mode database you plan to revive.
-
AWS account with permissions to create a VPC, subnet, security group, instances, and roles.
-
Amazon key pair for SSH access to an instance.
Revive the database on the cloud
You use a wizard in Management Console to provision a new cluster on AWS and revive a database onto it. For the new cluster, Management Console automatically provisions the same number of AWS instances used by the database when it was last shut down.
Caution
You should not use the same communal storage location for running multiple databases, as it causes data corruption. To avoid corruption, you should also never use the revive functionality to simultaneously run the same Eon Mode database on different clusters.-
From the Management Console home page, select Revive Eon Mode Database. The Revive an Eon Mode Database wizard opens.
-
Enter your cloud credentials and cluster preferences. Your cluster must be in the same region as your communal storage location's S3 bucket. To revive the cluster in a new region, you must:
-
Create an S3 bucket in the new region.
-
Copy the previous S3 bucket's contents into it.
-
Provide the new S3 bucket URL in Step 3.
-
-
By default, Vertica creates your cluster in the same subnet as your Management Console instance. If you want to manage all Vertica clusters in the same VPC, you can provision your Vertica database in a different subnet than the Management Console instance. To do so, on the AWS Credentials page, select Show Advanced Options and enter a value in the Subnet field.
Important
If you specify a different subnet for your database, make sure to secure the subnet. -
Enter the S3 URL of the database you are reviving. When you enter an S3 bucket location, Management Console discovers all known Eon Mode databases.
-
Select the correct database to revive.
-
Provide the database administrator credentials for the database you are reviving. These credentials are the same as the ones used by the database in the previous cluster.
-
In the Database Version field, choose the desired Vertica database version. Select from the latest hotfix of recent Vertica releases. For each Vertica version, you can select from a list of associated Linux operating systems.
If you select a Vertica version that is higher than the version of the original database in the communal storage, Vertica upgrades your database to match the Vertica version you selected. This upgrade may cause the database revive to take longer. To bypass this upgrade, select the Vertica version of your original database.
Note
After your Vertica database has been upgraded, you can not downgrade your database later. -
Choose instance types for the cluster. Management Console provisions the same number of instances used by the database when it was last shut down.
The MC populates the existing paths for the depot, catalog, and temp directories.
Note
You cannot persist the catalog with ephemeral instances.The last step displays a confirmation page showing the configured volumes. For details on the volume configurations that MC provides, see Eon Mode volume configuration defaults for AWS and Enterprise Mode volume configuration defaults for AWS.
Caution
To ensure against data loss, choose instances that use EBS storage. EBS storage is durable, while instance store is temporary. For Eon mode, Management Console displays an alert to inform the user of the potential data loss when terminating instances that support instance store. -
Choose whether to encrypt your EBS volumes. With AWS, only 4th and 5th generation instance types (c4, r4, and m4; c5, r5, and m5) support encrypting EBS volumes.
-
Optionally, you can tag the instances. In the Tag EC2 instances field, if another cluster is already running, Management Console fills those fields with the tag values for the first instance in the cluster. You can accept the defaults, or enter new tag values.
-
Review your choices, accept the license agreement, and click Create to revive the database on a new cluster. If the version of Management Console you use to revive is higher than that of the database, Management Console first notifies you that it is about to automatically upgrade the database. After starting the revive process, the wizard displays its progress. After a successful revive, the database starts automatically.
Important
If the database fails to start automatically, check the controlmode setting in /opt/vertica/config/admintools.conf. This setting must be compatible with the network messaging requirements of your Eon implementation. AWS relies on unicast messaging, which is compatible with a controlmode setting of point-to-point (pt2pt). If the source database controlmode setting was broacast and you migrate to S3/AWS communal storage, you must change controlmode with admintools:
$ admintools -t re_ip -d dbname -T
When the revive process is complete, click Get Started to navigate to the Databases page.