| List: | Commits | « Previous MessageNext Message » | |
| From: | jon | Date: | March 29 2006 7:59am |
| Subject: | svn commit - mysqldoc@docsrva: r1696 - in trunk: refman-5.0 refman-5.1 refman-common | ||
| View as plain text | |||
Author: jstephens Date: 2006-03-29 07:59:03 +0200 (Wed, 29 Mar 2006) New Revision: 1696 Log: General updates for Cluster docs reflecting changes in varsize implementaton and other new features. (Hi, Vinay!) Renaming "5.1 Cluster Roadmap" to "Changes in MySQL 5.1 Cluster" and updating content. (Adding new title entity.) Cut 5.1 Cluster Roadmap section from 5.0 Manual - changed xref to ulink pointing to 5.1 Cluster chapter online. Updating 5.1 renamed-nodes file to reflect organisaitonal changes. Modified: trunk/refman-5.0/ndbcluster.xml trunk/refman-5.1/ndbcluster.xml trunk/refman-5.1/renamed-nodes.txt trunk/refman-common/titles.en.ent Modified: trunk/refman-5.0/ndbcluster.xml =================================================================== --- trunk/refman-5.0/ndbcluster.xml 2006-03-29 02:29:39 UTC (rev 1695) +++ trunk/refman-5.0/ndbcluster.xml 2006-03-29 05:59:03 UTC (rev 1696) @@ -9672,9 +9672,10 @@ <para> 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 to include later in this - section (see <xref linkend="mysql-5-1-cluster-roadmap"/>). + are going into the MySQL 5.1 and 5.2 trees. For information on + changes in the Cluster implementations in MySQL versions 5.1 and + later, see + <ulink url="http://dev.mysql.com/doc/refman/5.1/en/ndbcluster.html"/>. </para> <remark role="todo"> Modified: trunk/refman-5.1/ndbcluster.xml =================================================================== --- trunk/refman-5.1/ndbcluster.xml 2006-03-29 02:29:39 UTC (rev 1695) +++ trunk/refman-5.1/ndbcluster.xml 2006-03-29 05:59:03 UTC (rev 1696) @@ -3012,16 +3012,13 @@ <para> The memory allocated by <literal>DataMemory</literal> is - used to store both the actual records and indexes. Each - record is currently of fixed size. (Even - <literal>VARCHAR</literal> columns are stored as - fixed-width columns.) There is a 16-byte overhead on each - record; an additional amount for each record is incurred - because it is stored in a 32KB page with 128 byte page - overhead (see below). There is also a small amount wasted - per page due to the fact that each record is stored in - only one page. The maximum record size is currently 8052 - bytes. + used to store both the actual records and indexes. There + is a 16-byte overhead on each record; an additional amount + for each record is incurred because it is stored in a 32KB + page with 128 byte page overhead (see below). There is + also a small amount wasted per page due to the fact that + each record is stored in only one page. The maximum record + size is currently 8052 bytes. </para> <para> @@ -3674,11 +3671,11 @@ </para> <para> - A REDO log record is not removed until three local - checkpoints have been completed since that log record was - inserted. Checkpointing frequency is determined by its own - set of configuration parameters discussed elsewhere in - this chapter. + A <literal>REDO</literal> log record is not removed until + three local checkpoints have been completed since that log + record was inserted. Checkpointing frequency is determined + by its own set of configuration parameters discussed + elsewhere in this chapter. </para> <remark role="todo"> @@ -10254,6 +10251,7 @@ tables in MySQL 5.1, variable-length columns take up a fixed amount of space. For each row, this is equal to the space required to store the largest possible value for that column. + See <xref linkend="mysql-cluster-disk-data"/>. </para> </listitem> @@ -11079,19 +11077,12 @@ given in <xref linkend="bug-reports"/>. If we do not plan to fix the problem in MySQL ¤t-series;, we will add it to the list. </para> - - <remark role="todo"> - [js] Commented out the following paragraph until the 5.1 list is - ready. - </remark> - -<!-- + <para> (<emphasis role="bold">Note</emphasis>: See the end of this section for a list of issues in MySQL &previous-series; Cluster that have been resolved in the current version.) </para> ---> <itemizedlist> @@ -11318,21 +11309,6 @@ <listitem> <para> - All Cluster table rows are of fixed length. This means - (for example) that if a table has one or more - <literal>VARCHAR</literal> fields containing only - relatively small values, more memory and disk space is - required when using the <literal>NDB</literal> storage - engine than would be the case for the same table and data - using the <literal>MyISAM</literal> engine. (In other - words, in the case of a <literal>VARCHAR</literal> column, - the column requires the same amount of storage as a - <literal>CHAR</literal> column of the same size.) - </para> - </listitem> - - <listitem> - <para> The maximum number of tables in a Cluster database is limited to 1792. </para> @@ -11482,22 +11458,7 @@ </listitem> <listitem> - <remark role="todo"> - [js] Cut or change this item when cluster replication is - enabled. - </remark> - <para> - MySQL replication will not work correctly if updates are - done on multiple MySQL servers. However, if the database - partitioning scheme is done at the application level and - no transactions take place across these partitions, - replication can be made to work. - </para> - </listitem> - - <listitem> - <para> Autodiscovery of databases is not supported for multiple MySQL servers accessing the same MySQL Cluster. However, autodiscovery of tables is supported in such cases. What @@ -11631,6 +11592,61 @@ </itemizedlist> </listitem> + + <listitem> + + <para> + <emphasis role="bold">MySQL Cluster issues from previous + versions that have been resolved in MySQL 5.1</emphasis>: + </para> + + <itemizedlist> + + <listitem> + <para> + The <literal>NDB Cluster</literal> storage engine now + supports variable-length column types for in-memory tables. + </para> + + <para> + Previously, this meant that — for example — + any Cluster table having one or more + <literal>VARCHAR</literal> fields which contained only + relatively small values, much more memory and disk space + were required when using the <literal>NDBCluster</literal> + storage engine than would have been the case for the same + table and data using the <literal>MyISAM</literal> engine. + In other words, in the case of a + <literal>VARCHAR</literal> column, such a column required + the same amount of storage as a <literal>CHAR</literal> + column of the same size. In MySQL 5.1, this is no longer + the case for in-memory tables, where storage requirements + for variable-length column types such as + <literal>VARCHAR</literal> and <literal>BINARY</literal> + are comparable to those for these column types when used + in <literal>MyISAM</literal> tables (see + <xref linkend="storage-requirements"/>). + </para> + + <para> + <emphasis role="bold">Important</emphasis>: For MySQL + Cluster Disk Data tables, the fixed-width limitation + continues to apply. See + <xref linkend="mysql-cluster-disk-data"/>. + </para> + </listitem> + + <listitem> + <para> + It is now possible to use MySQL replication with Cluster + databases. For details, see + <xref linkend="mysql-cluster-replication"/>. + </para> + </listitem> + + </itemizedlist> + + </listitem> </itemizedlist> @@ -11681,173 +11697,49 @@ </para> <para> - There are relatively few changes between the NDB Cluster storage - engine implementations in MySQL &previous-series; and in - ¤t-series;, so the upgrade path should be relatively quick - and painless. + There are a number of significant changes in the implementaiton of + the <literal>NDB Cluster</literal> storage engine in MySQL 5.1 as + compared to that in MySQL 5.0. For an overview of these changes, + see <xref linkend="mysql-5-1-cluster-changes"/> </para> - <para> - 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 to include later in this - section (see <xref linkend="mysql-5-1-cluster-roadmap"/>). - </para> + <section id="mysql-5-1-cluster-changes"> - <remark role="todo"> - Consider removing this section altogether once it has been - verified that all relevant info contained herein is covered in - News and elsewhere. [js] - </remark> + <title>&title-mysql-5-1-cluster-changes;</title> - <section id="mysql-5-0-cluster-changes"> - - <title>&title-mysql-5-0-cluster-changes;</title> - <para> - MySQL Cluster in versions 5.0.3-beta and later contains a number - of new features that are likely to be of interest: + Four major new features for MySQL Cluster have been developed + for MySQL 5.1: </para> - <itemizedlist> - - <listitem> - <para> - <emphasis role="bold">Push-Down Conditions</emphasis>: - Consider the following query: - </para> - -<programlisting> -SELECT * FROM t1 WHERE non_indexed_attribute = 1; -</programlisting> - - <para> - This query 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.) 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 <literal>SET - engine_condition_pushdown = On</literal> statement. - Alternatively, you can run <command>mysqld</command> with - the this feature enabled by starting the MySQL server with - the <option>--engine-condition-pushdown</option> option. - </para> - - <para> - A major benefit of this change is that queries can be - executed in parallel. This means that queries against - non-indexed columns can run faster than previously by a - factor of as much as 5 to 10 times, <emphasis>times the - number of data nodes</emphasis>, because multiple CPUs can - work on the query in parallel. - </para> - - <para> - You can use <literal>EXPLAIN</literal> to determine when - condition pushdown is being used. See - <xref linkend="explain"/>. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Decreased - <literal>IndexMemory</literal> Usage</emphasis>: In MySQL - ¤t-series;, 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 - because these are stored in a separate table). This is - because the primary key is not stored in the index memory - anymore. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Query Cache Enabled for MySQL - Cluster</emphasis>: See <xref linkend="query-cache"/>, for - information on configuring and using the query cache. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">New Optimizations</emphasis>: One - optimization that merits particular attention is that a - batched read interface is now used in some queries. For - example, consider the following query: - </para> - -<programlisting> -SELECT * FROM t1 WHERE <replaceable>primary_key</replaceable> IN (1,2,3,4,5,6,7,8,9,10); -</programlisting> - - <para> - 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. - </para> - </listitem> - - <listitem> - <para> - <emphasis role="bold">Limit On Number of Metadata - Objects</emphasis>: In MySQL 5.1, each Cluster database may - contain a maximum of 20320 metadata objects, including - database tables, system tables, indexes and - <literal>BLOB</literal>s. - </para> - </listitem> - - </itemizedlist> - - </section> - - <section id="mysql-5-1-cluster-roadmap"> - - <title>&title-mysql-5-1-cluster-roadmap;</title> - - <remark role="todo"> - Leave title, ID, and content more or less as they are. As - development progresses, we can add a mysql-cluster-5-2-roadmap - section (etc.) and drop sections as versions are released? [js] - </remark> - - <para> - 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. - </para> - - <para> - There are currently 4 major new features being developed for - MySQL 5.1: - </para> - <orderedlist> <listitem> <para> <emphasis role="bold">Integration of MySQL Cluster into - MySQL replication</emphasis>: This will make it possible to + MySQL replication</emphasis>: This makes 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, with the state of the slave side remaining consistent with the cluster acting as the master. </para> + + <para> + See <xref linkend="mysql-cluster-replication"/>. + </para> </listitem> <listitem> <para> <emphasis role="bold">Support for disk-based - records</emphasis>: Records on disk will be supported. + records</emphasis>: Records on disk are now supported. Indexed fields including the primary key hash index must still be stored in RAM but all other fields can be on disk. </para> + + <para> + See <xref linkend="mysql-cluster-disk-data"/>. + </para> </listitem> <listitem> @@ -11866,21 +11758,34 @@ <listitem> <para> <emphasis role="bold">User-defined partitioning</emphasis>: - Users will be able to define partitions based on columns - that are 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 <literal>WHERE</literal> clause. - Partitioning based on <literal>KEY</literal>, - <literal>HASH</literal>, <literal>RANGE</literal>, and - <literal>LIST</literal> handlers will be possible, as well - as subpartitioning. This feature should also be available - for many other handlers, and not only <literal>NDB - Cluster</literal>. + Users can define partitions based on columns that are part + of the primary key. It is possible to partition tables based + on <literal>KEY</literal>, <literal>HASH</literal>, + <literal>RANGE</literal>, and <literal>LIST</literal>, as is + subpartitioning. This feature is also available for many + other storage engines, and not only <literal>NDB + Cluster</literal>. </para> + + <para> + See <xref linkend="partitioning"/>. + </para> + + <para> + The MySQL Server can also determine whether it is possible + to <quote>prune away</quote> some of the partitions from the + <literal>WHERE</literal> clause. See + <xref linkend="partitioning-pruning"/>. + </para> </listitem> </orderedlist> - + + <remark role="todo"> + [js] Update in view of varsize changes and uncomment again. + </remark> + +<!-- <para> In addition, we are working to increase the 8KB size limit for rows containing columns of types other than @@ -11893,7 +11798,8 @@ limitation so that using more than 8KB in a given row does not result in the remainder of the page being wasted. </para> - +--> + </section> </section> @@ -12767,15 +12673,15 @@ extensions. (See <xref linkend="spatial-extensions"/>.) In addition, there are some differences with regard to indexes when used with <literal>NDB</literal> tables. - <emphasis role="bold">Note</emphasis>: MySQL Cluster tables - (that is, tables created with - <literal>ENGINE=NDBCLUSTER</literal>) have only fixed-width - rows. This means that (for example) each record containing a - <literal>VARCHAR(255)</literal> column will require space for - 255 characters (as required for the character set and + <emphasis role="bold">Note</emphasis>: MySQL Cluster Disk Data + tables (that is, tables created with + <literal>TABLESPACE ... STORAGE DISK + ENGINE=NDBCLUSTER</literal>) have only fixed-width rows. + This means that (for example) each Disk Data table record + containing a <literal>VARCHAR(255)</literal> column requires + space for 255 characters (as required for the character set and collation being used for the table), regardless of the actual - number of characters stored therein. This issue is expected to - be fixed in a future MySQL release series. + number of characters stored therein. </para> <para> Modified: trunk/refman-5.1/renamed-nodes.txt =================================================================== --- trunk/refman-5.1/renamed-nodes.txt 2006-03-29 02:29:39 UTC (rev 1695) +++ trunk/refman-5.1/renamed-nodes.txt 2006-03-29 05:59:03 UTC (rev 1696) @@ -56,6 +56,8 @@ mysql-apis apis mysql-connectors connectors mysql-database-administration database-administration +mysql-cluster-5-0-changes mysql-cluster-5-1-changes +mysql-cluster-5-1-roadmap mysql-cluster-5-1-changes mysql-optimisation optimization nt-start windows-start-service nutshell-ready-for-immediate-use roadmap Modified: trunk/refman-common/titles.en.ent =================================================================== --- trunk/refman-common/titles.en.ent 2006-03-29 02:29:39 UTC (rev 1695) +++ trunk/refman-common/titles.en.ent 2006-03-29 05:59:03 UTC (rev 1696) @@ -848,6 +848,7 @@ <!ENTITY title-mysql-4-0-nutshell "MySQL 4.0 in a Nutshell"> <!ENTITY title-mysql-4-1-nutshell "MySQL 4.1 in a Nutshell"> <!ENTITY title-mysql-5-0-cluster-changes "MySQL Cluster Changes in MySQL 5.0"> +<!ENTITY title-mysql-5-1-cluster-changes "MySQL Cluster Changes in MySQL 5.1"> <!ENTITY title-mysql-5-0-nutshell "What's New in MySQL 5.0"> <!ENTITY title-mysql-5-1-cluster-roadmap "MySQL 5.1 Development Roadmap for MySQL Cluster"> <!ENTITY title-mysql-5-1-nutshell "What's New in MySQL 5.1">
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r1696 - in trunk: refman-5.0 refman-5.1 refman-common | jon | 29 Mar |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.512 sec. using MySQL 5.1.14-beta-log