MySQL Bugs: #24584: ServerPort + PortNumber marked as OBSOLETE in manual

Bug #24584	ServerPort + PortNumber marked as OBSOLETE in manual
Submitted:	25 Nov 2006 11:33	Modified:	3 Nov 2009 18:01
Reporter:	Mikael Ronström	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1	OS:	Any
Assigned to:	Magnus Blåudd	CPU Architecture:	Any
Tags:	5.0+5.1

Description:
I read in the manual for MySQL 5.0 in the configuration directory that the variable ServerPort is
obsolete.

Is this really the idea? A very simple configuration and certainly not uncommon is to place the
management server in another network domain from the ndbd nodes. In this case it is necessary
to open the firewall between the domains on the port used by the ndbd node so that the management
server can connect to the ndbd node. I don't know of any other mechanisms other than setting up
ServerPort or PortNumber on TCP/IP Connections (which is also marked as OBSOLETE).

If anyone argues that one always have all nodes in the same domain please remember that we require
a third node as management server to bear the role as arbitrator and it is even a good idea to use an
existing machine in the network (which usually resides in another domain) as this management server.

So unless someone can show how to do instead I suggest to remove the word OBSOLETE from
these parameters in the manual since they are very much non-OBSOLETE and even ESSENTIAL rather.

How to repeat:
Read manual

Suggested fix:
Remove the word OBSOLETE from ServerPort + PortNumber in manual on MySQL Cluster
Configuration (at least 5.0 + 5.1)

ServerPort and PortNumber parameters were marked as OBSOLETE on instructions from the Cluster developers. I'm changing the category of this bug to Cluster and setting Calvin to lead while you lot sort this out, then you can let me know what you decide.

Thanks.

Examining this in MySQL Cluster 6.3 I find:
1) The PortNumber for an individual connection will not be used. In fact it will be overwritten with a calculated value and a warning printed to ndbout.
2) The value will be calulated as:
  a) if either node is a MGM node, its PortNumber will be used since it's already
     a server port and also well known.
  b) use ServerPort of the node ie. "[DB] ServerPort=xxx"(this is the port to configure in the firewall)
  c) use PortNumber from the DEFAULT section. ie "[DB DEFAULT] PortNumber=xxx"
     (probably also "[DB] PortNumber=xxx")
     and increase this value with one for each connection. This is referred
     to as the "old way" and should not be used (or documented?).
  d) If none of the above, set PortNumber of the connection to 0 and thus
     use "dynamic ports" which is the preferred way and thus the default
     if nothing has been specified.

This means that to be able to open ports in a firewall, one should use
[DB [DEFAULT]]
ServerPort=xxx
and then open port xxx for incoming connections from API nodes.

The connection from DB to MGM will always be done to the ndb_mgmd's management port so outgoing connections to that should be allowed.

Will mark PortNumber for TCP, SHM and SCI as deprecated.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/89087

Pushed to 6.3 and 7.0.10

Documented bugfix in the NDB-6.3.29 and 7.0.10 changelogs as follows:

        Deprecation and usage information obtain from ndb_config
        regarding the PortNumber and ServerPort configuration parameters
        was improved.

Also updated Manual concerning these parameters using info from Magnus.

Closed.