Bug 1270755 - [RFE] Need to know which host is the master when using stick on dst
Summary: [RFE] Need to know which host is the master when using stick on dst
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: haproxy
Version: 7.3
Hardware: All
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Ryan O'Hara
QA Contact: Brandon Perkins
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-12 10:09 UTC by Raoul Scarazzini
Modified: 2015-10-17 15:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-17 15:10:57 UTC
Target Upstream Version:


Attachments (Terms of Use)

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';".


Note You need to log in before you can comment on or make changes to this bug.