Installing Vertica with the Installation Script

--help

--hosts host_list, 
-s host_list

A comma-separated list of host names or IP addresses to include in the cluster. Do not include spaces in the list. The IP addresses or hostnames must be for unique hosts. You cannot list the same host using multiple IP addresses/hostnames.

Examples:

--hosts host01,host02,host03
-s 192.168.233.101,192.168.233.102,192.168.233.103

--rpm package_name,
--deb package_name,
-r package_name
                

The name of the RPM or Debian package. The install package must be provided if you are installing or upgrading multiple nodes and the nodes do not have the latest server package installed, or if you are adding a new node. The install_vertica and update_vertica scripts serially copy the server package to the other nodes and install the package. If you are installing or upgrading a large number of nodes, then consider manually installing the package on all nodes before running the upgrade script, as the script runs faster if it does not need to serially upload and install the package on each node.

Example:

--rpm vertica_8.1.x.x86_64.RHEL6.rpm

--data-dir data_directory,
-d data_directory

The default directory for database data and catalog files. The default is /home/dbadmin.

--temp-dir directory

The temporary directory used for administrative purposes. If it is a directory within /opt/vertica, then it will be created by the installer. Otherwise, the directory should already exist on all nodes in the cluster. The location should allow dbadmin write privileges.

The default is /tmp.

--dba-user dba_username,
-u dba_username

The name of the Database Administrator system account to create. Only this account can run the Administration Tools. If you omit the --dba-user parameter, then the default database administrator account name is dbadmin.

This parameter is optional for new installations done as root but must be specified when upgrading or when installing using sudo. If upgrading, use the -u parameter to specify the same DBA account name that you used previously. If installing using sudo, the user must already exist.

--dba-group GROUP,
-g GROUP

The UNIX group for DBA users. The default is verticadba.

--dba-user-home dba_home_directory,
-l dba_home_directory  

The home directory for the database administrator. The default is /home/dbadmin.

--dba-user-password 
dba_password,
-p dba_password

The password for the database administrator account. If not supplied, the script prompts for a password and does not echo the input.

--dba-user-password-disabled

--spread-logging,
-w

Configures spread to output logging output to /opt/vertica/log/spread_<hostname>.log. Does not apply to upgrades.

--ssh-password password,
-P password

The password to use by default for each cluster host. If not supplied, and the -i option is not used, then the script prompts for the password if and when necessary and does not echo the input. Do not use with the -i option.

Special note about password:

If you run the install_vertica script as root, specify the root password with the -P parameter:

# /opt/vertica/sbin/install_vertica -P <root_passwd>

If, however, you run the install_vertica script with the sudo command, the password for the -P parameter should be the password of the user who runs install_vertica, not the root password. For example if user dbadmin runs install_vertica with sudo and has a password with the value dbapasswd, then the value for -P should be dbapasswd:

$ sudo /opt/vertica/sbin/install_vertica -P dbapasswd

--ssh-identity file,
-i file

The root private-key file to use if passwordless ssh has already been configured between the hosts. Verify that normal SSH works without a password before using this option. The file can be private key file (for example, id_rsa), or PEM file. Do not use with the --ssh-password/-P option.

Vertica accepts the following:

• By providing an SSH private key which is not password protected. You cannot run the install_verticascript with the sudo command when using this method.
• By providing a password-protected private key and using an SSH-Agent. Note that sudo typically resets environment variables when it is invoked. Specifically, the SSH_AUTHSOCK variable required by the SSH-Agent may be reset. Therefore, configure your system to maintain SSH_AUTHSOCK or invoke the install_vertica command using a method similar to the following: sudo SSH_AUTHSOCK=$SSH_AUTHSOCK /opt/vertica/sbin/install_vertica ...

--config-file file,
-z file  

Accepts an existing properties file created by --record-config file_name. This properties file contains key/value parameters that map to values in the install_vertica script, many with Boolean arguments that default to false.

--add-hosts host_list,
-A host_list

A comma-separated list of hosts to add to an existing Vertica cluster.

--add-hosts modifies an existing installation of Vertica by adding a host to the database cluster and then reconfiguring the spread. This is useful for increasing system performance or setting K-safety to one (1) or two (2).

Notes:

• If you have used the -T parameter to configure spread to use direct point-to-point communication within the existing cluster, you must use the -T parameter when you add a new host; otherwise, the new host automatically uses UDP broadcast traffic, resulting in cluster communication problems that prevent Vertica from running properly.

  Examples:

  --add-hosts host01
  --add-hosts 192.168.233.101

• The update_vertica script described in Adding Nodes calls the install_vertica script to update the installation. You can use either the install_vertica or update_vertica script with the --add-hosts parameter.

--record-config file_name,
-B file_name

Accepts a file name, which when used in conjunction with command line options, creates a properties file that can be used with the --config-file parameter. This parameter creates the properties file and exits; it has no impact on installation.

--clean

