Author: paul
Date: 2010-07-12 22:32:30 +0200 (Mon, 12 Jul 2010)
New Revision: 21675
Log:
r61077@frost: paul | 2010-07-12 14:46:17 -0500
Oracle style guideline: afterwards -> afterward; backwards -> backward
Modified:
trunk/dynamic-docs/changelog/monitor.xml
trunk/dynamic-docs/changelog/mysqld-1.xml
trunk/dynamic-docs/changelog/mysqld.xml
trunk/dynamic-docs/glossary/innodb.xml
trunk/innodb-plugin-1.1/innodb-performance.xml
trunk/innodb-plugin-1.1/plugin.ent
trunk/mysqldoc-guide/styleguide.xml
trunk/refman-4.1/mysql-cluster-multi-computer.xml
trunk/refman-4.1/mysql-cluster-overview.xml
trunk/refman-5.0/installing-updowngrade.xml
trunk/refman-5.0/mysql-cluster-multi-computer.xml
trunk/refman-5.0/mysql-cluster-overview.xml
trunk/refman-5.0/replication-notes.xml
trunk/refman-5.0/sql-syntax-data-definition.xml
trunk/refman-5.1/dba-log-files.xml
trunk/refman-5.1/information-schema.xml
trunk/refman-5.1/mysql-cluster-management.xml
trunk/refman-5.1/mysql-cluster-multi-computer.xml
trunk/refman-5.1/mysql-cluster-overview.xml
trunk/refman-5.1/replication-notes.xml
trunk/refman-5.5/dba-log-files.xml
trunk/refman-5.5/replication-notes.xml
trunk/refman-6.0/dba-log-files.xml
trunk/refman-6.0/replication-notes.xml
trunk/refman-common/news-cluster.xml
trunk/refman-common/news-innodb.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40730
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61076
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
+ 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:40730
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:61077
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
Modified: trunk/dynamic-docs/changelog/monitor.xml
===================================================================
--- trunk/dynamic-docs/changelog/monitor.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/monitor.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 638 bytes
@@ -151,7 +151,7 @@
<para>
When using &merlin_agent;, if the current configured time went
- backwards (for example during time correction), then the
+ backward (for example, during time correction), the
&merlin_agent; would stop reporting data and induce a high load
on the machine running &merlin_agent;
</para>
Modified: trunk/dynamic-docs/changelog/mysqld-1.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld-1.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/mysqld-1.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 581 bytes
@@ -8070,7 +8070,7 @@
<para>
If the cluster crashed during the execution of a
<literal role="stmt">CREATE LOGFILE GROUP</literal> statement,
- the cluster could not be restarted afterwards.
+ the cluster could not be restarted afterward.
</para>
</message>
Modified: trunk/dynamic-docs/changelog/mysqld.xml
===================================================================
--- trunk/dynamic-docs/changelog/mysqld.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/changelog/mysqld.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 6, Lines Added: 6, Lines Deleted: 6; 2362 bytes
@@ -1344,7 +1344,7 @@
to include <literal>'</literal> characters in
<literal>PARTITION</literal> options must still be removed by
deleting the corresponding <filename>.frm</filename> files and
- re-creating them afterwards.
+ re-creating them afterward.
</para>
</note>
@@ -16241,7 +16241,7 @@
and encounters a row in the binary log that is written in
<literal>ROW</literal> logging format. In that case, the slave
switches to row-based replication temporarily for that event,
- and switches back to the previous format afterwards.
+ and switches back to the previous format afterward.
</para>
</message>
@@ -81008,7 +81008,7 @@
<para>
Alternatively, you can dump the table using
<command>mysqldump</command> prior to upgrading and reload
- it afterwards with <literal role="stmt">LOAD
+ it afterward with <literal role="stmt">LOAD
DATA</literal>.
</para>
</listitem>
@@ -89417,7 +89417,7 @@
version and scheduled events have been used, the upgrade
utilities do not accomodate changes in event-related system
tables. As a workaround, you can dump events before the upgrade,
- then restore them from the dump afterwards. This issue was fixed
+ then restore them from the dump afterward. This issue was fixed
in MySQL 5.1.20.
</para>
@@ -91511,7 +91511,7 @@
sometimes corrupted table resolution for statements which were
prepared before the <literal role="stmt" condition="flush">FLUSH
TABLES</literal> but which were being executed repeatedly
- afterwards.
+ afterward.
</para>
</message>
@@ -119048,7 +119048,7 @@
<para>
<literal>MYSQL_STMT</literal> objects were not preserved
following a connection reset. Attempting to operate on them
- afterwards caused the server to crash.
+ afterward caused the server to crash.
</para>
</message>
Modified: trunk/dynamic-docs/glossary/innodb.xml
===================================================================
--- trunk/dynamic-docs/glossary/innodb.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/dynamic-docs/glossary/innodb.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 738 bytes
@@ -1807,7 +1807,7 @@
data transfer operations, consider doing operations such as
<literal>ALTER TABLE ... ENGINE=INNODB</literal> or
<literal>INSERT INTO ... SELECT * FROM ...</literal> without any
- secondary indexes in place, and creating the indexes afterwards.
+ secondary indexes in place, and creating the indexes afterward.
</para>
<para>
Even if you do not use the InnoDB Plugin as your primary storage
Modified: trunk/innodb-plugin-1.1/innodb-performance.xml
===================================================================
--- trunk/innodb-plugin-1.1/innodb-performance.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/innodb-plugin-1.1/innodb-performance.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 616 bytes
@@ -1193,7 +1193,7 @@
The goal is to make sure that frequently accessed
(<quote>hot</quote>) pages remain in the buffer cache, even as
read-ahead and full table scans bring new blocks in that might or
- might not be accessed afterwards.
+ might not be accessed afterward.
</para>
<para>
Modified: trunk/innodb-plugin-1.1/plugin.ent
===================================================================
--- trunk/innodb-plugin-1.1/plugin.ent 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/innodb-plugin-1.1/plugin.ent 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 4638 bytes
@@ -157,7 +157,7 @@
<!ENTITY glos_full_table_scan "<glossentry id='glos_full_table_scan'><glossterm>full table scan</glossterm> <indexterm significance='preferred'><primary>full table scan</primary></indexterm> <glossdef> <para> An operation that requires reading the entire contents of a table, rather than just selected portions using an index. Typically performed either with small lookup tables, or in data warehousing situations with large tables where all available data is aggregated and analyzed. How frequently these operations occur, and the sizes of the tables relative to available memory, have implications for the algorithms used in query optimization and managing the buffer pool. </para> <para> The purpose of <emphasis role='bold'>indexes</emphasis> is to allow lookups for specific values or ranges of values within a large table, thus avoiding full table scans when practical. </para> <glossseealso otherterm='glos_buffer!
_pool' /> <glossseealso otherterm='glos_index' /> </glossdef> </glossentry> ">
-<!ENTITY glos_fast_index_creation "<glossentry id='glos_fast_index_creation'><glossterm>fast index creation</glossterm> <indexterm significance='preferred'><primary>fast index creation</primary></indexterm> <glossdef> <para> A capability first introduced in the InnoDB Plugin, that speeds up creation of secondary indexes by avoiding the need to completely rewrite the associated table. The speedup applies to dropping secondary indexes also. </para> <para> Because index maintenance can add performance overhead to many data transfer operations, consider doing operations such as <literal>ALTER TABLE ... ENGINE=INNODB</literal> or <literal>INSERT INTO ... SELECT * FROM ...</literal> without any secondary indexes in place, and creating the indexes afterwards. </para> <para> Even if you do not use the InnoDB Plugin as your primary storage engine, you can take advantage of this capability by enabling the Plugin temporar!
ily, just to create or drop indexes, and then switch back to the built-in InnoDB storage engine for normal use. </para> <glossseealso otherterm='glos_index' /> <glossseealso otherterm='glos_secondary_index' /> </glossdef> </glossentry> ">
+<!ENTITY glos_fast_index_creation "<glossentry id='glos_fast_index_creation'><glossterm>fast index creation</glossterm> <indexterm significance='preferred'><primary>fast index creation</primary></indexterm> <glossdef> <para> A capability first introduced in the InnoDB Plugin, that speeds up creation of secondary indexes by avoiding the need to completely rewrite the associated table. The speedup applies to dropping secondary indexes also. </para> <para> Because index maintenance can add performance overhead to many data transfer operations, consider doing operations such as <literal>ALTER TABLE ... ENGINE=INNODB</literal> or <literal>INSERT INTO ... SELECT * FROM ...</literal> without any secondary indexes in place, and creating the indexes afterward. </para> <para> Even if you do not use the InnoDB Plugin as your primary storage engine, you can take advantage of this capability by enabling the Plugin temporari!
ly, just to create or drop indexes, and then switch back to the built-in InnoDB storage engine for normal use. </para> <glossseealso otherterm='glos_index' /> <glossseealso otherterm='glos_secondary_index' /> </glossdef> </glossentry> ">
<!ENTITY glos_fast_shutdown "<glossentry id='glos_fast_shutdown'><glossterm>fast shutdown</glossterm> <indexterm significance='preferred'><primary>fast shutdown</primary></indexterm> <glossdef> <para> A shutdown procedure that is required before installation of the InnoDB Plugin. From the MySQL command line, issue the following command before performing the shutdown: <programlisting>SET GLOBAL innodb_fast_shutdown=0;</programlisting> To make this type of shutdown the default, specify by the configuration parameter <literal>innodb_fast_shutdown=0</literal>. </para> <glossseealso otherterm='glos_slow_shutdown' /> <glossseealso otherterm='glos_shutdown' /> </glossdef> </glossentry> ">
Modified: trunk/mysqldoc-guide/styleguide.xml
===================================================================
--- trunk/mysqldoc-guide/styleguide.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/mysqldoc-guide/styleguide.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 6, Lines Deleted: 0; 504 bytes
@@ -1329,6 +1329,12 @@
<listitem>
<para>
+ afterward, not afterwards
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
a lot requires two words; alot is wrong
</para>
</listitem>
Modified: trunk/refman-4.1/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-multi-computer.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-4.1/mysql-cluster-multi-computer.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes
@@ -1753,7 +1753,7 @@
<para>
Use <command>mysqldump</command> (see
<xref linkend="mysqldump"/>) to create a backup
- prior to the upgrade; afterwards, restore the dump
+ prior to the upgrade; afterward, restore the dump
using
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>.
Modified: trunk/refman-4.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-overview.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-4.1/mysql-cluster-overview.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 680 bytes
@@ -1551,7 +1551,7 @@
<literal role="type">BLOB</literal> or
<literal role="type">TEXT</literal> columns, or, in
cases where such queries are not avoidable, by
- committing transactions as soon as possible afterwards.
+ committing transactions as soon as possible afterward.
</para>
<para>
Modified: trunk/refman-5.0/installing-updowngrade.xml
===================================================================
--- trunk/refman-5.0/installing-updowngrade.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/installing-updowngrade.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 621 bytes
@@ -590,7 +590,7 @@
This problem does not occur (and thus these two steps are
not required) for tables upgraded using the recommended
procedure of dumping tables prior to the upgrade and
- reloading them afterwards.
+ reloading them afterward.
</para>
<note>
Modified: trunk/refman-5.0/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-multi-computer.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/mysql-cluster-multi-computer.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes
@@ -1740,7 +1740,7 @@
<para>
Use <command>mysqldump</command> (see
<xref linkend="mysqldump"/>) to create a backup
- prior to the upgrade; afterwards, restore the dump
+ prior to the upgrade; afterward, restore the dump
using
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>.
Modified: trunk/refman-5.0/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-overview.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/mysql-cluster-overview.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 680 bytes
@@ -1711,7 +1711,7 @@
<literal role="type">BLOB</literal> or
<literal role="type">TEXT</literal> columns, or, in
cases where such queries are not avoidable, by
- committing transactions as soon as possible afterwards.
+ committing transactions as soon as possible afterward.
</para>
<para>
Modified: trunk/refman-5.0/replication-notes.xml
===================================================================
--- trunk/refman-5.0/replication-notes.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/replication-notes.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 763 bytes
@@ -945,7 +945,7 @@
<literal role="stmt">REPAIR TABLE</literal> to repair it, you
should first stop replication (if it is still running) before
using <literal role="stmt">REPAIR TABLE</literal>, then
- afterwards compare the master's and slave's copies of
+ afterward compare the master's and slave's copies of
the table and be prepared to correct any discrepancies manually,
before restarting replication.
</para>
Modified: trunk/refman-5.0/sql-syntax-data-definition.xml
===================================================================
--- trunk/refman-5.0/sql-syntax-data-definition.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.0/sql-syntax-data-definition.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1187 bytes
@@ -5963,7 +5963,7 @@
(<literal><replaceable>table_name</replaceable>.<replaceable>trigger_name</replaceable></literal>).
When upgrading from a previous version of MySQL 5.0 to MySQL
5.0.10 or newer, you must drop all triggers <emphasis>before
- upgrading</emphasis> and re-create them afterwards, or else
+ upgrading</emphasis> and re-create them afterward, or else
<literal role="stmt">DROP TRIGGER</literal> does not work after
the upgrade. See
<xref linkend="upgrading-from-previous-series"/>, for a
@@ -5976,7 +5976,7 @@
dropped following a downgrade to MySQL 5.0.15 or earlier. If you
wish to perform such a downgrade, you must also in this case drop
all triggers <emphasis>prior to</emphasis> the downgrade, and then
- re-create them afterwards.
+ re-create them afterward.
</para>
<para>
Modified: trunk/refman-5.1/dba-log-files.xml
===================================================================
--- trunk/refman-5.1/dba-log-files.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/dba-log-files.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes
@@ -1473,7 +1473,7 @@
and encounters an event in the binary log that is written in
<literal>ROW</literal> logging format. In that case, the slave
switches to row-based replication temporarily for that event,
- and switches back to the previous format afterwards.
+ and switches back to the previous format afterward.
</para>
<para>
Modified: trunk/refman-5.1/information-schema.xml
===================================================================
--- trunk/refman-5.1/information-schema.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/information-schema.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 605 bytes
@@ -5572,7 +5572,7 @@
<para>
If you create a MySQL Cluster Disk Data table and then insert
some rows into it, you can see approximately how much space
- remains for undo logging afterwards, for example:
+ remains for undo logging afterward, for example:
</para>
<programlisting>
Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-management.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 689 bytes
@@ -9289,7 +9289,7 @@
For each column, this table shows the name, data type, and a
brief description of each <literal>ndbinfo.pools</literal>
column (as it appeared prior to MySQL Cluster NDB 7.1.3).
- Additional information can be found in the notes afterwards.
+ Additional information can be found in the notes afterward.
</para>
<informaltable>
Modified: trunk/refman-5.1/mysql-cluster-multi-computer.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-multi-computer.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-multi-computer.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 754 bytes
@@ -3062,7 +3062,7 @@
<para>
Use <command>mysqldump</command> (see
<xref linkend="mysqldump"/>) to create a backup
- prior to the upgrade; afterwards, restore the dump
+ prior to the upgrade; afterward, restore the dump
using
<literal role="stmt" condition="load-data">LOAD DATA
INFILE</literal>.
Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/mysql-cluster-overview.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 697 bytes
@@ -4945,7 +4945,7 @@
that retrieve <literal role="type">BLOB</literal> or
<literal role="type">TEXT</literal> columns, or, in
cases where such queries are not avoidable, by
- committing transactions as soon as possible afterwards.
+ committing transactions as soon as possible afterward.
</para>
</listitem>
Modified: trunk/refman-5.1/replication-notes.xml
===================================================================
--- trunk/refman-5.1/replication-notes.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.1/replication-notes.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes
@@ -1688,7 +1688,7 @@
disable the Event Scheduler on the slave (using <literal>SET
GLOBAL event_scheduler = OFF;</literal>), run the
<literal role="stmt">UPDATE</literal>, restart the server,
- then re-enable the Event Scheduler afterwards (using
+ then re-enable the Event Scheduler afterward (using
<literal>SET GLOBAL event_scheduler = ON;</literal>).
</para>
@@ -2216,7 +2216,7 @@
<literal role="stmt">REPAIR TABLE</literal> to repair it, you
should first stop replication (if it is still running) before
using <literal role="stmt">REPAIR TABLE</literal>, then
- afterwards compare the master's and slave's copies of
+ afterward compare the master's and slave's copies of
the table and be prepared to correct any discrepancies manually,
before restarting replication.
</para>
Modified: trunk/refman-5.5/dba-log-files.xml
===================================================================
--- trunk/refman-5.5/dba-log-files.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.5/dba-log-files.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes
@@ -1293,7 +1293,7 @@
and encounters an event in the binary log that is written in
<literal>ROW</literal> logging format. In that case, the slave
switches to row-based replication temporarily for that event,
- and switches back to the previous format afterwards.
+ and switches back to the previous format afterward.
</para>
<para>
Modified: trunk/refman-5.5/replication-notes.xml
===================================================================
--- trunk/refman-5.5/replication-notes.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-5.5/replication-notes.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes
@@ -1621,7 +1621,7 @@
disable the Event Scheduler on the slave (using <literal>SET
GLOBAL event_scheduler = OFF;</literal>), run the
<literal role="stmt">UPDATE</literal>, restart the server,
- then re-enable the Event Scheduler afterwards (using
+ then re-enable the Event Scheduler afterward (using
<literal>SET GLOBAL event_scheduler = ON;</literal>).
</para>
@@ -2131,7 +2131,7 @@
<literal role="stmt">REPAIR TABLE</literal> to repair it, you
should first stop replication (if it is still running) before
using <literal role="stmt">REPAIR TABLE</literal>, then
- afterwards compare the master's and slave's copies of
+ afterward compare the master's and slave's copies of
the table and be prepared to correct any discrepancies manually,
before restarting replication.
</para>
Modified: trunk/refman-6.0/dba-log-files.xml
===================================================================
--- trunk/refman-6.0/dba-log-files.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-6.0/dba-log-files.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 639 bytes
@@ -1337,7 +1337,7 @@
and encounters an event in the binary log that is written in
<literal>ROW</literal> logging format. In that case, the slave
switches to row-based replication temporarily for that event,
- and switches back to the previous format afterwards.
+ and switches back to the previous format afterward.
</para>
<para>
Modified: trunk/refman-6.0/replication-notes.xml
===================================================================
--- trunk/refman-6.0/replication-notes.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-6.0/replication-notes.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 2, Lines Added: 2, Lines Deleted: 2; 1192 bytes
@@ -1573,7 +1573,7 @@
disable the Event Scheduler on the slave (using <literal>SET
GLOBAL event_scheduler = OFF;</literal>), run the
<literal role="stmt">UPDATE</literal>, restart the server,
- then re-enable the Event Scheduler afterwards (using
+ then re-enable the Event Scheduler afterward (using
<literal>SET GLOBAL event_scheduler = ON;</literal>).
</para>
@@ -2029,7 +2029,7 @@
<literal role="stmt">REPAIR TABLE</literal> to repair it, you
should first stop replication (if it is still running) before
using <literal role="stmt">REPAIR TABLE</literal>, then
- afterwards compare the master's and slave's copies of
+ afterward compare the master's and slave's copies of
the table and be prepared to correct any discrepancies manually,
before restarting replication.
</para>
Modified: trunk/refman-common/news-cluster.xml
===================================================================
--- trunk/refman-common/news-cluster.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-common/news-cluster.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 590 bytes
@@ -7,7 +7,7 @@
]>
<!--
The Cluster changelog was kept separate up to version 4.1.13 or 5.0.7,
-respectively. Afterwards, and for all 5.1 versions, the Cluster
+respectively. Afterward, and for all 5.1 versions, the Cluster
changelog was merged into the general server changelog.
-->
<section id="mysql-cluster-change-history">
Modified: trunk/refman-common/news-innodb.xml
===================================================================
--- trunk/refman-common/news-innodb.xml 2010-07-12 20:32:04 UTC (rev 21674)
+++ trunk/refman-common/news-innodb.xml 2010-07-12 20:32:30 UTC (rev 21675)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 591 bytes
@@ -7,7 +7,7 @@
]>
<!--
The InnoDB changelog was kept separate up to version 4.0.21 or 4.1.4,
-respectively. Afterwards, and for all 5.0 versions, the InnoDB changelog was
+respectively. Afterward, and for all 5.0 versions, the InnoDB changelog was
merged into the general server changelog.
-->
<section id="innodb-change-history">
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r21675 - in trunk: . dynamic-docs/changelog dynamic-docs/glossary innodb-plugin-1.1 mysqldoc-guide refman-4.1 refman-5.... | paul.dubois | 12 Jul |
