From: jon Date: April 24 2007 2:31am Subject: svn commit - mysqldoc@docsrva: r6100 - trunk/refman-5.1 List-Archive: http://lists.mysql.com/commits/25214 Message-Id: <200704240231.l3O2VoV4026494@docsrva.mysql.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Author: jstephens Date: 2007-04-24 04:31:48 +0200 (Tue, 24 Apr 2007) New Revision: 6100 Log: Reformat. Modified: trunk/refman-5.1/mysql-cluster.xml trunk/refman-5.1/news-5.1.xml Modified: trunk/refman-5.1/mysql-cluster.xml =================================================================== --- trunk/refman-5.1/mysql-cluster.xml 2007-04-24 02:30:24 UTC (rev 6099) +++ trunk/refman-5.1/mysql-cluster.xml 2007-04-24 02:31:48 UTC (rev 6100) Changed blocks: 16, Lines Added: 115, Lines Deleted: 90; 14175 bytes @@ -8820,7 +8820,7 @@ changes in the cluster system tables. - + Online upgrades from MySQL 5.1.17 and earlier to 5.1.18 and @@ -8829,8 +8829,9 @@ mysql.ndb_apply_status table. However, it should not be necessary to shut down the cluster entirely, if you follow this modified rolling restart procedure: - + + Stop the management server, update the @@ -8839,17 +8840,17 @@ step for each management server in turn. - + For each data node in turn: Stop the data node, replace the ndbd binary with the new version, then restart the data node. It is not necessary to use --initial when - restarting any of the data nodes. + restarting any of the data nodes. - + Stop all SQL nodes. Replace the @@ -8863,14 +8864,15 @@ mysql.ndb_apply_status uses the NDB storage engine and is thus shared between all SQL nodes — there may be - conflicts between MySQL servers using the old and - new versions of the table. + conflicts between MySQL servers using the old and new + versions of the table. + - + You can find more information about the changes to - ndb_apply_status in + ndb_apply_status in . @@ -13451,7 +13453,7 @@ message displayed upon completion of a backup. (See .) - + adds (or restores) epoch information to the cluster replication status table. This is useful for @@ -13460,7 +13462,7 @@ mysql.ndb_apply_status having 0 in the id column is updated if it already exists; such a row is inserted if it - does not already exist. (See + does not already exist. (See .) @@ -13583,7 +13585,7 @@ Do not ignore system table during restore — EXPERIMENTAL; not for production - use + use FALSE @@ -17229,7 +17231,7 @@ Circular replication: - + Prior to MySQL 5.1.18, circular replication was not supported with MySQL Cluster replication, due to the fact @@ -17238,7 +17240,7 @@ used as master and not with the server ID of the originating server. - + Beginning with MySQL 5.1.18, this limitation is lifted, as discussed in the next few paragraphs, in which we consider @@ -17248,19 +17250,34 @@ master for Cluster 3, and Cluster 3 acts as the master for Cluster 1. Each cluster has two SQL nodes, with SQL nodes A and B belonging to Cluster 1, SQL nodes C and D belonging to - Cluster 2, and SQL nodes E and F belonging to Cluster 3. + Cluster 2, and SQL nodes E and F belonging to Cluster 3. - + Circular replication using these clusters is supported as - long as: - - the SQL nodes on all masters and slaves are the - sameAll SQL nodes acting - as replication masters and slaves are started using the - option - This type of circular replication setup is shown in the following diagram: - + long as: + + + + + + the SQL nodes on all masters and slaves are the same + + + + + + All SQL nodes acting as replication masters and slaves + are started using the + option + + + + + + This type of circular replication setup is shown in the + following diagram: + @@ -17270,41 +17287,42 @@ which all master SQL nodes are also slaves. - + In this scenario, SQL node A in Cluster 1 replicates to SQL node C in Cluster 2; SQL node C replicates to SQL node E in Cluster 3; SQL node E replicates to SQL node A. In other words, the replication line (indicated by the red arrows in the diagram) directly connects all SQL nodes used as - replication masters and slaves. + replication masters and slaves. - + - It should also be possible to set up circular replication in which - not all master SQL nodes are also slaves, as shown here: - + It should also be possible to set up circular replication in + which not all master SQL nodes are also slaves, as shown + here: + Cluster circular replication scheme in - which all master SQL nodes are not also necessarily slaves. + which all master SQL nodes are not also necessarily + slaves. - - + In this case, different SQL nodes in each cluster are used as replication masters and slaves. However, you must not start any of the SQL nodes using - (see the + (see the description of this option for more information). This type of circular replication scheme for MySQL Cluster, in which the line of replication (again indicated by the red arrows in the diagram) is discontinuous, should be possible, but it should - be noted that it has not yet been thoroughly tested and - must therefore still be considered experimental. + be noted that it has not yet been thoroughly tested and must + therefore still be considered experimental. @@ -17374,25 +17392,25 @@ cluster_replication database (obsolete) - + binlog_index table (obsolete) - + - + ndb_binlog_index table (MySQL Cluster replication) - + - + cluster.binlog_index table (obsolete) - + - + mysql.ndb_binlog_index table - + @@ -17483,7 +17501,7 @@ ndb_apply_status can use the NDB Cluster storage engine, as shown here: - + CREATE TABLE `ndb_apply_status` ( `server_id` INT(10) UNSIGNED NOT NULL, @@ -17494,16 +17512,16 @@ PRIMARY KEY (`server_id`) USING HASH ) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1; - + The log_name, start_pos, and end_pos columns were added in MySQL 5.1.18. - + - If you are using MySQL Cluster replication, see + If you are using MySQL Cluster replication, see before upgrading to MySQL 5.1.18 or later from an earlier version. @@ -18446,8 +18464,8 @@ example is required in order that the epoch is written to the slave mysql.ndb_apply_status. Without this information, the slave will not be able to - synchronize properly with the master. (See - .) + synchronize properly with the master. (See + .) @@ -21258,48 +21276,55 @@ MySQL Cluster limitations Disk Data tables + - Issues relating to Disk Data tables: - - - - - Disk data objects are subject to the following maximums: - - - - - Maxmimum number of tablespaces: 2^32 (4294967296) - - - - - - Maximum number of data files per tablespace: - 2^16 (65535) - - - - - - Maxmimum data file size: 2^47 (128GB) - - - - - - - - - - Use of Disk Data tables is not supported when running the - cluster in diskless mode. Beginning with MySQL 5.1.12, it - is disallowed altogether. (Bug #20008) - - - + Issues relating to Disk Data + tables: + + + + + + Disk data objects are subject to the following + maximums: + + + + + + Maxmimum number of tablespaces: 2^32 + (4294967296) + + + + + + Maximum number of data files per tablespace: + 2^16 (65535) + + + + + + Maxmimum data file size: 2^47 (128GB) + + + + + + + + + + Use of Disk Data tables is not supported when + running the cluster in diskless mode. Beginning with + MySQL 5.1.12, it is disallowed altogether. (Bug + #20008) + + + + - Modified: trunk/refman-5.1/news-5.1.xml =================================================================== --- trunk/refman-5.1/news-5.1.xml 2007-04-24 02:30:24 UTC (rev 6099) +++ trunk/refman-5.1/news-5.1.xml 2007-04-24 02:31:48 UTC (rev 6100) Changed blocks: 1, Lines Added: 4, Lines Deleted: 5; 882 bytes @@ -156,14 +156,13 @@ . - + - NDB Cluster (Replication): Some - circular replication setups are now supported for MySQL - Cluster. See + NDB Cluster (Replication): Some circular + replication setups are now supported for MySQL Cluster. See , for - detailed information. (Bug #25688) + detailed information. (Bug #25688)