Below is the list of changes that have just been committed into a local
mysqldoc repository of paul. When paul does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html
ChangeSet
1.2703 05/05/20 21:37:24 paul@stripped +1 -0
manual.texi:
Tweaks.
Docs/manual.texi
1.2915 05/05/20 21:37:09 paul@stripped +53 -50
Tweaks.
# This is a BitKeeper patch. What follows are the unified diffs for the
# set of deltas contained in the patch. The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User: paul
# Host: frost.snake.net
# Root: /Volumes/frost2/MySQL/bk/mysqldoc
--- 1.2914/Docs/manual.texi 2005-05-20 14:15:28 -05:00
+++ 1.2915/Docs/manual.texi 2005-05-20 21:37:09 -05:00
@@ -27432,20 +27432,20 @@
You should include such options as necessary so that the MySQL server allows
you to connect to it.
-We'll consider data is stored into the @code{InnoDB} storage engine of
+We'll assume that data is stored into the @code{InnoDB} storage engine of
MySQL, which has support for transactions and automatic crash recovery.
-We'll always assume the MySQL server is under load at the time of crash. If
-it were not, no recovery would ever be needed.
+We'll always assume that the MySQL server is under load at the time of
+crash. If it were not, no recovery would ever be needed.
For the cases of operating system crashes or power failures, we can assume
the MySQL disk data is available after a restart. The @code{InnoDB} data
-files do not contain consistent data due to the crash, but @code{InnoDB}
+files might not contain consistent data due to the crash, but @code{InnoDB}
reads its logs and finds in them the list of pending committed and
-non-committed transactions that have not been flushed to the data files. It
-automatically rolls back those that were not committed, and flushes to the
-data files those that were committed. Information about this recovery
-process is conveyed to the user through the MySQL error log. The following
-is an example log excerpt:
+non-committed transactions that have not been flushed to the data files.
+@code{InnoDB} automatically rolls back those that were not committed, and
+flushes to its data files those that were committed. Information about this
+recovery process is conveyed to the user through the MySQL error log. The
+following is an example log excerpt:
@example
InnoDB: Database was not shut down normally.
@@ -27471,12 +27471,12 @@
mysqld: ready for connections
@end example
-For the cases of filesystem crashes or hardware problems, we can assume the
+For the cases of filesystem crashes or hardware problems, we can assume that the
MySQL disk data is @emph{not} available after a restart. This means that
MySQL fails to start successfully because some blocks of disk data are
no longer readable. In this case, it's necessary to reformat the disk,
install a new one, or otherwise correct the underlying problem. Then it's
-necessary to recover our MySQL data from backups---which means that we must
+necessary to recover our MySQL data from backups, which means that we must
already have made backups. To make sure that is the case, let's step back in
time and design a backup policy.
@@ -27492,8 +27492,8 @@
We all know that backups must be scheduled periodically. Full backups (a
snapshot of the data at a point in time) can be done in MySQL with several
tools. For example, @code{InnoDB Hot Backup} provides online non-blocking
-physical backup of the InnoDB data file, and @command{mysqldump} provides
-online logical backup. This discussion uses @command{mysqldump}.
+physical backup of the @code{InnoDB} data files, and @command{mysqldump}
+provides online logical backup. This discussion uses @command{mysqldump}.
Assume that we make a backup on Sunday at 1 PM, when load is low. The
following command makes a full backup of all our
@@ -27550,8 +27550,8 @@
tell it to close the current binary log file and begin a new one manually by
issuing a @code{FLUSH LOGS} SQL statement or with a @command{mysqladmin
flush-logs} command. @command{mysqldump} also has an option to flush the
-logs. The @code{.index} file contains the list of all MySQL binary logs in
-the directory. This file is used for replication.
+logs. The @code{.index} file in the data directory contains the list of all
+MySQL binary logs in the directory. This file is used for replication.
The MySQL binary logs are important for recovery, because they are
incremental backups. If you make sure to flush the logs when you make your
@@ -30063,40 +30063,43 @@
MySQL 4.1 has the same binary log format as 4.0.
@xref{Replication Compatibility}.
-By default, the binary log is not synchronized to disk at each write. So
-if the operating system or machine (not only the MySQL server) crashes
-there is a chance that the last statements of the binary log are lost. To
-prevent this, you can make the binary log be synchronized to disk after
-every Nth binary log write, with the @code{sync_binlog} global variable
-(1 being the safest value, but also the slowest). @xref{Server system
-variables}. Even with this set to 1, there is still the chance of an
-inconsistency between the tables content and the binary log content in
-case of crash. For example, if using @code{InnoDB} tables, and the MySQL
-server processes a @code{COMMIT} statement, it writes the whole transaction
-to the binary log and then commits this transaction into @code{InnoDB}. If
-it crashes between those two operations, at restart the transaction is
-rolled back by InnoDB but still exist in the binary log. This problem can be
-solved with the @code{--innodb-safe-binlog} option (available starting from
-MySQL 4.1.3), which adds consistency between the content of @code{InnoDB}
-tables and the binary log. For this option to really bring safety to you,
-the MySQL server should also be configured to synchronize to disk, at every
-transaction, the binary log (@code{sync_binlog=1}) and (which is true by
-default) the @code{InnoDB} logs. The effect of this option is that at restart
-after a crash,
-after doing a rollback of transactions, the MySQL server cuts rolled
-back @code{InnoDB} transactions from the binary log. This ensures that the
-binary log reflects the exact data of @code{InnoDB} tables, and so, that
-the slave remains in sync with the master (not receiving a statement which
-has been rolled back). Note that @code{--innodb-safe-binlog} can be used
-even if the MySQL server updates other storage engines than InnoDB. Only
-statements/transactions affecting @code{InnoDB} tables are subject to
-being removed from the binary log at @code{InnoDB}'s crash recovery. If at
-crash recovery the MySQL server discovers that the binary log is shorter
-than it should have been (that is, it lacks at least one successfully committed
+By default, the binary log is not synchronized to disk at each write. So if
+the operating system or machine (not only the MySQL server) crashes, there
+is a chance that the last statements of the binary log are lost. To prevent
+this, you can make the binary log be synchronized to disk after every
+@var{N}th binary log write, with the @code{sync_binlog} global variable (1
+being the safest value, but also the slowest). @xref{Server system
+variables}. Even with @code{sync_binlog} set to 1, there is still the
+chance of an inconsistency between the tables content and the binary log
+content in case of crash. For example, if using @code{InnoDB} tables, and
+the MySQL server processes a @code{COMMIT} statement, it writes the whole
+transaction to the binary log and then commits this transaction into
+@code{InnoDB}. If it crashes between those two operations, at restart the
+transaction is rolled back by @code{InnoDB} but still exists in the binary
+log. This problem can be solved with the @code{--innodb-safe-binlog} option
+(available starting from MySQL 4.1.3), which adds consistency between the
+content of @code{InnoDB} tables and the binary log.
+
+For this option to really bring safety to you, the MySQL server should also
+be configured to synchronize to disk, at every transaction, the binary log
+(@code{sync_binlog=1}) and (which is true by default) the @code{InnoDB}
+logs. The effect of this option is that at restart after a crash, after
+doing a rollback of transactions, the MySQL server cuts rolled back
+@code{InnoDB} transactions from the binary log. This ensures that the binary
+log reflects the exact data of @code{InnoDB} tables, and so, that the slave
+remains in sync with the master (not receiving a statement which has been
+rolled back).
+
+Note that @code{--innodb-safe-binlog} can be used even if the MySQL server
+updates other storage engines than @code{InnoDB}. Only
+statements/transactions affecting @code{InnoDB} tables are subject to being
+removed from the binary log at @code{InnoDB}'s crash recovery. If at crash
+recovery the MySQL server discovers that the binary log is shorter than it
+should have been (that is, it lacks at least one successfully committed
@code{InnoDB} transaction), which should not happen if @code{sync_binlog=1}
and the disk/filesystem do an actual sync when they are requested to (some
-don't), it prints an error message ("The binary log <name> is shorter
-than its expected size"). In this case, this binary log is not correct,
+don't), it prints an error message ("The binary log <name> is shorter than
+its expected size"). In this case, this binary log is not correct,
replication should be restarted from a fresh master's data snapshot.
Before MySQL 4.1.9, a write to a binary log file or binary log index file
@@ -59314,7 +59317,7 @@
@end itemize
-Suppose a table @code{t} is defined as follows:
+Suppose that a table @code{t} is defined as follows:
@example
CREATE TABLE t (i INT NOT NULL);
@@ -83776,7 +83779,7 @@
division by zero can be treated as errors, but this requires
@code{ERROR_FOR_DIVISION_BY_ZERO} in addition to strict mode.
-Suppose we have this statement:
+Suppose that we have this statement:
@example
INSERT INTO t SET i = 1/0;
@@ -88459,7 +88462,7 @@
@code{mysql_stmt_fetch()} is called. Suppose that an application binds
the columns in a result set and calls @code{mysql_stmt_fetch()}.
The client/server
-protocol returns data in the bound buffers. Then suppose the application
+protocol returns data in the bound buffers. Then suppose that the application
binds the columns to a different set of buffers. The protocol does
not place data into the newly bound
buffers until the next call to @code{mysql_stmt_fetch()} occurs.
| Thread |
|---|
| • bk commit - mysqldoc@docsrva tree (paul:1.2703) | paul | 21 May |
