Beginning with MySQL 4.1.9-max, MySQL Cluster attempts to use
the shared memory transporter and configure it automatically
where possible. (In previous versions of MySQL Cluster, shared
memory segments functioned only when the -max
binary was built using --with-ndb-shm
.)
[shm]
sections in the
config.ini
file explicitly define
shared-memory connections between nodes in the cluster. When
explicitly defining shared memory as the connection method, it
is necessary to define at least NodeId1
,
NodeId2
and ShmKey
. All
other parameters have default values that should work well in
most cases.
SHM functionality is considered experimental only. It is not officially supported in any current MySQL Cluster release, and testing results indicate that SHM performance is not appreciably greater than when using TCP/IP for the transporter.
For these reasons, you must determine for yourself or by using our free resources (forums, mailing lists) whether SHM can be made to work correctly in your specific case.
To identify a connection between two nodes it is necessary
to provide node identifiers for each of them, as
NodeId1
and NodeId2
.
Version Introduced | 4.1.3 | |
Restart Type | node | |
Permitted Values (>= 4.1.3) | ||
Type | numeric |
|
Default |
|
|
Range | 0-4G |
When setting up shared memory segments, a node ID, expressed as an integer, is used to identify uniquely the shared memory segment to use for the communication. There is no default value.
Version Introduced | 4.1.3 | |
Restart Type | node | |
Permitted Values (>= 4.1.3) | ||
Type | numeric |
|
Default | 1M |
|
Range | 64K-4G |
Each SHM connection has a shared memory segment where
messages between nodes are placed by the sender and read by
the reader. The size of this segment is defined by
ShmSize
. The default value is 1MB.
Version Introduced | 4.1.3 | |
Restart Type | node | |
Permitted Values (>= 4.1.3) | ||
Type | boolean |
|
Default | false |
|
Range | - |
To retrace the path of a distributed message, it is
necessary to provide each message with a unique identifier.
Setting this parameter to Y
causes these
message IDs to be transported over the network as well. This
feature is disabled by default in production builds, and
enabled in -debug
builds.
Version Introduced | 4.1.3 | |
Restart Type | node | |
Permitted Values | ||
Type | boolean |
|
Default | true |
|
Range | - |
This parameter is a boolean
(Y
/N
) parameter which
is disabled by default. When it is enabled, checksums for
all messages are calculated before being placed in the send
buffer.
This feature prevents messages from being corrupted while waiting in the send buffer. It also serves as a check against data being corrupted during transport.
Version Introduced | 4.1.3 | |
Restart Type | node | |
Permitted Values (>= 4.1.3) | ||
Type | numeric |
|
Default |
|
|
Range | 0-4G |
When using the shared memory transporter, a process sends an operating system signal to the other process when there is new data available in the shared memory. Should that signal conflict with with an existing signal, this parameter can be used to change it. This is a possibility when using SHM due to the fact that different operating systems use different signal numbers.
The default value of SigNum
is 0;
therefore, it must be set to avoid errors in the cluster log
when using the shared memory transporter. Typically, this
parameter is set to 10 in the [shm
default]
section of the
config.ini
file.
User Comments
Add your own comment.