Systems for MySQLThe world's most popular open source database
- Documentation Library
- Table of Contents
- MySQL 6.0 Reference Manual
- MySQL 5.1 Reference Manual
- MySQL 5.0 Reference Manual
- MySQL 3.23/4.0/4.1 Manual
- Table of Contents
- 16 MySQL Cluster
- 16.1 MySQL Cluster Overview
- 16.2 Simple Multi-Computer How-To
- 16.3 MySQL Cluster Configuration
- 16.4 MySQL Cluster Options and Variables
- 16.5 Upgrading and Downgrading MySQL Cluster
- 16.6 Process Management in MySQL Cluster
- 16.7 Management of MySQL Cluster
- 16.8 MySQL Cluster Security Issues
- 16.9 On-line Backup of MySQL Cluster
- 16.10 MySQL Cluster Utility Programs
- 16.11 Using High-Speed Interconnects with MySQL Cluster
- 16.12 Known Limitations of MySQL Cluster
- 16.13 MySQL Cluster Development Roadmap
- 16.14 MySQL Cluster Glossary
[+/-]
Even before design of NDBCLUSTER began in 1996,
it was evident that one of the major problems to be encountered in
building parallel databases would be communication between the nodes
in the network. For this reason, NDBCLUSTER was
designed from the very beginning to allow for the use of a number of
different data transport mechanisms. In this Manual, we use the term
transporter for these.
The MySQL Cluster codebase includes support for four different transporters:
TCP/IP using 100 Mbps or gigabit Ethernet, as discussed in Section 16.3.4.7, “Cluster TCP/IP Connections”.
Direct (machine-to-machine) TCP/IP; although this transporter uses the same TCP/IP protocol as mentioned in the previous item, it requires setting up the hardware differently and is configured differently as well. For this reason, it is considered a separate transport mechanism for MySQL Cluster. See Section 16.3.4.8, “TCP/IP Connections Using Direct Connections”, for details.
Shared memory (SHM). For more information about SHM, see Section 16.3.4.9, “Shared-Memory Connections”.
Scalable Coherent Interface (SCI), as described in the next section of this chapter, Section 16.3.4.10, “SCI Transport Connections”.
Most users today employ TCP/IP over Ethernet because it is ubiquitous. TCP/IP is also by far the best-tested transporter for use with MySQL Cluster.
We are working to make sure that communication with the ndbd process is made in “chunks” that are as large as possible because this benefits all types of data transmission.
For users who desire it, it is also possible to use cluster interconnects to enhance performance even further. There are two ways to achieve this: Either a custom transporter can be designed to handle this case, or you can use socket implementations that bypass the TCP/IP stack to one extent or another. We have experimented with both of these techniques using the SCI (Scalable Coherent Interface) technology developed by Dolphin.
User Comments
Add your own comment.