| List: | Commits | « Previous MessageNext Message » | |
| From: | jon | Date: | August 13 2007 12:46pm |
| Subject: | svn commit - mysqldoc@docsrva: r7442 - in trunk: refman-5.1 refman-5.2 | ||
| View as plain text | |||
Author: jstephens Date: 2007-08-13 12:46:39 +0200 (Mon, 13 Aug 2007) New Revision: 7442 Log: Cluster Replication: 5.1: Fake headings -> <formalpara>s 5.2: Get rid of 5.1 specifics. Harmonise 5.2 version with 5.1.. Modified: trunk/refman-5.1/mysql-cluster.xml trunk/refman-5.2/mysql-cluster.xml Modified: trunk/refman-5.1/mysql-cluster.xml =================================================================== --- trunk/refman-5.1/mysql-cluster.xml 2007-08-13 08:17:05 UTC (rev 7441) +++ trunk/refman-5.1/mysql-cluster.xml 2007-08-13 10:46:39 UTC (rev 7442) Changed blocks: 5, Lines Added: 101, Lines Deleted: 66; 8966 bytes @@ -18883,21 +18883,27 @@ <para> The following are known problems or issues when using - replication with MySQL Cluster in MySQL 5.1: + replication with MySQL Cluster in MySQL ¤t-series;: </para> <itemizedlist> <listitem> - <para> - Prior to MySQL 5.1.18, a MySQL Cluster replication slave - <command>mysqld</command> had no way of detecting that the - connection from the master had been interrupted (due to, for - instance, the master going down or a network failure). For - this reason, it was possible for the slave to become - inconsistent with the master. - </para> + <formalpara> + <title>Loss of master-slave connection</title> + + <para> + Prior to MySQL 5.1.18, a MySQL Cluster replication slave + <command>mysqld</command> had no way of detecting that the + connection from the master had been interrupted (due to, + for instance, the master going down or a network failure). + For this reason, it was possible for the slave to become + inconsistent with the master. + </para> + + </formalpara> + <para> (If high availability is a requirement for the slave server or cluster, then it is still advisable to set up multiple @@ -18936,32 +18942,36 @@ </listitem> <listitem> - <para> - <emphasis role="bold">Multi-byte character sets</emphasis> - </para> + <formalpara> - <para> - There are several known issues with regard to the use of - multi-byte characters sets with MySQL Cluster Replication. - See Bug #27404 (fixed in MySQL 5.1.21), Bug #29562, Bug - #29563, and Bug #29564 for more information. - </para> + <title>Multi-byte character sets</title> + + <para> + There are several known issues with regard to the use of + multi-byte characters sets with MySQL Cluster Replication. + See Bug #27404 (fixed in MySQL 5.1.21), Bug #29562, Bug + #29563, and Bug #29564 for more information. + </para> + + </formalpara> </listitem> <listitem> - <para> - <emphasis role="bold">Circular replication</emphasis>: - </para> + <formalpara> - <para> - Prior to MySQL 5.1.18, circular replication was not - supported with MySQL Cluster replication, due to the fact - that all log events created in a particular MySQL Cluster - were wrongly tagged with the server ID of the MySQL server - used as master and not with the server ID of the originating - server. - </para> + <title>Circular replication</title> + <para> + Prior to MySQL 5.1.18, circular replication was not + supported with MySQL Cluster replication, due to the fact + that all log events created in a particular MySQL Cluster + were wrongly tagged with the server ID of the MySQL server + used as master and not with the server ID of the + originating server. + </para> + + </formalpara> + &mccge-warning-unsupported-begin; <para> @@ -19053,48 +19063,73 @@ </listitem> <listitem> - <para> - The use of data definition statements, such as - <literal>CREATE TABLE</literal>, <literal>DROP - TABLE</literal>, and <literal>ALTER TABLE</literal>, are - recorded in the binary log for only the MySQL server on - which they are issued. - </para> + <formalpara> + + <title>DDL statements</title> + + <para> + The use of data definition statements, such as + <literal>CREATE TABLE</literal>, <literal>DROP + TABLE</literal>, and <literal>ALTER TABLE</literal>, are + recorded in the binary log for only the MySQL server on + which they are issued. + </para> + + </formalpara> </listitem> <listitem> - <para> - In MySQL 5.1.6, only those <literal>NDB</literal> tables - having explicit primary keys could be replicated. This - limitation was lifted in MySQL 5.1.7. - </para> + <formalpara> + + <title>Explicit primary key required</title> + + <para> + In MySQL 5.1.6, only those <literal>NDB</literal> tables + having explicit primary keys could be replicated. This + limitation was lifted in MySQL 5.1.7. + </para> + + </formalpara> </listitem> <listitem> - <para> - Restarting the cluster with the - <option>&ddash;initial</option> option will cause the - sequence of GCI and epoch numbers to start over from - <literal>0</literal>. (This is generally true of MySQL - Cluster and not limited to replication scenarios involving - Cluster.) The MySQL servers involved in replication should - in this case be restarted. After this, you should use the - <literal>RESET MASTER</literal> and <literal>RESET - SLAVE</literal> statements to clear the invalid - <literal>ndb_binlog_index</literal> and - <literal>ndb_apply_status</literal> tables. respectively. - </para> + <formalpara> + + <title>Restarting with <option>--initial</option></title> + + <para> + Restarting the cluster with the + <option>&ddash;initial</option> option will cause the + sequence of GCI and epoch numbers to start over from + <literal>0</literal>. (This is generally true of MySQL + Cluster and not limited to replication scenarios involving + Cluster.) The MySQL servers involved in replication should + in this case be restarted. After this, you should use the + <literal>RESET MASTER</literal> and <literal>RESET + SLAVE</literal> statements to clear the invalid + <literal>ndb_binlog_index</literal> and + <literal>ndb_apply_status</literal> tables. respectively. + </para> + + </formalpara> </listitem> <listitem> - <para> - The use of the <literal>auto_increment_offset</literal> and - <literal>auto_increment_increment</literal> server system - variables is supported beginning with MySQL 5.1.20. - Previously, these produced unpredictable results when used - with <literal>NDB</literal> tables or MySQL Cluster - replication. - </para> + <formalpara> + + <title><literal>auto_increment_offset</literal> and + <literal>auto_increment_increment</literal> variables</title> + + <para> + The use of the <literal>auto_increment_offset</literal> + and <literal>auto_increment_increment</literal> server + system variables is supported beginning with MySQL 5.1.20. + Previously, these produced unpredictable results when used + with <literal>NDB</literal> tables or MySQL Cluster + replication. + </para> + + </formalpara> </listitem> </itemizedlist> @@ -21115,8 +21150,8 @@ Every <literal>CREATE LOGFILE GROUP</literal> and <literal>ALTER LOGFILE GROUP</literal> statement must include an <literal>ENGINE</literal> clause. In MySQL - 5.1, the permitted values for this clause are - <literal>NDB</literal> and + ¤t-series;, the permitted values for this clause + are <literal>NDB</literal> and <literal>NDBCLUSTER</literal>. </para> @@ -21238,8 +21273,8 @@ <literal>ALTER TABLESPACE</literal> statements must contain an <literal>ENGINE</literal> clause; only tables using the same storage engine as the tablespace can be - created in the tablespace. In MySQL 5.1, the only - permitted values for this clause are + created in the tablespace. In MySQL ¤t-series;, + the only permitted values for this clause are <literal>NDB</literal> and <literal>NDBCLUSTER</literal>. </para> Modified: trunk/refman-5.2/mysql-cluster.xml =================================================================== --- trunk/refman-5.2/mysql-cluster.xml 2007-08-13 08:17:05 UTC (rev 7441) +++ trunk/refman-5.2/mysql-cluster.xml 2007-08-13 10:46:39 UTC (rev 7442) Changed blocks: 18, Lines Added: 1250, Lines Deleted: 178; 56274 bytes @@ -684,11 +684,16 @@ <para> &mccge-series; is a branch of MySQL 5.1 using advanced versions of the <literal>NDB</literal> storage engine and - <literal>NDB</literal> API. It is intended for use in the - telcommunications industry, and is available in binary and source - form to commercial customers. Two development trees can also be - accessed via <ulink url="http://mysql.bkbits.net/"/>: + <literal>NDB</literal> API, created as a direct response to + customer needs. It is intended for use in the telcommunications + industry, and is available in binary and source form to commercial + customers. + </para> + <para> + Two development trees can also be accessed via + <ulink url="http://mysql.bkbits.net/"/>: + <itemizedlist> <listitem> @@ -706,6 +711,45 @@ </itemizedlist> </para> + <important> + <para> + This chapter of the MySQL Manual covers both MySQL + ¤t-series; and &mccge-series;. + </para> + + <para> + Information which applies to &mccge-series; releases but not to + mainline ¤t-series; releases is indicated with a warning + such as this one: + </para> + + &mccge-warning-begin; + + <para> + Information which applies to mainline MySQL ¤t-series; + releases but not to &mccge-series; releases is indicated with a + warning such as this one: + </para> + + &mccge-warning-unsupported-begin; + + <para> + (Similar warnings are displayed where appropriate in + <xref linkend="ndb-api"/>.) + </para> + </important> + + <para> + Currently, both the ndb-6.1.<replaceable>x</replaceable> and + ndb-6.2.<replaceable>x</replaceable> series are under active + development, with the ndb-6.1.<replaceable>x</replaceable> series + intended for use by telecommunications customers and + ndb-6.2.<replaceable>x</replaceable> intended for testing + purposes. Differences between the mainline MySQL ¤t-series; + series and &mccge-series; are higlighted in + <xref linkend="mysql-cluster-cge-differences"/>. + </para> + <formalpara> <title>&mccge-series; versioning</title> @@ -718,7 +762,8 @@ string which identifies the mainline MySQL version from which the CGE release was branched and the version of the <literal>NDB</literal> storage engine used. For example, the - first CGE release was <literal>mysql-5.1.14-ndb-6.1.0</literal>. + first CGE release was <literal>mysql-5.1.14-ndb-6.1.0</literal> + (shown as <quote>MySQL 5.1.14-ndb-6.1.0</quote> in this Manual). The version string tells us that this version: <itemizedlist> @@ -739,33 +784,355 @@ </listitem> </itemizedlist> + + A listing of available &mccge-current; releases for both the + ndb-6.1.<replaceable>x</replaceable> and the + ndb-6.1.<replaceable>x</replaceable> series can be found in + <xref linkend="mysql-cluster-cge-releases"/>. </para> </formalpara> - <remark role="note"> - [js] Needs to be updated with each new CGE release. - </remark> + <para> + Additional information about obtaining &mccge-series; binaries can + be found on the MySQL AB web site at + <ulink url="http://www.mysql.com/products/database/clustercge/"/>, + or by contacting <email>sales@stripped</email>. + </para> - <formalpara> + <section id="mysql-cluster-cge-differences"> - <title>&mccge-series; change history</title> + <title>Major Differences Between MySQL ¤t-series; and &mccge-series;</title> <para> - Changelogs for &mccge-series; releases may be found in - <xref linkend="news-5-1-x"/>, and are grouped together according - to the mainline MySQL 5.1 version from which they derive, in the - following sections: + This section lists the most prominent feature differences + between mainline releases of MySQL ¤t-series; and + &mccge-series; releases. + </para> + <note> + <para> + &mccge-series; also fixes many MySQL Cluster bugs before the + fixes appear in MySQL ¤t-series;. The &mccge-series; + changelogs has complete listings of these — see + <xref linkend="mysql-cluster-cge-releases"/>. + </para> + </note> + + <remark role="TODO"> + [js] Add relevant links to items in next 3 lists. + </remark> + + <formalpara> + + <title>ndb-6.1.<replaceable>x</replaceable> branch</title> + + <para> + <itemizedlist> + + <listitem> + <para> + Enhanced backup status reporting, aided in part by the + introduction of a + <literal>BackupReportFrequency</literal> configuration + parameter (MySQL 5.1.14-ndb-6.1.0). + </para> + </listitem> + + <listitem> + <para> + Maxmimum number of all nodes in a cluster increased to + 255 (MySQL 5.1.14-ndb-6.1.1). + </para> + </listitem> + + <listitem> + <para> + Addition of the <literal>NDB</literal> API + <literal>Dictionary::listEvents()</literal> method + (MySQL 5.1.15-ndb-6.1.3). + </para> + </listitem> + + <listitem> + <para> + Ability to disable arbitration, by setting + <literal>ArbitrationRank=0</literal> on all nodes (MySQL + 5.1.15-ndb-6.1.3). + </para> + </listitem> + + <listitem> + <para> + Inclusion of the <command>ndb_redo_log_reader</command> + utility in the default build (MySQL 5.1.15-ndb-6.1.3). + </para> + </listitem> + + <listitem> + <para> + New methods of the + <literal>Ndb_cluster_connection</literal> class, making + it possible to iterate over all existing + <literal>Ndb</literal> objects (MySQL 5.1.15-ndb-6.1.4). + </para> + </listitem> + + <listitem> + <para> + <option>--ndb-wait-connected</option> option for + <command>mysqld</command>, causing + <command>mysqld</command> wait a specified amount of + time to be connected to the cluster before starting to + accept client connections (MySQL 5.1.15-ndb-6.1.4). + </para> + </listitem> + + <listitem> + <para> + Improved data node memory allocation (MySQL + 5.1.15-ndb-6.1.4). + </para> + </listitem> + + <listitem> + <para> + Ability to pipe output of <command>ndb_restore</command> + to CSV file (MySQL 5.1.15-ndb-6.1.5). + </para> + </listitem> + + <listitem> + <para> + A new <literal>FragmentLogFileSize</literal> + configuration parameter makes it possible to set the + size of redo log files (MySQL 5.1.15-ndb-6.1.11). + </para> + </listitem> + + <listitem> + <para> + <literal>MaxAllocate</literal> configuration parameter + makes it possible to set the maximum size of the + allocation unit used for table memory (MySQL + 5.1.15-ndb-6.1.12). + </para> + </listitem> + + <listitem> + <para> + New management client <literal>DUMP</literal> commands + providing help with tracking transactions, scan + operations, and locks (MySQL 5.1.15-ndb-6.1.12). + </para> + </listitem> + + <listitem> + <para> + Improvements in backups of Disk Data tables resulted in + a 10 to 15% increase in backup speed of Disk Data tables + (MySQL 5.1.15-ndb-6.1.13). + </para> + </listitem> + + <listitem> + <para> + Batching of updates on cluster replication slaves, + enabled using the + <option>--slave-allow-batching</option> option for + <command>mysqld</command> (MySQL 5.1.15-ndb-6.1.17). + </para> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + <formalpara> + + <title>ndb-6.2.<replaceable>x</replaceable> branch</title> + + <para> + The following improvements are available in + ndb-6.2.<replaceable>x</replaceable> releases: + + <itemizedlist> + + <listitem> + <para> + Mutliple cluster connections by a single MySQL server + using the <option>--ndb-cluster-connection-pool</option> + startup option for <command>mysqld</command> (MySQL + 5.1.18-ndb-6.2.2). + </para> + </listitem> + + <listitem> + <para> + New management client <literal>DUMP</literal> commands + providing help with tracking transactions, scan + operations, and locks (MySQL 5.1.18-ndb-6.2.2). + </para> + </listitem> + + <listitem> + <para> + The addition of the <literal>NdbRecord</literal> + interface and handler for the <literal>NDB</literal> API + (MySQL 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + Enhanced backup status reporting, aided in part by the + introduction of a + <literal>BackupReportFrequency</literal> configuration + parameter as well as a new management client command + <literal>REPORT BackupStatus</literal> (MySQL + 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + In-progress status reporting by + <command>ndb_restore</command> (MySQL 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + Batching of updates on cluster replication slaves, + enabled using the + <option>--slave-allow-batching</option> option for + <command>mysqld</command> (MySQL 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + Improved memory allocation in the <literal>NDB</literal> + kernel (MySQL 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + Improvements in backups of Disk Data tables resulted in + a 10 to 15% increase in backup speed of Disk Data tables + (MySQL 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + <literal>MaxAllocate</literal> configuration parameter + makes it possible to set the maximum size of the + allocation unit used for table memory (MySQL + 5.1.19-ndb-6.2.3). + </para> + </listitem> + + <listitem> + <para> + The ability to control whether fixed-width or + variable-width storage is used for a given column of an + <literal>NDB</literal> table by means of the + <literal>COLUMN_FORMAT</literal> specifier as part of + the column's definition in a <literal>CREATE + TABLE</literal> or <literal>ALTER TABLE</literal> + statement. In addition, the ability to control whether a + given column of an <literal>NDB</literal> table is + stored in memory or on disk, using the + <literal>STORAGE</literal> specifier as part of the + column's definition in a <literal>CREATE TABLE</literal> + or <literal>ALTER TABLE</literal> statement. (MySQL + 5.1.19-ndb-6.2.5) + </para> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + <formalpara> + + <title>ndb-6.3.<replaceable>x</replaceable> branch</title> + + <para> + The following improvements are available in + ndb-6.3.<replaceable>x</replaceable> releases: + + <itemizedlist> + + <listitem> + <para> + Implementation of conflict resolution for use in + multi-master replication (MySQL 5.1.19-ndb-6.3.0). + </para> + </listitem> + + <listitem> + <para> + The ability to control whether fixed-width or + variable-width storage is used for a given column of an + <literal>NDB</literal> table by means of the + <literal>COLUMN_FORMAT</literal> specifier as part of + the column's definition in a <literal>CREATE + TABLE</literal> or <literal>ALTER TABLE</literal> + statement. In addition, the ability to control whether a + given column of an <literal>NDB</literal> table is + stored in memory or on disk, using the + <literal>STORAGE</literal> specifier as part of the + column's definition in a <literal>CREATE TABLE</literal> + or <literal>ALTER TABLE</literal> statement. (MySQL + 5.1.20-ndb-6.3.2) + </para> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + <para> + More detailed information can be found in the changelogs for + individual &mccge-series; releases; see + <xref linkend="mysql-cluster-cge-releases"/>, for a current + changelog listing. + </para> + + </section> + + <section id="mysql-cluster-cge-releases"> + + <title>&mccge-series; Releases</title> + + <remark role="note"> + [js] Needs to be updated with each new CGE release. + </remark> + + <para> + Changelogs and source code download locations for &mccge-series; + releases may be found in <xref linkend="news-5-1-x"/>; these are + grouped together according to the mainline MySQL 5.1 version + from which they derive, as shown in the list that follows: + <itemizedlist> <listitem> <para> - <xref linkend="news-5-1-14-cge"/>: Includes - <xref linkend="news-5-1-14-ndb-6-1-0"/>. + <xref linkend="news-5-1-14-cge"/>: </para> <para> + Includes <xref linkend="news-5-1-14-ndb-6-1-0"/>. + </para> + + <para> This release includes all feature enhancements and bugfixes made in MySQL 5.1 up to and including the 5.1.14 release. @@ -774,38 +1141,267 @@ <listitem> <para> - <xref linkend="news-5-1-15-cge"/>: Includes - <xref linkend="news-5-1-15-ndb-6-1-1"/>, - <xref linkend="news-5-1-15-ndb-6-1-2"/>, - <xref linkend="news-5-1-15-ndb-6-1-3"/>, - <xref linkend="news-5-1-15-ndb-6-1-4"/>, - <xref linkend="news-5-1-15-ndb-6-1-5"/>, and - <xref linkend="news-5-1-15-ndb-6-1-6"/>. + <xref linkend="news-5-1-15-cge"/>: </para> <para> + Includes these changelogs: + + <itemizedlist> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-1"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-2"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-3"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-4"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-5"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-6"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-7"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-8"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-9"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-10"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-11"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-12"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-13"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-14"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-15"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-16"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-15-ndb-6-1-17"/> + </para> + </listitem> + + </itemizedlist> + </para> + + <para> These releases include all feature enhancements and bugfixes made in MySQL 5.1 up to and including 5.1.15, as - well as those CGE-specific enhancements made in - MySQL-5.1.14-ndb-6.1.0. + well as those enhancements specific to &mccge-series; made + in MySQL-5.1.14-ndb-6.1.0. </para> </listitem> <listitem> <para> - <xref linkend="news-5-1-16-cge"/>: Includes - <xref linkend="news-5-1-16-ndb-6-2-0"/> and - <xref linkend="news-5-1-18-ndb-6-2-1"/>. + <xref linkend="news-5-1-16-cge"/>: </para> <para> - These releases include all feature enhancements and + Includes <xref linkend="news-5-1-16-ndb-6-2-0"/>. + </para> + + <para> + This release includes all feature enhancements and bugfixes made in MySQL 5.1 up to and including 5.1.16, as - well as those CGE-specific enhancements that were made in - ndb-6.1.<replaceable>x</replaceable> releases. + well as those enhancements specific to &mccge-series; that + were made in ndb-6.1.<replaceable>x</replaceable> + releases. </para> </listitem> + <listitem> + <para> + <xref linkend="news-5-1-18-cge"/>: + </para> + + <para> + Includes these changelogs: + + <itemizedlist> + + <listitem> + <para> + <xref linkend="news-5-1-18-ndb-6-2-1"/> and + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-18-ndb-6-2-2"/>. + </para> + </listitem> + + </itemizedlist> + </para> + + <para> + These releases include all feature enhancements and + bugfixes made in MySQL 5.1 up to and including 5.1.18, as + well as those enhancements specific to &mccge-series; that + were made in ndb-6.2.1 and ndb-6.2.2. + </para> + + <note> + <para> + MySQL 5.1.18-ndb-6.2.1 was withdrawn after release, and + is no longer available for download in source or binary + form. + </para> + </note> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-19-cge"/>: + </para> + + <para> + Includes these changelogs: + + <itemizedlist> + + <listitem> + <para> + <xref linkend="news-5-1-19-ndb-6-2-3"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-19-ndb-6-2-4"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-19-ndb-6-2-5"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-19-ndb-6-3-0"/> + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-19-ndb-6-3-1"/> + </para> + </listitem> + + </itemizedlist> + </para> + + <para> + These releases include all feature enhancements and + bugfixes made in MySQL 5.1 up to and including 5.1.19, as + well as those enhancements specific to &mccge-series; that + were made in ndb-6.2.<replaceable>x</replaceable> releases + beginning with MySQL 5.1.19-ndb-6.2.3, as well as those + that were made in ndb-6.2.1 and ndb-6.2.2. + </para> + </listitem> + + <listitem> + <para> + <xref linkend="news-5-1-20-cge"/>: + </para> + + <para> + Includes this changelog: + + <itemizedlist> + + <listitem> + <para> + <xref linkend="news-5-1-20-ndb-6-3-2"/> + </para> + </listitem> + + </itemizedlist> + </para> + + <para> + These releases include all feature enhancements and + bugfixes made in MySQL 5.1 up to and including 5.1.20, as + well as those enhancements specific to &mccge-series; that + were made in ndb-6.3.<replaceable>x</replaceable> releases + beginning with MySQL 5.1.19-ndb-6.3.0. + </para> + </listitem> + </itemizedlist> Each of the &mccge-series; includes enhancements to the @@ -815,60 +1411,21 @@ point in the future. </para> - </formalpara> - - <para> - Some fixes that were applied first in &mccge-series; have already - been ported to MySQL ¤t-series;. In these cases, the fix is - listed twice in <xref linkend="news-5-1-x"/>. - </para> - - <para> - Since all bugfixes applied in &mccge-series; relate to MySQL - Cluster, changelog entries for CGE releases are not prefixed with - <quote><literal>NDB Cluster</literal>:</quote> as MySQL Cluster - bugfixes in mainline MySQL ¤t-series; are. - </para> - - <important> <para> - This chapter of the MySQL Manual covers both MySQL - ¤t-series; and &mccge-series;. + Some fixes that were applied first in &mccge-series; have + already been ported to MySQL ¤t-series;. In these cases, + the fix is listed twice in <xref linkend="news-5-1-x"/>. </para> <para> - Information which applies to &mccge-series; releases but not to - mainline ¤t-series; releases is indicated with a warning - such as this one: + Since all bugfixes applied in &mccge-series; relate to MySQL + Cluster, changelog entries for CGE releases are not prefixed + with <quote><literal>NDB Cluster</literal>:</quote> as MySQL + Cluster bugfixes in mainline MySQL ¤t-series; are. </para> - - &mccge-warning-begin; - - <para> - Information which applies to mainline MySQL ¤t-series; - releases but not to &mccge-series; releases is indicated with a - warning such as this one: - </para> - - &mccge-warning-unsupported-begin; - </important> - <para> - Currently, both the ndb-6.1.<replaceable>x</replaceable> and - ndb-6.2.<replaceable>x</replaceable> series are under active - development, with the ndb-6.1.<replaceable>x</replaceable> series - intended for use by telecommunications customers and - ndb-6.2.<replaceable>x</replaceable> intended for testing - purposes. - </para> + </section> - <para> - Additional information about obtaining &mccge-series; binaries can - be found on the MySQL AB web site at - <ulink url="http://www.mysql.com/products/database/clustercge/"/>, - or by contacting <email>sales@stripped</email>. - </para> - </section> <section id="mysql-cluster-multi-computer"> @@ -4953,8 +5510,7 @@ <para> Setting this parameter allows you to control directly the size of redo log files. The default is - <literal>16M</literal>. This parameter was added in MySQL - 5.1.15/NDB-6.1.11. + <literal>16M</literal>. </para> &mccge-warning-end-cluster; @@ -5365,6 +5921,67 @@ <listitem> <indexterm> + <primary><literal>ODirect</literal></primary> + </indexterm> + + <para id="mysql-cluster-param-ndbd-definition-odirect"> + <literal>ODirect</literal> + </para> + + <para> + Enabling this parameter causes <literal>NDB</literal> to + attempt using <literal>O_DIRECT</literal> writes for LCP, + backups, and redo logs, often lowering + <command>kswapd</command> and CPU usage. + </para> + + <warning> + <para> + When using MySQL Cluster or &mccge-series; on Linux, + this <literal>ODirect</literal> should be enabled for + 2.6 or newer kernels. + </para> + </warning> + + <para> + This parameter was added in the following releases: + + <itemizedlist> + + <listitem> + <para> + MySQL 5.1.20 + </para> + </listitem> + + <listitem> + <para> + MySQL 5.1.15-ndb-6.1.11 + </para> + </listitem> + + <listitem> + <para> + MySQL 5.1.19-ndb-6.2.3 + </para> + </listitem> + + <listitem> + <para> + MySQL 5.1.19-ndb-6.3.0 + </para> + </listitem> + + </itemizedlist> + </para> + + <para> + <literal>ODirect</literal> is disabled by default. + </para> + </listitem> + + <listitem> + <indexterm> <primary><literal>RestartOnErrorInsert</literal></primary> </indexterm> @@ -7770,8 +8387,7 @@ <entry/> </row> <row> - <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-filesystempath">FileSystemPath</link></literal> - (Added in MySQL-5.1.15/NDB-6.1.11)</entry> + <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-filesystempath">FileSystemPath</link></literal></entry> <entry>string</entry> <entry>value specified for <literal>DataDir</literal></entry> <entry>N/A</entry> @@ -8121,6 +8737,14 @@ <entry>IS</entry> </row> <row> + <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-odirect">ODirect</link></literal></entry> + <entry>boolean</entry> + <entry>0</entry> + <entry>0</entry> + <entry>1</entry> + <entry>NR</entry> + </row> + <row> <entry><literal><link linkend="mysql-cluster-param-ndbd-definition-redobuffer">RedoBuffer</link></literal></entry> <entry>bytes</entry> <entry>8M</entry> @@ -14556,7 +15180,7 @@ <entry><literal>\n</literal> (linefeed character)</entry> </row> <row> - <entry><option>--appends</option></entry> + <entry><option>--append</option></entry> <entry><emphasis>None</emphasis></entry> <entry>When used with <option>--tab</option>, causes the data to be appended to existing files of the same name</entry> @@ -18178,21 +18802,41 @@ <para> The following are known problems or issues when using - replication with MySQL Cluster in MySQL 5.1: + replication with MySQL Cluster in MySQL ¤t-series;: </para> <itemizedlist> <listitem> - <para> - Prior to MySQL 5.1.18, a MySQL Cluster replication slave - <command>mysqld</command> had no way of detecting that the - connection from the master had been interrupted (due to, for - instance, the master going down or a network failure). For - this reason, it was possible for the slave to become - inconsistent with the master. - </para> + <formalpara> + <title>Loss of master-slave connection</title> + + <para> + In some previous versions of MySQL Cluster, this was an + issue because slaves did not detect loss of communication + with the master. In MySQL ¤t-series;, this is no + longer a problem, because the master issues a + <quote>gap</quote> event when connecting to the cluster. + When the slave encounters a gap in the replication log, it + stops with an error message. This message is available in + the output of <literal>SHOW SLAVE STATUS</literal>, and + indicates that the SQL thread has stopped due to an + incident registered in the replication stream, and that + manual intervention is required. In order to restart the + slave, it is necessary to issue the following commands: + +<programlisting> +SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; +START SLAVE; +</programlisting> + + The slave then resumes reading the master binlog from the + point where the gap was recorded. + </para> + + </formalpara> + <para> (If high availability is a requirement for the slave server or cluster, then it is still advisable to set up multiple @@ -18203,75 +18847,44 @@ <xref linkend="mysql-cluster-replication-two-channels"/>, and <xref linkend="mysql-cluster-replication-failover"/>.) </para> + </listitem> - &mccge-warning-unsupported-begin; + <listitem> + <formalpara> - <para> - Beginning with MySQL 5.1.18, the master issues a - <quote>gap</quote> event when connecting to the cluster. - When the slave encounters a gap in the replication log, it - stops with an error message. This message is available in - the output of <literal>SHOW SLAVE STATUS</literal>, and - indicates that the SQL thread has stopped due to an incident - registered in the replication stream, and that manual - intervention is required. In order to restart the slave, it - is necessary to issue the following commands: + <title>Multi-byte character sets</title> -<programlisting> -SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; -START SLAVE; -</programlisting> + <para> + There are several known issues with regard to the use of + multi-byte characters sets with MySQL Cluster Replication. + See Bug #27404 (fixed in MySQL 5.1.21), Bug #29562, Bug + #29563, and Bug #29564 for more information. + </para> - The slave then resumes reading the master binlog from the - point where the gap was recorded. - </para> - - &mccge-warning-end-cluster; - + </formalpara> </listitem> <listitem> - <para> - <emphasis role="bold">Multi-byte character sets</emphasis> - </para> + <formalpara> - <para> - There are several known issues with regard to the use of - multi-byte characters sets with MySQL Cluster Replication. - See Bug #29562, Bug #29563, and Bug #29564 for more - information. - </para> - </listitem> + <title>Circular replication</title> - <listitem> - <para> - <emphasis role="bold">Circular replication</emphasis>: - </para> + <para> + In MySQL ¤t-series;, circular replication is + supported as discussed in the next few paragraphs, in + which we consider the example of a replication setup + involving three MySQL Clusters numbered 1, 2, and 3, in + which Cluster 1 acts as the replication master for Cluster + 2, Cluster 2 acts as the 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. + </para> - <para> - Prior to MySQL 5.1.18, circular replication was not - supported with MySQL Cluster replication, due to the fact - that all log events created in a particular MySQL Cluster - were wrongly tagged with the server ID of the MySQL server - used as master and not with the server ID of the originating - server. - </para> + </formalpara> - &mccge-warning-unsupported-begin; - <para> - Beginning with MySQL 5.1.18, this limitation is lifted, as - discussed in the next few paragraphs, in which we consider - the example of a replication setup involving three MySQL - Clusters numbered 1, 2, and 3, in which Cluster 1 acts as - the replication master for Cluster 2, Cluster 2 acts as the - 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. - </para> - - <para> Circular replication using these clusters is supported as long as: @@ -18348,37 +18961,41 @@ </listitem> <listitem> - <para> - The use of data definition statements, such as - <literal>CREATE TABLE</literal>, <literal>DROP - TABLE</literal>, and <literal>ALTER TABLE</literal>, are - recorded in the binary log for only the MySQL server on - which they are issued. - </para> + <formalpara> + + <title>DDL statements</title> + + <para> + The use of data definition statements, such as + <literal>CREATE TABLE</literal>, <literal>DROP + TABLE</literal>, and <literal>ALTER TABLE</literal>, are + recorded in the binary log for only the MySQL server on + which they are issued. + </para> + + </formalpara> </listitem> <listitem> - <para> - In MySQL 5.1.6, only those <literal>NDB</literal> tables - having explicit primary keys could be replicated. This - limitation was lifted in MySQL 5.1.7. - </para> - </listitem> + <formalpara> - <listitem> - <para> - Restarting the cluster with the - <option>&ddash;initial</option> option will cause the - sequence of GCI and epoch numbers to start over from - <literal>0</literal>. (This is generally true of MySQL - Cluster and not limited to replication scenarios involving - Cluster.) The MySQL servers involved in replication should - in this case be restarted. After this, you should use the - <literal>RESET MASTER</literal> and <literal>RESET - SLAVE</literal> statements to clear the invalid - <literal>ndb_binlog_index</literal> and - <literal>ndb_apply_status</literal> tables. respectively. - </para> + <title>Restarting with <option>--initial</option></title> + + <para> + Restarting the cluster with the + <option>&ddash;initial</option> option will cause the + sequence of GCI and epoch numbers to start over from + <literal>0</literal>. (This is generally true of MySQL + Cluster and not limited to replication scenarios involving + Cluster.) The MySQL servers involved in replication should + in this case be restarted. After this, you should use the + <literal>RESET MASTER</literal> and <literal>RESET + SLAVE</literal> statements to clear the invalid + <literal>ndb_binlog_index</literal> and + <literal>ndb_apply_status</literal> tables. respectively. + </para> + + </formalpara> </listitem> </itemizedlist> @@ -18966,6 +19583,56 @@ <xref linkend="mysql-cluster-replication-two-channels"/>. </para> + <para> + It is also possible to improve cluster replication performance + enabling batched updates. This can be accomplished by starting + slave <command>mysqld</command> processes with the + <option>--slave-allow-batching</option> option. Normally, + updates are applied as soon as they are received. However, the + use of batching causes updates to be applied in 32 KB batches, + which can result in higher throughput and less CPU usage, + particularly where individual updates are relatively small. + </para> + + <para> + Batching can be turned on and off at runtime. To activate it at + runtime, you can use either of these two statements: + +<programlisting> +SET GLOBAL slave_allow_batching = 1; +SET GLOBAL slave_allow_batching = ON; +</programlisting> + + If a particular batch causes problems (such as a statement whose + effects do not appear to be replicated correctly), slave + batching can be deactivated using either of the following + statements: + +<programlisting> +SET GLOBAL slave_allow_batching = 0; +SET GLOBAL slave_allow_batching = OFF; +</programlisting> + + You can check the current state of slave batching using an + appropriate <literal>SHOW VARIABLES</literal> statement, like + this one: + +<programlisting> +mysql> <userinput>SHOW VARIABLES LIKE 'slave%';</userinput> ++---------------------------+-------+ +| Variable_name | Value | ++---------------------------+-------+ +| slave_allow_batching | ON | +| slave_compressed_protocol | OFF | +| slave_load_tmpdir | /tmp | +| slave_net_timeout | 3600 | +| slave_skip_errors | OFF | +| slave_transaction_retries | 10 | ++---------------------------+-------+ +6 rows in set (0.00 sec) +</programlisting> + </para> + </section> <section id="mysql-cluster-replication-two-channels"> @@ -19771,6 +20438,404 @@ </section> + <section id="mysql-cluster-replication-conflict-resolution"> + + <title>MySQL Cluster Replication Conflict Resolution</title> + + <para> + When using a replication setup involving multiple masters, it is + possible that different masters may try to update the same row + on the slave with different data. Conflict resolution in MySQL + Cluster Replication provides a means of resolving such conflicts + by allowing a user defined <quote>timestamp</quote> column to be + used to determine whether or not an update to the row on a given + master should be applied on the slave. Generally speaking, if + the <quote>timestamp</quote> for a given row coming from the + master is higher than that on the slave, it is applied it; + otherwise it is not applied on the slave. + </para> + + <para> + This replication scheme, also known as <quote>changed parameter + only replication</quote>, is configurable on a per-table basis. + + <itemizedlist> + + <listitem> + <para> + On the master, it must be determined which columns to send + (all columns or only those that have been updated). + </para> + </listitem> + + <listitem> + <para> + On the slave, it must be determined which type of conflict + resolution to apply (none or <quote>latest timestamp + wins</quote>). + </para> + </listitem> + + </itemizedlist> + + If only some but all columns are sent, then the master and slave + can diverge. + </para> + + <note> + <para> + We refer to the column used for determining updates as a + <quote>timestamp</quote> column, but the data type of this + column is never <literal>TIMESTAMP</literal>; rather, its data + type can be either of <literal>INT UNSIGNED</literal> or + <literal>INT UNSIGNED</literal>. + </para> + </note> + + <para> + We can see update operations in terms of <quote>before</quote> + and <quote>after</quote> images — that is, the states of + the table before and after the update is applied. Normally, when + updating a table with a primary key, the <quote>before</quote> + image is not of great interest; however, when we need to + determine on a per-update basis whether or not to use the + updated values on a replication slave, we need to make sure that + both images are written to the master's binary log. This is done + with the <option>--ndb-log-update-as-write</option> startup + option for <command>mysqld</command>, as described later in this + section. + </para> + + <para> + Whether logging of complete rows or of updated columns only is + done is decided when the MySQL server is started, and cannot be + changed online; you must either restart + <command>mysqld</command>, or start a new + <command>mysqld</command> instance with different logging + options. + </para> + + <para> + For purposes of conflict resolution, there are two basic methods + of logging rows: + + <itemizedlist> + + <listitem> + <para> + Log complete rows + </para> + </listitem> + + <listitem> + <para> + Log only column data that has been updated — that + is, column data whose value has been set, regardless of + whether or not this value was actually changed. + </para> + </listitem> + + </itemizedlist> + + Either of the above logging methods can be configured to be done + with or without the <quote>before</quote> image. + </para> + + <formalpara> + + <title><command>mysqld</command> startup options</title> + + <para> + The following <command>mysqld</command> startup options are + available to control conflict resolution: + + <itemizedlist> + + <listitem> + <formalpara> + + <title><option>--ndb-log-update-as-write</option></title> + + <para> + Because conflict resolution is done in the MySQL + Server's update handler, it is necessary to control + logging on the master such that updates are updates + and not writes as in in mainline MySQL 5.1. This + option is turned on by default; to turn it off, start + the server with + <option>--ndb-log-update-as-write=0</option> or + <option>--ndb-log-update-as-write=OFF</option>. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><option>--ndb-log-updated-only</option></title> + + <para> + In general it is preferable to log full rows. However, + depending on the application, it may be sufficient to + log only the updates, and can be more efficient to do + so. + </para> + + </formalpara> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + <para> + To enable conflict resolution, it is necessary to create an + <literal>ndb_replication</literal> table in the + <literal>mysql</literal> system database on the master, the + slave, or both, depending on the conflict resolution type and + method to be employed. This table is used in order to control + logging and conflict resolution function on a per-table basis, + and has one row per table invokved in replication. Each row in + <literal>mysql.ndb_replication</literal> corresponding to a + given table specifies how to log and resolve conflicts for that + table. The definition of this table is shown here: + +<programlisting> +CREATE TABLE mysql.ndb_replication ( + db VARBINARY(63), + table_name VARBINARY(63), + server_id INT UNSIGNED, + binlog_type INT UNSIGNED, + conflict_fn VARBINARY(128), + PRIMARY KEY USING HASH (db, table_name, server_id) +) +ENGINE=NDB +PARTITION BY KEY(db,table_name); +</programlisting> + + The columns in this table are described in the following list: + + <itemizedlist> + + <listitem> + <formalpara> + + <title><literal>db</literal></title> + + <para> + The name of the database containing the table to be + replicated. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>table_name</literal></title> + + <para> + The name of the table to be replicated. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>server_id</literal></title> + + <para> + The unique server ID of the MySQL instance (SQL node) + where the table resides. + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>binlog_type</literal></title> + + <para> + The type of binary logging to be employed. This is + determined as shown in the following table: + + <informaltable> + <tgroup cols="3"> + <colspec colwidth="15*"/> + <colspec colwidth="30*"/> + <colspec colwidth="65*"/> + <thead> + <row> + <entry>Value</entry> + <entry>Internal Value</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>0</entry> + <entry><literal>NBT_DEFAULT</literal></entry> + <entry>Use server default</entry> + </row> + <row> + <entry>1</entry> + <entry><literal>NBT_NO_LOGGING</literal></entry> + <entry>Do not log this table in the binary log</entry> + </row> + <row> + <entry>2</entry> + <entry><literal>NBT_UPDATED_ONLY</literal></entry> + <entry>Only updated attributes are logged</entry> + </row> + <row> + <entry>3</entry> + <entry><literal>NBT_FULL</literal></entry> + <entry>Log full row, even if not updated (MySQL server default behavior)</entry> + </row> + <row> + <entry>4</entry> + <entry><literal>NBT_USE_UPDATE</literal></entry> + <entry>(For generating <literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> and + <literal>NBT_FULL_USE_UPDATE</literal> values + only — not intended for separate use)</entry> + </row> + <row> + <entry>5</entry> + <entry>[<emphasis>Not used</emphasis>]</entry> + <entry>---</entry> + </row> + <row> + <entry>6</entry> + <entry><literal>NBT_UPDATED_ONLY_USE_UPDATE</literal> (= + <literal>NBT_UPDATED_ONLY | + NBT_USE_UPDATE</literal>)</entry> + <entry>Use updated attributes, even if values are unchanged</entry> + </row> + <row> + <entry>7</entry> + <entry><literal>NBT_FULL_USE_UPDATE</literal>(= <literal>NBT_FULL | + NBT_USE_UPDATE</literal>)</entry> + <entry>Use full row, even if values are unchanged</entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + + </formalpara> + </listitem> + + <listitem> + <formalpara> + + <title><literal>conflict_fn</literal></title> + + <para> + The conflict resolution function to be applied. + Currently this function must be specified as either + <literal>NDB$MAX(<replaceable>column_name</replaceable></literal> + or <literal>NULL</literal> (if conflict resolution is + not to be used). + </para> + + </formalpara> + </listitem> + + </itemizedlist> + </para> + + <important> + <para> + The <literal>mysql.ndb_replication</literal> table is read + when the table is set up for replication, so the row + corresponding to a table to be replicated must be inserted + into <literal>mysql.ndb_replication</literal> + <emphasis>before</emphasis> creation of the table to be + replicated takes place. + </para> + </important> + + <remark> + test rpl_ndb_rep_error.test - negative testing of the + mysql.ndb_replication table + </remark> + + <remark> + test rpl_ndb_conflict.test - test the basic "highest wins" + conflict resolution schema + </remark> + + <formalpara> + + <title>Example</title> + + <para> + Suppose you wish to enable conflict resolution on table + <literal>test.t1</literal>, using column + <literal>mycol</literal> as the <quote>timestamp</quote>. This + can be done using the following two steps: + + <itemizedlist> + + <listitem> + <para> + On the master, perform this query: + +<programlisting> +INSERT INTO mysql.ndb_replication VALUES + ("test", "t1", 0, NULL, "NDB$MAX(mycol)"); +</programlisting> + </para> + + <para> + Inserting a 0 into the <literal>server_id</literal> + indicates that all SQL nodes accessing this table should + use the conflict resolution. If you want to use conflict + resolution on a specific <command>mysqld</command> only, + use the actual server ID. + </para> + + <para> + Inserting <literal>NULL</literal> into the + <literal>binlog_type</literal> column has the same + effect as inserting 0 (<literal>NBT_DEFAULT</literal>); + the server default is used. + </para> + </listitem> + + <listitem> + <para> + Create the <literal>test.t1</literal> table: + +<programlisting> +CREATE TABLE test.t1 ( + <replaceable>columns</replaceable> + mycol INT UNSIGNED, + <replaceable>columns</replaceable> +); +</programlisting> + + Now, when updates are done on this table, conflict + resolution will be applied, and the version of the row + having the greatest value for <literal>mycol</literal> + will be written to the slave. + </para> + </listitem> + + </itemizedlist> + </para> + + </formalpara> + + </section> + </section> <section id="mysql-cluster-disk-data"> @@ -19941,8 +21006,8 @@ Every <literal>CREATE LOGFILE GROUP</literal> and <literal>ALTER LOGFILE GROUP</literal> statement must include an <literal>ENGINE</literal> clause. In MySQL - ↷, the permitted values for this clause are - <literal>NDB</literal> and + ¤t-series;, the permitted values for this clause + are <literal>NDB</literal> and <literal>NDBCLUSTER</literal>. </para> @@ -22648,6 +23713,13 @@ <listitem> <para> + Maximum number of data files per tablespace: 2^16 + (65535) + </para> + </listitem> + + <listitem> + <para> The theoretical maximum number of extents per tablespace data file is 2^16 (65525); however, for practical purposes, the recommended maximum number of
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r7442 - in trunk: refman-5.1 refman-5.2 | jon | 13 Aug |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 1.230 sec. using MySQL 5.1.14-beta-log