| List: | Commits | « Previous MessageNext Message » | |
| From: | paul | Date: | February 19 2006 12:32am |
| Subject: | svn commit - mysqldoc@docsrva: r1391 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | ||
| View as plain text | |||
Author: paul Date: 2006-02-19 00:32:52 +0100 (Sun, 19 Feb 2006) New Revision: 1391 Log: r7836@frost: paul | 2006-02-18 17:29:48 -0600 General revisions. Modified: trunk/ trunk/refman-4.1/ndbcluster.xml trunk/refman-5.0/ndbcluster.xml trunk/refman-5.1/ndbcluster.xml Property changes on: trunk ___________________________________________________________________ Name: svk:merge - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7832 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223 + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7836 bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:3223 Modified: trunk/refman-4.1/ndbcluster.xml =================================================================== --- trunk/refman-4.1/ndbcluster.xml 2006-02-18 23:32:34 UTC (rev 1390) +++ trunk/refman-4.1/ndbcluster.xml 2006-02-18 23:32:52 UTC (rev 1391) @@ -881,7 +881,8 @@ <para> Change location to the directory containing the downloaded file, unpack the archive, and create a symlink to the - mysql-max executable. Note that the actual file and + <filename>mysql-max</filename> directory named + <filename>mysql</filename>. Note that the actual file and directory names will vary according to the MySQL version number. </para> Modified: trunk/refman-5.0/ndbcluster.xml =================================================================== --- trunk/refman-5.0/ndbcluster.xml 2006-02-18 23:32:34 UTC (rev 1390) +++ trunk/refman-5.0/ndbcluster.xml 2006-02-18 23:32:52 UTC (rev 1391) @@ -881,7 +881,8 @@ <para> Change location to the directory containing the downloaded file, unpack the archive, and create a symlink to the - mysql-max executable. Note that the actual file and + <filename>mysql-max</filename> directory named + <filename>mysql</filename>. Note that the actual file and directory names will vary according to the MySQL version number. </para> Modified: trunk/refman-5.1/ndbcluster.xml =================================================================== --- trunk/refman-5.1/ndbcluster.xml 2006-02-18 23:32:34 UTC (rev 1390) +++ trunk/refman-5.1/ndbcluster.xml 2006-02-18 23:32:52 UTC (rev 1391) @@ -869,9 +869,10 @@ <listitem> <para> Change location to the directory containing the downloaded - file, unpack the archive, and create a symlink to the mysql - directory. Note that the actual file and directory names - will vary according to the MySQL version number. + file, unpack the archive, and create a symlink to the + <filename>mysql</filename> directory. Note that the actual + file and directory names will vary according to the MySQL + version number. </para> <programlisting> @@ -8343,7 +8344,7 @@ the master being the source of the operations and data to be replicated and the slave being the recipient of these. In MySQL Cluster, replication is conceptually very similar but can be more - complex in practise, as it may be extended to cover a number of + complex in practice, as it may be extended to cover a number of different configurations including replicating between two complete clusters. Although a MySQL Cluster itself depends on the <literal>NDB Cluster</literal> storage engine for clustering @@ -8365,7 +8366,7 @@ </mediaobject> <para> - In this scenario the replication process is one in which + In this scenario, the replication process is one in which successive states of a master cluster are logged and saved to a slave cluster. This process is accomplished by a special thread known as the NDB binlog injector thread, which runs on each MySQL @@ -8583,11 +8584,11 @@ database, which is created during the MySQL installation process by the <command>mysql_install_db</command> script, contains a table for storing the binary log's indexing data. As the - binlog_index table is local to each MySQL server and does not - participate in clustering, it uses the <literal>MyISAM</literal> - storage engine, and so must be created separately on each - <command>mysqld</command> participating in the master cluster. - This table is defined as follows: + <literal>binlog_index</literal> table is local to each MySQL + server and does not participate in clustering, it uses the + <literal>MyISAM</literal> storage engine, and so must be created + separately on each <command>mysqld</command> participating in + the master cluster. This table is defined as follows: </para> <programlisting> @@ -8604,10 +8605,9 @@ </programlisting> <para> - In the following figure, the relationship of the MySQL Cluster + The following figure shows the relationship of the MySQL Cluster replication master server, its binlog injector thread, and the - <literal>cluster_replication.binlog_index</literal> table are - shown. + <literal>cluster_replication.binlog_index</literal> table. </para> <mediaobject> @@ -8623,7 +8623,7 @@ <para> An additional table, named <literal>apply_status</literal>, is - used to keep a record of the operations which have been + used to keep a record of the operations that have been replicated from the master to the slave. Unlike the case with <literal>binlog_index</literal>, the data in this table is not specific to any one SQL node in the (slave) cluster, and so @@ -8640,10 +8640,11 @@ </programlisting> <para> - These tables are created in a separate database because they - should not be replicated. No user intervention is normally - required to create or maintain either of them. Both the - <literal>binlog_index</literal> and the + The <literal>binlog_index</literal> and + <literal>apply_status</literal> tables are created in a separate + database because they should not be replicated. No user + intervention is normally required to create or maintain either + of them. Both the <literal>binlog_index</literal> and the <literal>apply_status</literal> tables are maintained by the NDB injector thread. This keeps the master <command>mysqld</command> process updated to changes performed by the NDB storage engine. @@ -8696,15 +8697,15 @@ <programlisting> mysql<replaceable>M</replaceable>> <userinput>GRANT REPLICATION SLAVE</userinput> - -> <userinput>ON *.* TO '<replaceable>slave-user</replaceable>'@'<replaceable>slave-host</replaceable>'</userinput> - -> <userinput>IDENTIFIED BY '<replaceable>slave-password</replaceable>';</userinput> + -> <userinput>ON *.* TO '<replaceable>slave_user</replaceable>'@'<replaceable>slave_host</replaceable>'</userinput> + -> <userinput>IDENTIFIED BY '<replaceable>slave_password</replaceable>';</userinput> </programlisting> <para> - where <replaceable>slave-user</replaceable> is the slave - account username, <replaceable>slave-host</replaceable> is + where <replaceable>slave_user</replaceable> is the slave + account username, <replaceable>slave_host</replaceable> is the hostname or IP address of the replication slave, and - <replaceable>slave-password</replaceable> is the password to + <replaceable>slave_password</replaceable> is the password to assign to this account. </para> @@ -8713,8 +8714,8 @@ <quote><literal>myslave</literal>,</quote> logging in from the host named <quote><literal>rep-slave</literal>,</quote> and using the password - <quote><literal>53cr37</literal>,</quote> you would use the - following <literal>GRANT</literal> statement: + <quote><literal>53cr37</literal>,</quote> use the following + <literal>GRANT</literal> statement: </para> <programlisting> @@ -8739,20 +8740,20 @@ <programlisting> mysql<replaceable>S</replaceable>> <userinput>CHANGE MASTER TO</userinput> - -> <userinput>MASTER_HOST='<replaceable>master-host</replaceable>',</userinput> - -> <userinput>MASTER_PORT=<replaceable>master-port</replaceable>,</userinput> - -> <userinput>MASTER_USER='<replaceable>slave-user</replaceable>',</userinput> - -> <userinput>MASTER_PASSWORD='<replaceable>slave-password</replaceable>';</userinput> + -> <userinput>MASTER_HOST='<replaceable>master_host</replaceable>',</userinput> + -> <userinput>MASTER_PORT=<replaceable>master_port</replaceable>,</userinput> + -> <userinput>MASTER_USER='<replaceable>slave_user</replaceable>',</userinput> + -> <userinput>MASTER_PASSWORD='<replaceable>slave_password</replaceable>';</userinput> </programlisting> <para> - where <replaceable>master-host</replaceable> is the hostname + where <replaceable>master_host</replaceable> is the hostname or IP address of the replication master, - <replaceable>master-port</replaceable> is the port for the + <replaceable>master_port</replaceable> is the port for the slave to use for connecting to the master, - <replaceable>slave-user</replaceable> is the username set up + <replaceable>slave_user</replaceable> is the username set up for the slave on the master, and - <replaceable>slave-password</replaceable> is the password + <replaceable>slave_password</replaceable> is the password set for that user account in the previous step. </para> @@ -8760,8 +8761,8 @@ For example, to tell the slave to replicate from the MySQL server whose hostname is <quote><literal>rep-master</literal>,</quote> using the - replication slave account created in the previous step, you - would use the following statement: + replication slave account created in the previous step, use + the following statement: </para> <programlisting> @@ -8842,14 +8843,15 @@ copying the dump file over to the slave. After this, you can use the <command>mysql</command> client to import the data from the dumpfile into the slave database as shown here, - where <filename>dump_file</filename> is the name of the file - that was generated using <command>mysqldump</command> on the - master, and <literal>database-name</literal> is the name of - the database to be replicated: + where <replaceable>dump_file</replaceable> is the name of + the file that was generated using + <command>mysqldump</command> on the master, and + <replaceable>db_name</replaceable> is the name of the + database to be replicated: </para> <programlisting> -shell<replaceable>S</replaceable>> <userinput>mysql -u root -p database-name < dump_file</userinput> +shell<replaceable>S</replaceable>> <userinput>mysql -u root -p <replaceable>db_name</replaceable> < <replaceable>dump_file</replaceable></userinput> </programlisting> <para> @@ -8949,7 +8951,7 @@ <literal>skip-slave-start</literal> in the slave server's <filename>my.cnf</filename> file, unless you want replication to begin immediately. With the use of this - option, the start of replication will be delayed until the + option, the start of replication is delayed until the appropriate <literal>START SLAVE</literal> statement has been issued, as explained in Step 4 below. </para> @@ -8970,10 +8972,10 @@ </programlisting> <para> - This will instruct the slave to begin reading the master's + This instructs the slave to begin reading the master's binary log from the log's starting point. Otherwise — that is, if you are loading data from the master using a - backup mdash; see + backup — see <xref linkend="mysql-cluster-replication-failover"/>, for information on how to obtain the correct values to use for <literal>MASTER_LOG_FILE</literal> and @@ -9018,7 +9020,7 @@ In a more complete example scenario, we envision two replication channels to provide redundancy and thereby guard against possible failure of a single replication channel. This requires - a total of 4 replication servers, two masters for the master + a total of four replication servers, two masters for the master cluster and two slave servers for the slave cluster. For purposes of the discussion that follows, we assume that unique identifiers are assigned as shown here: @@ -9125,8 +9127,8 @@ </orderedlist> <para> - Note that — as mentioned previously — is not - necessary to enable binary logging on replication slaves. + As mentioned previously, it is not necessary to enable binary + logging on replication slaves. </para> </section> @@ -9138,7 +9140,7 @@ <para> In the event that the primary Cluster replication process fails, it is possible to switch over to the secondary replication - channel. We describe in this section the steps required to + channel. The following procedure describes the steps required to accomplish this. </para> @@ -9146,23 +9148,22 @@ <listitem> <para> - First, you must obtain the time of the most recent global - checkpoint (GCP). That is, you need to determine the most - recent epoch from the <literal>apply_status</literal> table - on the slave cluster, which can be found using the following - query: + Obtain the time of the most recent global checkpoint (GCP). + That is, you need to determine the most recent epoch from + the <literal>apply_status</literal> table on the slave + cluster, which can be found using the following query: </para> <programlisting> mysql<replaceable>S'</replaceable>> <userinput>SELECT @latest:=MAX(epoch)</userinput> - <userinput>FROM cluster_replication.apply_status;</userinput> + -> <userinput>FROM cluster_replication.apply_status;</userinput> </programlisting> </listitem> <listitem> <para> Using the information obtained from the query shown in Step - 1, you can obtain the corresponding records from the + 1, obtain the corresponding records from the <literal>binlog_index</literal> table on the master cluster as shown here: </para> @@ -9182,9 +9183,9 @@ variable <literal>@latest</literal> here to represent the value obtained in Step 1. Of course, it is not possible for one <command>mysqld</command> instance to access user - variables set on another server instance directly; this - value will need to be <quote>plugged in</quote> to the - second query manually or in application code. + variables set on another server instance directly. These + values must be <quote>plugged in</quote> to the second query + manually or in application code. </para> </listitem> @@ -9214,7 +9215,7 @@ <literal>'/var/log/mysql/replication-master-bin.00001'</literal> and so must be quoted when used in SQL or application code. However, the value represented by <literal>@pos</literal> - must <emphasis>not</emphasis> be quoted; while MySQL + must <emphasis>not</emphasis> be quoted. Although MySQL normally attempts to convert strings to numbers, this case is an exception. </para> @@ -9322,7 +9323,7 @@ </para> <para> - If the <filename>my.cnf</filename> file does not spacify + If the <filename>my.cnf</filename> file does not specify where to find the management host, you can start the backup process by passing this information to the <literal>NDB</literal> management client as part of the @@ -9330,14 +9331,14 @@ </para> <programlisting> -shell<replaceable>M</replaceable>> <userinput>ndb_mgm management_host:port -e "START BACKUP"</userinput> +shell<replaceable>M</replaceable>> <userinput>ndb_mgm <replaceable>management_host</replaceable>:<replaceable>port</replaceable> -e "START BACKUP"</userinput> </programlisting> <para> where <replaceable>management_host</replaceable> and <replaceable>port</replaceable> are the hostname and port number of the management server. In our scenario as - outlined earliuer in this section (see + outlined earlier (see <xref linkend="mysql-cluster-replication-preparation"/>), this would be executed as follows: </para> @@ -9377,9 +9378,9 @@ number of <command>ndbd</command> processes (data nodes) as the master; however, it is highly recommended this number be the same. It <emphasis>is</emphasis> necessary that the - slave be started with the <option>&ddash;skip-slave-start - option</option>, to prevent premature startup of the - replication process. + slave be started with the + <option>&ddash;skip-slave-start</option> option, to prevent + premature startup of the replication process. </para> </listitem> @@ -9405,10 +9406,10 @@ </programlisting> <para> - It is important that you make sure that the slave's - apply_status table does not contain any records prior to - running the restore process. You can accomplish this by - running this SQL statement on the slave: + It is important to make sure that the slave's + <literal>apply_status</literal> table does not contain any + records prior to running the restore process. You can + accomplish this by running this SQL statement on the slave: </para> <programlisting> @@ -9420,21 +9421,21 @@ <para> You can now start the cluster restoration process on the replication slave using the <command>ndb_restore</command> - command for each backup file in turn. For the first of these - it is necessary to include the <option>-m</option> option in - order to restore the cluster metadata: + command for each backup file in turn. For the first of + these, it is necessary to include the <option>-m</option> + option to restore the cluster metadata: </para> <programlisting> -shell<replaceable>S</replaceable>> <userinput>ndb_restore -c <replaceable>slave-host</replaceable>:<replaceable>port</replaceable> -n <replaceable>node-id</replaceable> \</userinput> +shell<replaceable>S</replaceable>> <userinput>ndb_restore -c <replaceable>slave_host</replaceable>:<replaceable>port</replaceable> -n <replaceable>node-id</replaceable> \</userinput> <userinput>-b <replaceable>backup-id</replaceable> -m -r <replaceable>dir</replaceable></userinput> </programlisting> <para> - where <replaceable>dir</replaceable> is the path to the - directory where the backup files have been placed on the - replication slave. For the <command>ndb_restore</command> - commands corresponding to the remaining backup files, the + <replaceable>dir</replaceable> is the path to the directory + where the backup files have been placed on the replication + slave. For the <command>ndb_restore</command> commands + corresponding to the remaining backup files, the <option>-m</option> option should <emphasis>not</emphasis> be used. </para> @@ -9473,17 +9474,17 @@ aware of the new tables. (This is due to the fact that the <literal>NDB Cluster</literal> storage engine does not currently support autodiscovery of schema changes. See - <xref linkend="mysql-cluster-replication-schema-discovery"/>). - You can accomplish this using the commands + <xref linkend="mysql-cluster-replication-schema-discovery"/>.) + You can accomplish this using these commands: </para> <programlisting> -mysql<replaceable>S*</replaceable>> <userinput>USE <replaceable>database</replaceable>;</userinput> +mysql<replaceable>S*</replaceable>> <userinput>USE <replaceable>db_name</replaceable>;</userinput> mysql<replaceable>S*</replaceable>> <userinput>SHOW TABLES;</userinput> </programlisting> <para> - where <replaceable>database</replaceable> is the name of the + <replaceable>db_name</replaceable> is the name of the database which was backed up and restored. Where multiple databases have been backed up and then restored, it is necessary to issue the <literal>USE</literal> and @@ -9496,8 +9497,8 @@ <listitem> <para> Now you need to obtain the most recent epoch from the - <literal>binlog_index</literal> table on the slave, as - discussed elsewhere (see + <literal>binlog_index</literal> table on the slave (as + discussed in <xref linkend="mysql-cluster-replication-failover"/>): </para> @@ -9870,7 +9871,7 @@ <para> You can now start using the table as normal. When creating a new table, note that — unlike the case when - dropping tables —, it is <emphasis>not</emphasis> + dropping tables — it is <emphasis>not</emphasis> necessary to stop performing any transactions beforehand. </para> </listitem> @@ -9899,11 +9900,11 @@ <para> Issue any desired <literal>ALTER TABLE</literal> statements that add or remove columns to or from an - existing table, for example: + existing table. For example: </para> <programlisting> -mysql<replaceable>S</replaceable>> <userinput>ALTER TABLE table_name /* <replaceable>column-definition, ...</replaceable> */;</userinput> +mysql<replaceable>S</replaceable>> <userinput>ALTER TABLE <replaceable>table_name</replaceable> /* <replaceable>column definition, ...</replaceable> */;</userinput> </programlisting> </listitem>
| Thread | ||
|---|---|---|
| • svn commit - mysqldoc@docsrva: r1391 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 19 Feb |
© 1995-2008 MySQL AB, 2008-2009 Sun Microsystems, Inc.
Page generated in 0.663 sec. using MySQL 5.1.14-beta-log