This blog post was authored by Mark Hayden.
You can deploy a Vertica cluster running in Eon or Enterprise mode using EC2 instances that support EBS volumes. This document provides the steps you need to use EBS volumes that were preserved from a Vertica cluster that was terminated, and how to reattach them to revive a Vertica database.
Vertica in Eon mode has a revive database feature you can use to revive your cluster from communal storage. If you shut down your database, and terminate EC2 instances without saving the EBS volumes, you can provision a new cluster and then use admintools or Management Console to revive the database from files saved on communal storage. Reviving the database from communal storage is simple and fast. However, when you revive the database, you lose the state of the depot, vertica.log, and data collector tables prior to cluster termination. You may see some performance degradation immediately after you revive the database, but as you start using the database and the depot gets repopulated, the performance will be restored.
If you are using instances with EBS volumes, you also have the option of terminating the instances, while preserving EBS volumes. Then, the EBS volumes can be attached to new instances after you re-deploy your cluster. With this option, you get the state of depot, vertica.log, and data collector table prior to cluster termination. To reuse EBS volumes, follow these steps:
1. Stop your database cleanly. This ensures you have the most up to date copy of the data and catalog on the communal storage location.
2. For each EBS volume that is being used for Vertica and is attached to your current cluster, ensure that the AWS DeleteOnTermination property is set to ‘False’. You must do this through the command line API by following this instructions
here.
3. If /opt/vertica is not on one of the EBS volumes you are saving, copy and backup /opt/vertica/config/admintools.conf in a secure location.
4. Take note of the current IP addresses of your cluster and their node mapping.
5. Take note of the old volume IDs or tag those volumes. You will need to locate these volumes in the future to successfully rebuild the cluster.
6. Terminate your instances. Because of the settings we did in Step 2, the EBS volumes will continue to exist. AWS will continue to charge the price of EBS per GB.
7. When you need the database again, deploy new EC2 instances in the exact same region and availability zone as your former cluster.
8. Attach one of the old EBS volumes to each of the new instances. You can do this using the command line. You can find your AWS volumes
here. Then, right-click and select Attach Volume, and select an instance.
9. The volumes are now attached to the instances, but they are not yet mounted. ssh to each instance and run a mount command to mount the volume to the same mount point as the original instances. At this point, you should see the old catalog files on the mounted filesystem.
10. Try to view your database with admintools. If it does not exist, then you must restore your admintools metadata. Copy your backed up admintool.conf to /opt/vertica/conf/admintools.conf and the database should reappear.
11. Take note of your new IP addresses. This step is optional.
12. Using the old and new IP addresses, build a mapping file as described in the
Vertica documentation. This step is optional.
13. Run ‘admintools –t re–ip’ pointing at your mapping file. This step is optional.
14. Start your database.
