WL#3683: Increase number of data nodes from 48 to 64
Status: On-Hold — Priority: Medium
Increase number of data nodes to at least, make it possible to easily increase it up to 127 nodes and set it to a maximum of 64 data nodes. This is to prepare for a benchmarking at a site with 128 cores, thus making it suitable to use 64 cores for data nodes and 64 cores for MySQL Servers and benchmark generators. Scaling this parameter also makes it easy to test with even bigger clusters.
The following signals need to have code when received from older versions and when sent to newer versions handling some signal remappings. CM_REGREQ CM_REGCONF CM_REGREF CNTR_MASTERCONF CNTR_MASTERREQ FAIL_REP NODE_FAILREP MASTER_GCPCONF STOP_REQ PREP_FAILREQ PREP_FAILREF START_LCP_REQ CNTR_START_CONF All of those signals require remappings since they contain a bit mask with all data nodes in the cluster. Most of the signals actually only contain this bitmask as the last part of the signal and in these cases it is only necessary to clear the bits when receiving them from older versions. It isn't necessary to do any handling at all when they are sent to older versions since these versions will anyways only copy the first part of the bitmask and will not care about the overflow bits. There are 2 signals that contain multiple bitmasks and these needs some remapping both when received from older versions and when sent to older versions. Then one has to handle the Sysfile in DIH. This currently sends its data in a fixed format, so here one needs to change it to a dynamic format in the signal while maintaining the fixed format internally. Finally if one wants to extend number of data nodes beyond 127 then it is necessary to make READ_NODESCONF a long signal. It is not required to do any upgrade code for this since it is a local signal. Special care needs to be taken with regard to CM_REGREQ and CM_REGCONF are the first signals sent, even before the NodeState has been set where version number is kept. However both of these signals carry the version number in the signal so this isn't really an issue. A simple way of checking which version sent the signal in those cases is to simply check the signal length. The signals CNTR_MASTER* were removed already in version 4.1 and so all references to these signals can be removed as a cleanup
Copyright (c) 2000, 2018, Oracle Corporation and/or its affiliates. All rights reserved.