You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I previously opened #17246 and continued discussion with @harshit-gangal in the community slack. The common decision was to create a feature request for it.
This is a feature request to have some mechanism to run select @@vtgate_hostname; or select @@vtgate_id; from the client and retrieving hostname/host id of the vtgate on the other end of the connection.
Use Case(s)
For the following use case on our side this would be very helpful and save us hours of debugging:
We have our application deployed in 3 different AZ's, similarly vtgate is also deployed in 3 different AZ's and application creates connection to vtgate over a layer 4 load balancer. Rarely we see increased database latency metrics on subset of the application instances. After hours of debugging we figured out requests from one specific AZ to another one had an intermittent issue on cloud provider side and this was the reason. If we'd known which application instance is connected to which vtgate in advance, we could have quickly notice the latency pattern.
The text was updated successfully, but these errors were encountered:
How would you use this feature? Would you add a select @@vtgate_hostname before every query in the client, and store the result in some kind of trace? It will be helpful to understand the intended usage more clearly. It will be no use to issue it after the fact, it has to go along with the query you are trying to trace.
Hi @deepthi , I was planning to use it as a separate query. Assume there is an application that creates a persistent connection to vtgate (actually one of many vtgates behind a layer 4 load balancer) and uses the same connection for all the queries. When it creates the connection, I want it to run select @@vtgate_hostname; and log which one it is connected to so that when we have an issue because of the middle proxy load balancer or some other external factor we can have some clue regarding what is going on.
By the way, it is not that crucial, but a something good-to-have for us. If adding this feature creates too much headache, you can skip. it is not a big deal.
Feature Description
Hello, I previously opened #17246 and continued discussion with @harshit-gangal in the community slack. The common decision was to create a feature request for it.
This is a feature request to have some mechanism to run
select @@vtgate_hostname;
orselect @@vtgate_id;
from the client and retrieving hostname/host id of the vtgate on the other end of the connection.Use Case(s)
For the following use case on our side this would be very helpful and save us hours of debugging:
We have our application deployed in 3 different AZ's, similarly vtgate is also deployed in 3 different AZ's and application creates connection to vtgate over a layer 4 load balancer. Rarely we see increased database latency metrics on subset of the application instances. After hours of debugging we figured out requests from one specific AZ to another one had an intermittent issue on cloud provider side and this was the reason. If we'd known which application instance is connected to which vtgate in advance, we could have quickly notice the latency pattern.
The text was updated successfully, but these errors were encountered: