MySQL Bugs: #38590: Connection string with node-id specified fails to use connection-pool feature

Bug #38590	Connection string with node-id specified fails to use connection-pool feature
Submitted:	6 Aug 2008 0:45	Modified:	7 Apr 2014 12:38
Reporter:	Adam Dixon	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.2	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	cge6.2.16bzr

Description:
The manual states exactly this;
"Multiple management nodes. When using multiple management servers:
* You must give nodes explicit IDs in connectstrings because automatic allocation of node IDs does not work across multiple management servers. "

That indicates that the two mgmd nodes do not communicate which node-id is given to which API, so they must be statically set.

So this means that you will need to pass an option to your mysqld_safe that looks something like this;
--ndb-connectstring=nodeid=6,127.0.0.1:1186,127.0.0.1:1196 &

If you do this, and say, also use --connection-pool=3

MySQL error log shows this;
080806 10:07:39 [Note] NDB: NodeID is 6, management server '127.0.0.1:1186'
080806 10:07:39 [Note] NDB[0]: all storage nodes connected
Configuration error: Error : Could not alloc node id at 127.0.0.1 port 1186: Id 6 already allocated by another node.
080806 10:07:51 [Warning] NDB[1]: starting connect thread
Configuration error: Error : Could not alloc node id at 127.0.0.1 port 1186: Id 6 already allocated by another node.
Configuration error: Error : Could not alloc node id at 127.0.0.1 port 1186: Id 6 already allocated by another node.
080806 10:08:16 [Warning] NDB[2]: starting connect thread
Configuration error: Error : Could not alloc node id at 127.0.0.1 port 1186: Id 6 already allocated by another node.

And indeed they are not connected in ndb_mgm -e 'show'
[mysqld(API)]	4 node(s)
id=6	@127.0.0.1  (mysql-5.1.24 ndb-6.2.16)
id=7 (not connected, accepting connect from any host)
id=8 (not connected, accepting connect from any host)
id=9 (not connected, accepting connect from any host)

How to repeat:
See initial desc.

comment: i think the documentation is wrong,
"must use fix node ids when using multiple ndb_mgmd", 99.3% sure

I think it should also be added to manual, that explicit node id can't
currently be using with connection pool...
(dont really know how that should work...)

bernhard, please also check with tomas.

overall triage of the "problem" what ever it is:
W5: dont use fix id
I3: i can easily see several people tripping on this

R3/E3: if fix is silently ignoring node-id
R1/E1: if fixing docs

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

can we fix the manual together ?

Changed category to Docs, lead to Stefan.

> Multiple management nodes. When using multiple management servers:
> * You must give nodes explicit IDs in connectstrings because automatic   
>   allocation of node IDs does not work across multiple management servers.

At the time this was written, a couple of years ago, it was true. (I'm pretty sure that I ran into this problem myself, at that time.)

So we really have 2 issues here.

1. Specifying node IDs is no longer a requirement when using more than one MGM.

2. Specifying node IDs breaks connection pooling.

I believe that (1) is, in Docs-speak, 'a known issue which has since been resolved', and the documentation must be updated to reflect this. However, I am obligated to document *when* this issue was resolved.

As regards (2), I am also agreeable to documenting this. However, I need to know whether this is (a) an issue which we intend to fix in future (IOW a bug), or (b) expected behaviour.

So before I can handle this in the docs, I need these 2 questions answered.

After the docs are updated, the resolution of the current bug report depends on the answer to the second question: If the current behaviour (using explicit node IDs breaks connection pooling) is expected behaviour, I can then close this bug (and I shall do so); if the current behaviour is regarded as something that needs to be fixed, then I need to change the category/status of this bug report to Server:Cluster/Verified, so that the devs will know to fix it (and I shall make that change).

Does this sound reasonable/logical?

Thanks!

Changed Category/Lead, removed myself as assignee.

A developer needs to answer my questions above, then change Category/Status/Lead/Assignee back to Docs/Verified/Stefan/me.

Thanks!

Thank you for taking the time to report a problem.  Unfortunately you are not using a current version of the product you reported a problem with -- the problem might already be fixed. Please download a new version from http://www.mysql.com/downloads/

If you are able to reproduce the bug with one of the latest versions, please change the version on this bug report to the version you tested and change the status back to "Open".  Again, thank you for your continued support of MySQL.