The first thing to check would be whether on host restart any firewall rules got reactivated. Frequently iptables rules are manually turned off but the system config is not set up to keep them off during a restart. When the host is restarted and rules are reactivated it can block the spread and/or node to node communications. If you find the spread and vertica processes running on the node but being reported as down then chances are good it's sitting wiating for the rest of the cluster to invite it but not getting the invitation due to commss issues.
If you don't have any firewall active then next check to see if the spreadd daemon is running (ps -ef | grep spread). Whether it is or not, kill the vertica process if it's running, then restart spread using "/etc/init.d/spreadd restart", then retry starting the node.
The vertica.log file in the catalog path on the node can be reviewed to see what the most recent activities on the node were and if there were any failures noted on restart attempt.
Comments
The first thing to check would be whether on host restart any firewall rules got reactivated. Frequently iptables rules are manually turned off but the system config is not set up to keep them off during a restart. When the host is restarted and rules are reactivated it can block the spread and/or node to node communications. If you find the spread and vertica processes running on the node but being reported as down then chances are good it's sitting wiating for the rest of the cluster to invite it but not getting the invitation due to commss issues.
If you don't have any firewall active then next check to see if the spreadd daemon is running (ps -ef | grep spread). Whether it is or not, kill the vertica process if it's running, then restart spread using "/etc/init.d/spreadd restart", then retry starting the node.
The vertica.log file in the catalog path on the node can be reviewed to see what the most recent activities on the node were and if there were any failures noted on restart attempt.