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

Bug #24584	ServerPort + PortNumber marked as OBSOLETE in manual
Submitted:	25 Nov 2006 12:33	Modified:	3 Nov 19:01
Reporter:	Mikael Ronstrom
Status:	Closed
Category:	Server: Cluster	Severity:	S3 (Non-critical)
Version:	mysql-5.1	OS:	Any
Assigned to:	Magnus Blaudd	Target Version:
Tags:	5.0+5.1
Triage:	Triaged: D3 (Medium) / R2 (Low) / E6 (Needs Assessment)

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.