Forcibly cleans previously stored configuration files. Use this parameter if you need to change the hosts that are included in your cluster. Only use this parameter when no database is defined. Cannot be used with update_vertica.

--license { license_file | CE },
-L { license_file | CE }

Silently and automatically deploys the license key to /opt/vertica/config/share. On multi-node installations, the –-license option also applies the license to all nodes declared in the --hosts host_list. To activate your license, use the –-license option with the –-accept-eula option. If you do not use the –-accept-eula option, you are asked to accept the EULA when you connect to your database. Once you accept the EULA, your license is activated.

If specified with CE, automatically deploys the Community Edition license key, which is included in your download. You do not need to specify a license file.

Examples:

--license CE
--license /tmp/vlicense.dat

--remove-hosts host_list,
-R host_list

A comma-separated list of hosts to remove from an existing Vertica cluster.

--remove-hosts modifies an existing installation of Vertica by removing a host from the database cluster and then reconfiguring the spread. This is useful for removing an obsolete or over-provisioned system. For example:

---remove-hosts host01
-R 192.168.233.101

Notes:

• If you used the -T parameter to configure spread to use direct point-to-point communication within the existing cluster, you must use -T when you remove a host; otherwise, the hosts automatically use UDP broadcast traffic, resulting in cluster communication problems that prevents Vertica from running properly.
• The update_vertica script described in Removing Nodes in the Administrator's Guide calls the install_vertica script to perform the update to the installation. You can use either the install_vertica or update_vertica script with the -R parameter.

--control-network { BCAST_ADDR | default },
-S { BCAST_ADDR | default }

Takes either the value 'default' or a broadcast network IP address (BCAST_ADDR) to allow spread communications to be configured on a subnet that is different from other Vertica data communications. --control-network is also used to force a cluster-wide spread reconfiguration when changing spread related options.

Examples:

--control-network default
--control-network 10.20.100.255

--point-to-point,
-T

Configures spread to use direct point-to-point communication between all Vertica nodes. You should use this option if your nodes aren't located on the same subnet. You should also use this option for all virtual environment installations, regardless of whether the virtual servers are on the same subnet or not. The maximum number of spread daemons supported in point-to-point communication in Vertica is 80. It is possible to have more than 80 nodes by using large cluster mode, which does not install a spread daemon on each node.

Cannot be used with --broadcast, as the setting must be either --broadcast or --point-to-point.

Important: When changing the configuration from --broadcast (the default) to --point-to-point or from --point-to-point to --broadcast, the --control-network parameter must also be used.

--broadcast,
-U

Specifies that Vertica use UDP broadcast traffic by spread between nodes on the subnet. This parameter is automatically used by default. No more than 80 spread daemons are supported by broadcast traffic. It is possible to have more than 80 nodes by using large cluster mode, which does not install a spread daemon on each node.

Cannot be used with --point-to-point, as the setting must be either --broadcast or --point-to-point.

Important: When changing the configuration from --broadcast (the default) to --point-to-point or from --point-to-point to --broadcast, the --control-network parameter must also be used.

--accept-eula,
-Y

Silently accepts the EULA agreement. On multi-node installations, the --accept-eula value is propagated throughout the cluster at the end of the installation, at the same time as the Administration Tools metadata.

Use the --accept-eula option with the --license option to activate your license.

--no-system-configuration

By default, the installer makes system configuration changes to meet server requirements. If you do not want the installer to change any system properties, then use the --no-system-configuration. The installer presents warnings or failures for configuration settings that do not meet requirements that it normally would have automatically configured.

--failure-threshold

Stops the installation when the specified failure threshold is encountered.

Options can be one of:

• HINT - Stop the install if a HINT or greater issue is encountered during the installation tests. HINT configurations are settings you should make, but the database runs with no significant negative consequences if you omit the setting.
• WARN (default) - Stop the installation if a WARN or greater issue is encountered. WARN issues may affect the performance of the database. However, for basic testing purposes or Community Edition users, WARN issues can be ignored if extreme performance is not required.
• FAIL - Stop the installation if a FAIL or greater issue is encountered. FAIL issues can have severely negative performance consequences and possible later processing issues if not addressed. However, Vertica can start even if FAIL issues are ignored.
• HALT - Stop the installation if a HALT or greater issue is encountered. The database may not be able to be started if you choose his option. Not supported in production environments.
• NONE - Do not stop the installation. The database may not start. Not supported in production environments.

--large-cluster, 
-2 
[ <integer> | DEFAULT ]

Enables a large cluster layout, in which control message responsibilities are delegated to a subset of Vertica Analytic Database nodes (called control nodes) to improve control message performance in large clusters. Consider using this parameter with more than 50 nodes.

Options can be one of:

• <integer>—The number of control nodes you want in the cluster. Valid values are 1 to 120 for all new databases.
• DEFAULT—Vertica Analytic Database chooses the number of control nodes using calculations based on the total number of cluster nodes in the --hosts argument.

For more information, see Large Cluster in the Administrator's Guide.