Intermittent connection problem with Vertica 8.1.1

Hi,

From my experience, those VSQL/JDBC errors typically mean that the client lost connectivity to the server for some reason (i.e. network timeout / it was closed via the CLOSE_SESSION function).

But you are saying they get the error immediately when typing vsql? And you say admintools says the database is down? If the DB is down, you normally get a different error:

[dbadmin@s18384357 v_sfdc_node0001_catalog]$ admintools -t list_allnodes | grep sfdc
 v_sfdc_node0001               | 74.208.100.58 | DOWN  | vertica-9.0.1.0 | sfdc

[dbadmin@s18384357 v_sfdc_node0001_catalog]$ vsql
vsql: could not connect to server: Connection refused
        Is the server running on host "???" and accepting
        TCP/IP connections on port 5433?

Have you tried connecting using IP (vsql -h)? JDBC client connects using public IP?

At the time when admintools reports DB down, can you execute queries from any of the still active connections?

Hmm. @praveshbhardwaj,that's a good point about private vs. public IPs. If they do have separate networks @Bernard92 can try vsql -h [private_ip] vs. vsql -h [public_ip]. Do you get the same error?

Anyway, I would think those "connected" clients will report the same error (server closed the connection unexpectedly) when they try to run a query as I bet they aren't really connected anymore. Note VSQL used in interactive mode will try to reconnect after getting the error.

Other possibilities:

Is spread not up on each node?

ps -ef | grep [^]]spread

What does dbadmin say about the node status for each node? DOWN or UNKNOWN?

admintools -t list_allnodes | grep <<dbname>>

If Vertica process actually remains running and admintools reports DB as DOWN, I would look for IP configuration. Check admintools and spread config to see what interface both are configured on.

As Jim suggested, vsql -h on both public and private IP should suggest something. Since you said embedded installation, I assume it's single node installation, so ruling out load balancer.

yes , this is a embedded installation with a single node , and only 1 public IP
I'll try next time to connect using the -h option
The remaining active sessions are batch sessions run by the HybridIT containers , so we don't really have control on them
spread was still up when we had the last hang

The ITOM/HybridIT people have finally fixed the problem , it seems the Vertica installation needs to be setup with SSL enabled and configured.
Any idea why it would generate these intermittent problem ?
I am a bit puzzled