MySQL Cluster Development History
1521
should definitely reside behind your firewall and not in your network's De-Militarized Zone (
DMZ
) or
elsewhere.
See
Section 17.5.10.1, “MySQL Cluster Security and Networking Issues”
, for more information.
• Efficiency.
Setting up a MySQL Cluster on a private or protected network enables the cluster to
make exclusive use of bandwidth between cluster hosts. Using a separate switch for your MySQL
Cluster not only helps protect against unauthorized access to cluster data, it also ensures that
MySQL Cluster nodes are shielded from interference caused by transmissions between other
computers on the network. For enhanced reliability, you can use dual switches and dual cards
to remove the network as a single point of failure; many device drivers support failover for such
communication links.
Network communication and latency.
MySQL Cluster requires communication between data
nodes and API nodes (including SQL nodes), as well as between data nodes and other data nodes,
to execute queries and updates. Communication latency between these processes can directly affect
the observed performance and latency of user queries. In addition, to maintain consistency and
service despite the silent failure of nodes, MySQL Cluster uses heartbeating and timeout mechanisms
which treat an extended loss of communication from a node as node failure. This can lead to reduced
redundancy. Recall that, to maintain data consistency, a MySQL Cluster shuts down when the
last node in a node group fails. Thus, to avoid increasing the risk of a forced shutdown, breaks in
communication between nodes should be avoided wherever possible.
The failure of a data or API node results in the abort of all uncommitted transactions involving the
failed node. Data node recovery requires synchronization of the failed notde's data from a surviving
data node, and re-establishment of disk-based redo and checkpoint logs, before the data node
returns to service. This recovery can take some time, during which the Cluster operates with reduced
redundancy.
Heartbeating relies on timely generation of heartbeat signals by all nodes. This may not be possible
if the node is overloaded, has insufficient machine CPU due to sharing with other programs, or is
experiencing delays due to swapping. If heartbeat generation is sufficiently delayed, other nodes treat
the node that is slow to respond as failed.
This treatment of a slow node as a failed one may or may not be desireable in some circumstances,
depending on the impact of the node's slowed operation on the rest of the cluster. When setting timeout
values such as
HeartbeatIntervalDbDb
[1572]
and
HeartbeatIntervalDbApi
[1573]
for
MySQL Cluster, care must be taken care to achieve quick detection, failover, and return to service,
while avoiding potentially expensive false positives.
Where communication latencies between data nodes are expected to be higher than would be
expected in a LAN environment (on the order of 100 µs), timeout parameters must be increased to
ensure that any allowed periods of latency periods are well within configured timeouts. Increasing
timeouts in this way has a corresponding effect on the worst-case time to detect failure and therefore
time to service recovery.
LAN environments can typically be configured with stable low latency, and such that they can provide
redundancy with fast failover. Individual link failures can be recovered from with minimal and controlled
latency visible at the TCP level (where MySQL Cluster normally operates). WAN environments may
offer a range of latencies, as well as redundancy with slower failover times. Individual link failures may
require route changes to propagate before end-to-end connectivity is restored. At the TCP level this
can appear as large latencies on individual channels. The worst-case observed TCP latency in these
scenarios is related to the worst-case time for the IP layer to reroute around the failures.
SCI support.
It is also possible to use the high-speed Scalable Coherent Interface (SCI) with
MySQL Cluster, but this is not a requirement. See
Section 17.3.5, “Using High-Speed Interconnects
with MySQL Cluster”
, for more about this protocol and its use with MySQL Cluster.
17.1.4. MySQL Cluster Development History
Содержание 5.0
Страница 1: ...MySQL 5 0 Reference Manual ...
Страница 18: ...xviii ...
Страница 60: ...40 ...
Страница 396: ...376 ...
Страница 578: ...558 ...
Страница 636: ...616 ...
Страница 844: ...824 ...
Страница 1234: ...1214 ...
Страница 1426: ...MySQL Proxy Scripting 1406 The following diagram shows an overview of the classes exposed by MySQL Proxy ...
Страница 1427: ...MySQL Proxy Scripting 1407 ...
Страница 1734: ...1714 ...
Страница 1752: ...1732 ...
Страница 1783: ...Configuring Connector ODBC 1763 ...
Страница 1793: ...Connector ODBC Examples 1773 ...
Страница 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Страница 1842: ...Connector Net Installation 1822 5 Once the installation has been completed click Finish to exit the installer ...
Страница 1864: ...Connector Net Visual Studio Integration 1844 Figure 20 24 Debug Stepping Figure 20 25 Function Stepping 1 of 2 ...
Страница 2850: ...2830 ...
Страница 2854: ...2834 ...
Страница 2928: ...2908 ...
Страница 3000: ...2980 ...
Страница 3122: ...3102 ...
Страница 3126: ...3106 ...
Страница 3174: ...3154 ...
Страница 3232: ...3212 ...