Bug 1270755

Summary: [RFE] Need to know which host is the master when using stick on dst
Product: Red Hat Enterprise Linux 7 Reporter: Raoul Scarazzini <rscarazz>
Component: haproxyAssignee: Ryan O'Hara <rohara>
Status: CLOSED WONTFIX QA Contact: Brandon Perkins <bperkins>
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.3Keywords: FutureFeature, Reopened
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-17 15:10:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Raoul Scarazzini 2015-10-12 10:09:56 UTC 
Description of problem:

There is no easy way to understand which host is the master when using a configuration with stick on dst (as described here http://blog.haproxy.com/2014/01/17/emulating-activepassing-application-clustering-with-haproxy/).

Version-Release number of selected component (if applicable):

haproxy-1.5.4-4.el7_1.1.x86_64

How reproducible:

You need to have at least 3 server, in a conf like this one:

listen mysql
  bind 172.16.20.10:3306 
  option tcpka
  option httpchk
  stick on dst
  stick-table type ip size 1000
  timeout client 0
  timeout server 0
  server overcloud-controller-0 172.16.20.12:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2
  server overcloud-controller-1 172.16.20.15:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2
  server overcloud-controller-2 172.16.20.13:3306 backup check fall 5 inter 2000 on-marked-down shutdown-sessions port 9200 rise 2

In such configuration the only way you have to understand which of the three servers haproxy is pointing is to check the stats and see on which server they are increasing.
As described here https://www.redhat.com/archives/rdo-list/2015-October/msg00058.html I made a script to do this, but from my point of view it's an incorrect approach, since this kind of information might be given in a native way, for example in a specific field on the stats.

Are there some contraindications in adding this field that I'm ignoring?

Thanks,

Raoul
Comment 2 Ryan O'Hara 2015-10-12 22:42:55 UTC 
This is not a bug. I've already replied to the original question on the mailing list and I'll do so again here.

It is quite possible that the only node that will have anything stored in the stick table will be the one that owns the VIP. Perhaps a better way to state this is that the only node that will be able to tell you which backend server that is currently the "master" is the one that owns the VIP. If you know which node owns the VIP (which you do), simply dump the stick table on that node and you will see the current "master". If you dump the stick table on a node that does not own the VIP, you haven't discovered anything except which server *was* the "master" when that node owned the VIP. If it never owned the VIP, the stick table will be empty.

Perhaps a better approach here is to simple send an SQL query for the hostname to the database VIP.
Comment 3 Raoul Scarazzini 2015-10-13 07:31:07 UTC 
Ryan, as in the subject this is an RFE, not properly a bug. But anyway, maybe I am missing something. Dumping the stick table on the node that owns the VIP gives me only a result like this:

[root@overcloud-controller-1 ~]# echo "show table mysql" | socat
/var/run/haproxy stdio
# table: mysql, type: ip, size:1000, used:1
0x7f9babb4d7d4: key=172.16.20.11 use=0 exp=0 server_id=1

How can I from these informations understand which is the master? Maybe you are talking about another way of dumping the stick table? Because here the "key" value is the VIP itself (and as you said I already know it) not one of the three servers which I would expect.
Comment 4 Ryan O'Hara 2015-10-14 13:21:52 UTC 
(In reply to Raoul Scarazzini from comment #3)
> Ryan, as in the subject this is an RFE, not properly a bug. But anyway,
> maybe I am missing something. Dumping the stick table on the node that owns
> the VIP gives me only a result like this:
> 
> [root@overcloud-controller-1 ~]# echo "show table mysql" | socat
> /var/run/haproxy stdio
> # table: mysql, type: ip, size:1000, used:1
> 0x7f9babb4d7d4: key=172.16.20.11 use=0 exp=0 server_id=1
> 
> How can I from these informations understand which is the master? Maybe you
> are talking about another way of dumping the stick table? Because here the
> "key" value is the VIP itself (and as you said I already know it) not one of
> the three servers which I would expect.

The server with server_id=1 is the current "active" server. I'd avoid calling this the "master". You can get more information about that server if you dump the information about the backend for that particular proxy.

I really think the easiest way to detemine the current active database server is to query the VIP for the hostname, eg. "show variables like 'hostname';".