Administration

Debugging Client Issues with Client Side Logging

0

In a prior blog on Native Vertica Load Balancing, I mentioned that there are “At Least” 3 things that must be implemented in order for Vertica Native Load Balancing to work. This post will show how you can use client side logging to track connectivity issues that can help with implementing capabilities like Vertica Load Balancing.

After I implemented the 3 required steps for load balancing I was unable to connect to Vertica with the settings enabled. I was trying to use DbVisualizer to run a query in Vertica with all the load balancing settings explained in the prior blog but I got a timeout trying to connect. Here was the message:

After receiving this message I decided to turn on Vertica Client Logging by changing the following settings in DbVisualizer. Notice below I also have the connectionloadbalance parameter set to true.

log1

Note: Every JDBC tool will have a different way on how to enable the connection settings; but for DbVisualizer it is done under the properties tab of the connections.

There are different levels for logging but in my case I wanted ‘debug’ so I can get the most amount of information to troubleshoot. Be sure to turn this uncheck this option after troubleshooting since this will have a negative impact on performance.

Once you turn logging on in the client driver, you should see something such as the following which provides detailed information showing that load balancing is turned on. In my case I sent the output to the /tmp directory.

After waiting for some time I received the following error in my client.

I then checked my log again and noticed the following stack trace:

Troubleshooting Tips

In my case I noticed that I can ping bi.mycompany.com which resolves to a 158.23.24.151 address. However, when load balancing kicks in I receive an IP of 10.62.55.200, port 5433.

This is an indication that a firewall issue on the server side is returning the internal IP address not the external IP address. The following query should provide more information on which IP is getting returned:

This indeed did identify the root cause to the problem that the IP address being returned was the internal IP and not the IP on the customer network starting with 158.

A Vertica KB article can be provided to the DBA to enable the server side setup for this to work. The section titled “Configuring the System to Use the Public Network” contains the appropriate steps to fix the IP address problem. Now when I reconnect and run my queries I can see that Vertica Native Load Balancing is working.

Using sessionlabel Setting to Track Queries

Another helpful tip when troubleshooting is to add a sessionlabel.

log2

In my case I added a sessionlabel named warnerbros so I know when I run queries against the session table I can easily track my session:

The other nice thing about adding the sessionlabel is that it also gets logged to the Vertica log. This makes it easy for finding your information within all the other activity in the database.

You can also implement session labels and client side logging using the address syntax of:

About the author / 

Mark Warner

Mark Warner previously worked for Vertica for nearly 4 years with the Partner Engineering team. Mark is currently an Integration Engineer working with Vertica for Tapjoy; a mobile platform for publishers.

Leave a Reply

Upcoming Events

  • No upcoming events
AEC v1.0.4

Subscribe to Blog via Email

Enter your email address to subscribe and receive notifications of new posts by email.

Read more use cases here.

Notice

This site is not affiliated, endorsed or associated with HPE Vertica. This site makes no claims on ownership of trademark rights. The author contributions on this site are licensed under CC BY-SA 3.0 with attribution required.
%d bloggers like this: