Below is the list of changes that have just been committed into a local
mysqldoc repository of jon. When jon does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2831 05/04/07 17:22:03 jon@stripped +1 -0
New Cluster chapter section 'Cluster in 5.0/5.1',
based on Mikael's Cluster News of 2005-04-06.
Docs/manual.texi
1.2668 05/04/07 17:21:58 jon@stripped +140 -8
New Cluster chapter section 'Cluster in 5.0/5.1',
based on Mikael's Cluster News of 2005-04-06.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: jon
# Host: gigan.site
# Root: /home/jon/bk/mysqldoc
--- 1.2667/Docs/manual.texi 2005-04-07 16:18:26 +10:00
+++ 1.2668/Docs/manual.texi 2005-04-07 17:21:58 +10:00
@@ -71238,6 +71238,7 @@
* MySQL Cluster Management:: Management of MySQL Cluster
* MySQL Cluster Interconnects:: Using High-Speed Interconnects with MySQL Cluster
* MySQL Cluster Limitations in 4.1:: Cluster Limitations in MySQL 4.1
+* MySQL Cluster in 5.0 and 5.1:: New Cluster Features for MySQL 5.0 and 5.1
* MySQL Cluster FAQ:: MySQL Cluster FAQ
* MySQL Cluster Glossary:: MySQL Cluster Glossary
@end menu
@@ -75635,16 +75636,17 @@
tested MySQL Cluster so far only with SCI sockets. We also include documentation
above on how to set up SCI sockets using ordinary TCP/IP for MySQL Cluster.
-@node MySQL Cluster Limitations in 4.1, MySQL Cluster FAQ, MySQL Cluster Interconnects, NDBCluster
+@node MySQL Cluster Limitations in 4.1, MySQL Cluster in 5.0 and 5.1, MySQL Cluster Interconnects, NDBCluster
@section Cluster Limitations in MySQL 4.1
In this section, we provide a listing of known limitations in MySQL
-Cluster release 4.1 when compared to features available when using the MyISAM
-and InnoDB storage engines. Currently there are no plans to address these in
-coming releases of 4.1; howver, we will supply fixes for these issues in
-MySQL 5.0 and subsequent releases. If you check the Cluster category in the
-MySQL bugs database at @uref{http://bugs.mysql.com}, you can find known bugs
-which (if marked 4.1) we intend to correct in upcoming releases of MySQL 4.1.
+Cluster releases in the 4.1.x series when compared to features available when
+using the MyISAM and InnoDB storage engines. Currently there are no plans to
+address these in coming releases of 4.1; howver, we will attempt to supply fixes
+for these issues in MySQL 5.0 and subsequent releases. If you check the Cluster
+category in the MySQL bugs database at @uref{http://bugs.mysql.com}, you can
+find known bugs which (if marked 4.1) we intend to correct in upcoming releases
+of MySQL 4.1.
@itemize @bullet
@@ -75785,11 +75787,141 @@
encounter to the MySQL bugs database at http://bugs.mysql.com/. If we do not
plan to fix the problem in MySQL 4.1, we will add it to the list above.
+@c *** BEGIN CLUSTER IN 5.0/5.1 ***
+
+@node MySQL Cluster in 5.0 and 5.1, MySQL Cluster FAQ, MySQL Cluster Limitations in 4.1, NDBCluster
+@section MySQL Cluster in 5.0 and 5.1
+
+@c Author: Jon Stephens
+@c Based on Mikael Ronström's "Cluster News" announcement of 2005-04-06
+
+@tindex MySQL Cluster in MySQL 5.0 and 5.1
+@tindex Future development of MySQL CLuster
+@tindex New features in MySQL Cluster
+
+In this section, we discuss changes in the implementation of MySQL Cluster in
+MySQL 5.0 as compared to MySQL 4.1. We will also discuss our roadmap for further
+improvements to MySQL Cluster as currently planned for MySQL 5.1.
+
+In the past we have recommended that users of MySQL Cluster not use version 5.0
+of MySQL since MySQL Cluster in the 5.0.x series wasn't yet fully tested. With
+the release of MySQL 5.0.3-beta we have a release of MySQL 5.0 with clustering
+funcitonality comparable to that of MySQL 4.1. MySQL 4.1 is still recommended
+for production use at this time; however, MySQL 5.0 is of high quality as well,
+and we encourage you to begin testing with Cluster in MySQL 5.0 if you think
+that you are interested in using it once it enters production later in 2005.
+There are relatively few changes between the NDB Cluster storage engine
+implementations in MySQL 4.1 and in 5.0, so the upgrade path should be
+relatively quick and painless.
+
+As of MySQL 5.0.3-beta, nearly all significantly new features being developed
+for MySQL Cluster are going into the MySQL 5.1 tree. We also provide some hints
+about what Cluster in MySQL 5.1 is likely include later in this section, under
+the heading @strong{MySQL 5.1 Development Roadmap for MySQL Cluster}.
+
+@subsection MySQL Cluster Changes in MySQL 5.0
+
+MySQL 5.0.3-beta contains a number of new features that are likely to be of
+interest:
+
+@itemize @bullet
+
+@item
+@strong{Push-Down Conditions}: A query such as
+
+@example
+SELECT * FROM t1 WHERE non_indexed_attribute = 1;
+@end example
+
+will use a full table scan and the condition will be evaluated in the cluster's
+data nodes. Thus it is not necessary to send the records across the network for
+evaluation. (That is, function transport is used, rather than data transport.)
+For this type of query you should see a speed up factor of 5-10. Please note
+that this feature is currently disabled by default (pending more thorough
+testing), but it should work in most cases. This feature can be enabled through
+the use of the command @code{SET engine-condition-pushdown=On;} command.
+Alternatively, you can run @command{mysqld} with the this feature enabled by
+starting the MySQL server with the new @code{--engine-condition-pushdown} option
+flag.
+
+You can use @code{EXPLAIN} to determine when push-down conditions are being used.
+
+A major benefit of this change is that queries are now executed in parallel.
+This means that queries against non-indexed columns can run as much as 5 to 10
+times, @emph{times the number of storage nodes}, faster than previously, since
+multiple CPUs can work on the query in parallel.
+
+@item
+@strong{Decreased @code{IndexMemory} Usage}: In MySQL 5.0, each record consumes
+approximately 25 bytes of index memory, and every unique index uses 25 bytes per
+record of index memory (in addition to some data memory since these are stored
+in a separate table). This is because there is no storage of the primary key in
+the index memory anymore.
+
+@item
+@strong{Query Cache Enabled for MySQL Cluster}: See @ref{Query Cache} for
+information on configuring ans using the query cache.
+
+@item
+@strong{New Optimisations}: One optimisation that merits particular attention
+is that a batched read interface is now used in some queries. For example,
+consider the following query:
+
+@example
+SELECT * FROM t1 WHERE @var{primary_key} IN (1,2,3,4,5,6,7,8,9,10);
+@end example
+
+This query will be executed 2 to 3 times more quickly than in previous MySQL
+Cluster versions due to the fact that all 10 key lookups are sent in a single
+batch rather than one at a time.
+
+@end itemize
+
+@subsection MySQL 5.1 Development Roadmap for MySQL Cluster
+
+What is said here is a status report based on recent commits to the MySQL 5.1
+source tree. It should be noted all 5.1 development is subject to change.
+
+There are currently 4 major new features being developed for MySQL 5.1:
+
+@itemize @bullet
+
+@item
+@strong{Integration of MySQL Cluster into MySQL Replication}: This will make it
+possible to update from any MySQL Server in the cluster and still have the MySQL
+Replication handled by one of the MySQL Servers in the cluster and the
+installation on the slave side consistent.
+
+@item
+@strong{Support for disk-based records}: Records on disk will be supported.
+Indexed fields including the primary key hash index must still be stored in RAM
+but all other fields can be on disk.
+
+@item
+@strong{Variable sized records}: A column defined as @code{VARCHAR(255)}
+currently uses 260 bytes of storage independent of what is stored in any
+particular record. In MySQL 5.1 Cluster tables only the portion of the field
+actually taken up by the record will be stored. This will make possible a
+reduction in space requirements for such columns by a factor of 5 in many cases.
+
+@item
+@strong{User-defined Partitioning}: Users will be able to define partitions
+based on the fields part of the primary key. The MySQL Server will be able to
+discover whether it is possible to prune away some of the partitions from the
+@code{WHERE} clause. Partitioning based on @code{KEY}, @code{HASH},
+@code{RANGE}, and @code{LIST} handlers will be possible, as well as
+subpartitioning. This feature should also be available for many other handlers.
+
+@end itemize
+
+@c *** END CLUSTER IN 5.0/5.1 ***
+
+
@c *** *** *** *** *** *** *** *** *** ***
@c *** *** *** BEGIN CLUSTER FAQ *** *** ***
@c *** *** *** *** *** *** *** *** *** ***
-@node MySQL Cluster FAQ, MySQL Cluster Glossary, MySQL Cluster Limitations in 4.1, NDBCluster
+@node MySQL Cluster FAQ, MySQL Cluster Glossary, MySQL Cluster in 5.0 and 5.1, NDBCluster
@section MySQL Cluster FAQ
@c Cluster FAQ, version 1.0 (2005-01-29)
| Thread |
|---|
| • bk commit - mysqldoc tree (jon:1.2831) | jon | 7 Apr |
