Author: paul
Date: 2006-01-29 00:47:07 +0100 (Sun, 29 Jan 2006)
New Revision: 1091
Log:
r6830@frost: paul | 2006-01-28 16:50:51 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/database-administration.xml
trunk/refman-5.0/database-administration.xml
trunk/refman-5.1/database-administration.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6829
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6830
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2588
Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml 2006-01-28 23:46:47 UTC (rev 1090)
+++ trunk/refman-4.1/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
@@ -4924,6 +4924,13 @@
battery-backed cache, which makes synchronization very
fast). This variable was added in MySQL 4.1.3.
</para>
+
+ <para>
+ If the value of <literal>sync_binlog</literal> is 0 (the
+ default), no extra flushing is done. The server relies on
+ the operating system to flush the file contents
+ occasionaly as for any other file.
+ </para>
</listitem>
<listitem>
@@ -6517,7 +6524,7 @@
<para>
The number of key blocks in the key cache that have
- changed but haven't yet been flushed to disk. This
+ changed but have not yet been flushed to disk. This
variable was added in MySQL 4.1.1. It used to be known as
<literal>Not_flushed_key_blocks</literal>.
</para>
@@ -10192,7 +10199,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';</userinput>
+GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';
</programlisting>
<para>
@@ -11287,7 +11294,7 @@
</para>
<programlisting>
-mysql> <userinput>SHOW GRANTS FOR 'bob'@'pc84.example.com';</userinput>
+SHOW GRANTS FOR 'bob'@'pc84.example.com';
</programlisting>
<para>
@@ -12076,8 +12083,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT ALL PRIVILEGES ON db.*</userinput>
- -> <userinput>TO david@'192.58.197.0/255.255.255.0';</userinput>
+GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';
</programlisting>
<para>
@@ -12898,9 +12904,9 @@
<title>&title-privilege-changes;</title>
<para>
- When <command>mysqld</command> starts, all grant table contents
- are read into memory and become effective for access control at
- that point.
+ When <command>mysqld</command> starts, it reads all grant table
+ contents into memory. The in-memory tables become effective for
+ access control at that point.
</para>
<para>
@@ -12935,10 +12941,11 @@
</itemizedlist>
<para>
- If you modify the grant tables using <literal>GRANT</literal>,
- <literal>REVOKE</literal>, or <literal>SET PASSWORD</literal>,
- the server notices these changes and reloads the grant tables
- into memory again immediately.
+ If you modify the grant tables indirectly using statements such
+ as <literal>GRANT</literal>, <literal>REVOKE</literal>, or
+ <literal>SET PASSWORD</literal>, the server notices these
+ changes and loads the grant tables into memory again
+ immediately.
</para>
<para>
@@ -12999,12 +13006,12 @@
<para>
It might also be that the server is running, but you are
trying to connect using a TCP/IP port, named pipe, or Unix
- socket file different from those on which the server is
+ socket file different from the one on which the server is
listening. To correct this when you invoke a client program,
specify a <option>--port</option> option to indicate the
- proper port, or a <option>--socket</option> option to
+ proper port number, or a <option>--socket</option> option to
indicate the proper named pipe or Unix socket file. To find
- out where the socket file is, you can do:
+ out where the socket file is, you can use this command:
</para>
<programlisting>
@@ -13020,7 +13027,7 @@
distributions on Linux), the installation process
initializes the <literal>mysql</literal> database containing
the grant tables. For distributions that do not do this, you
- should initialize the grant tables manually by running the
+ must initialize the grant tables manually by running the
<command>mysql_install_db</command> script. For details, see
<xref linkend="unix-post-installation"/>.
</para>
@@ -13063,7 +13070,7 @@
<literal>root</literal> user has no password initially. That
is also a security risk, so setting the password for the
<literal>root</literal> accounts is something you should do
- while you are setting up your other MySQL users. For
+ while you're setting up your other MySQL accounts. For
instructions on setting the initial passwords, see
<xref linkend="default-privileges"/>.
</para>
@@ -13125,8 +13132,8 @@
In this case, you must restart the server with the
<option>--skip-grant-tables</option> option and edit your
<filename>/etc/hosts</filename> or
- <filename>\<replaceable>%WINDIR%</replaceable>\SYSTEM32\hosts</filename>
- file to add an entry for your host.
+ <filename>\windows\hosts</filename> file to add an entry for
+ your host.
</para>
</listitem>
@@ -13151,12 +13158,12 @@
Remember that client programs use connection parameters
specified in option files or environment variables. If a
client program seems to be sending incorrect default
- connection parameters when you do not specify them on the
- command line, check your environment and any applicable
+ connection parameters when you have not specified them on
+ the command line, check your environment and any applicable
option files. For example, if you get <literal>Access
denied</literal> when you run a client without any options,
- make sure that you haven't specified an old password in any
- of your option files.
+ make sure that you have not specified an old password in any
+ of your option files!
</para>
<para>
@@ -13188,7 +13195,7 @@
</programlisting>
<para>
- If the preceding error occurs even when you haven't
+ If the preceding error occurs even when you have not
specified a password, it means that you have an incorrect
password listed in some option file. Try the
<option>--no-defaults</option> option as described in the
@@ -13215,13 +13222,13 @@
<literal>UPDATE</literal>, you must encrypt the password
using the <literal>PASSWORD()</literal> function. If you do
not use <literal>PASSWORD()</literal> for these statements,
- the password does not work. For example, the following
+ the password will not work. For example, the following
statement sets a password, but fails to encrypt it, so the
user is not able to connect afterward:
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';
</programlisting>
<para>
@@ -13229,15 +13236,15 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');
</programlisting>
<para>
The <literal>PASSWORD()</literal> function is unnecessary
when you specify a password using the
<literal>GRANT</literal> statement or the
- <command>mysqladmin password</command> command, both of
- which automatically use <literal>PASSWORD()</literal> to
+ <command>mysqladmin password</command> command. Each of
+ those automatically uses <literal>PASSWORD()</literal> to
encrypt the password. See <xref linkend="passwords"/>.
</para>
</listitem>
@@ -13271,14 +13278,14 @@
<para>
If you get an <literal>Access denied</literal> error when
trying to connect to the database with <literal>mysql -u
- user_name</literal>, you may have a problem with the
- <literal>user</literal> table. Check this by executing
- <literal>mysql -u root mysql</literal> and issuing this SQL
- statement:
+ <replaceable>user_name</replaceable></literal>, you may have
+ a problem with the <literal>user</literal> table. Check this
+ by executing <literal>mysql -u root mysql</literal> and
+ issuing this SQL statement:
</para>
<programlisting>
-mysql> <userinput>SELECT * FROM user;</userinput>
+SELECT * FROM user;
</programlisting>
<para>
@@ -13371,7 +13378,7 @@
</para>
<programlisting>
-shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some-hostname</replaceable> ver</userinput>
+shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some_hostname</replaceable> ver</userinput>
Access denied for user 'root'@'' (using password: YES)
</programlisting>
@@ -13389,7 +13396,7 @@
<listitem>
<para>
- Find out what is wrong with your DNS server and fix it.
+ Determine what is wrong with your DNS server and fix it.
</para>
</listitem>
@@ -13403,7 +13410,8 @@
<listitem>
<para>
Put an entry for the client machine name in
- <literal>/etc/hosts</literal>.
+ <filename>/etc/hosts</filename> or
+ <filename>\windows\hosts</filename>.
</para>
</listitem>
@@ -13603,8 +13611,8 @@
and the password; you can also use the
<option>--password=<replaceable>your_pass</replaceable></option>
syntax to specify the password. If you use the
- <option>-p</option> option alone, MySQL prompts you for the
- password.)
+ <option>-p</option> <option>--password</option>option with
+ no password value, MySQL prompts you for the password.)
</para>
</listitem>
@@ -13734,8 +13742,8 @@
</programlisting>
<para>
- Another common example of this occurs when trying to use the
- older PHP <emphasis role="bold">mysql</emphasis> extension after
+ Another common example of this phenomenon occurs for attempts to
+ use the older PHP <literal>mysql</literal> extension after
upgrading to MySQL 4.1 or newer. (See
<xref linkend="php-problems"/>.)
</para>
@@ -13889,13 +13897,13 @@
<para>
Pre-4.1 clients can connect, although because they know
only about the old hashing mechanism, they can
- authenticate only for accounts that have short hashes.
+ authenticate only using accounts that have short hashes.
</para>
</listitem>
<listitem>
<para>
- 4.1 clients can authenticate for accounts that have
+ 4.1 clients can authenticate using accounts that have
short or long hashes.
</para>
</listitem>
@@ -13906,31 +13914,29 @@
</itemizedlist>
<para>
- For short-hash accounts, the authentication process is actually
- a bit more secure for 4.1 clients than for older clients. In
- terms of security, the gradient from least to most secure is:
+ Even for short-hash accounts, the authentication process is
+ actually a bit more secure for 4.1 and later clients than for
+ older clients. In terms of security, the gradient from least to
+ most secure is:
</para>
<itemizedlist>
<listitem>
<para>
- Pre-4.1 client authenticating for account with short
- password hash
+ Pre-4.1 client authenticating with short password hash
</para>
</listitem>
<listitem>
<para>
- 4.1 client authenticating for account with short password
- hash
+ 4.1 client authenticating with short password hash
</para>
</listitem>
<listitem>
<para>
- 4.1 client authenticating for account with long password
- hash
+ 4.1 client authenticating with long password hash
</para>
</listitem>
@@ -14046,7 +14052,8 @@
</para>
<para>
- The following scenarios are possible for running a 4.1 server:
+ The following scenarios are possible for running a 4.1 or
+ laterserver:
</para>
<para>
@@ -14109,15 +14116,15 @@
<listitem>
<para>
- 4.1 clients can authenticate for accounts that have short or
- long hashes.
+ 4.1 and later clients can authenticate using accounts that
+ have short or long hashes.
</para>
</listitem>
<listitem>
<para>
- Pre-4.1 clients can authenticate only for accounts that have
- short hashes.
+ Pre-4.1 clients can authenticate only using accounts that
+ have short hashes.
</para>
</listitem>
@@ -14152,7 +14159,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');
</programlisting>
<para>
@@ -14161,7 +14168,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');
</programlisting>
<para>
@@ -14285,7 +14292,7 @@
<para>
PHP programmers migrating their MySQL databases from version
4.0 or lower to version 4.1 or higher should see
- <xref linkend="old-client"/>.
+ <xref linkend="php"/>.
</para>
</section>
@@ -17879,8 +17886,8 @@
<para>
Because we have not had any unexpectedly crashed tables
(tables that become corrupted for reasons other than hardware
- trouble) for several years, once a week is more than
- sufficient for us.
+ trouble) for a couple of years (this is really true), once a
+ week is more than enough for us.
</para>
<para>
Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml 2006-01-28 23:46:47 UTC (rev 1090)
+++ trunk/refman-5.0/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
@@ -5194,6 +5194,13 @@
battery-backed cache, which makes synchronization very
fast).
</para>
+
+ <para>
+ If the value of <literal>sync_binlog</literal> is 0 (the
+ default), no extra flushing is done. The server relies on
+ the operating system to flush the file contents
+ occasionaly as for any other file.
+ </para>
</listitem>
<listitem>
@@ -7330,7 +7337,7 @@
<para>
The number of key blocks in the key cache that have
- changed but haven't yet been flushed to disk.
+ changed but have not yet been flushed to disk.
</para>
</listitem>
@@ -12206,7 +12213,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';</userinput>
+GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';
</programlisting>
<para>
@@ -13387,7 +13394,7 @@
</para>
<programlisting>
-mysql> <userinput>SHOW GRANTS FOR 'bob'@'pc84.example.com';</userinput>
+SHOW GRANTS FOR 'bob'@'pc84.example.com';
</programlisting>
<para>
@@ -14218,8 +14225,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT ALL PRIVILEGES ON db.*</userinput>
- -> <userinput>TO david@'192.58.197.0/255.255.255.0';</userinput>
+GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';
</programlisting>
<para>
@@ -15047,9 +15053,9 @@
<title>&title-privilege-changes;</title>
<para>
- When <command>mysqld</command> starts, all grant table contents
- are read into memory and become effective for access control at
- that point.
+ When <command>mysqld</command> starts, it reads all grant table
+ contents into memory. The in-memory tables become effective for
+ access control at that point.
</para>
<para>
@@ -15084,10 +15090,11 @@
</itemizedlist>
<para>
- If you modify the grant tables using <literal>GRANT</literal>,
- <literal>REVOKE</literal>, or <literal>SET PASSWORD</literal>,
- the server notices these changes and reloads the grant tables
- into memory again immediately.
+ If you modify the grant tables indirectly using statements such
+ as <literal>GRANT</literal>, <literal>REVOKE</literal>, or
+ <literal>SET PASSWORD</literal>, the server notices these
+ changes and loads the grant tables into memory again
+ immediately.
</para>
<para>
@@ -15148,12 +15155,12 @@
<para>
It might also be that the server is running, but you are
trying to connect using a TCP/IP port, named pipe, or Unix
- socket file different from those on which the server is
+ socket file different from the one on which the server is
listening. To correct this when you invoke a client program,
specify a <option>--port</option> option to indicate the
- proper port, or a <option>--socket</option> option to
+ proper port number, or a <option>--socket</option> option to
indicate the proper named pipe or Unix socket file. To find
- out where the socket file is, you can do:
+ out where the socket file is, you can use this command:
</para>
<programlisting>
@@ -15169,7 +15176,7 @@
distributions on Linux), the installation process
initializes the <literal>mysql</literal> database containing
the grant tables. For distributions that do not do this, you
- should initialize the grant tables manually by running the
+ must initialize the grant tables manually by running the
<command>mysql_install_db</command> script. For details, see
<xref linkend="unix-post-installation"/>.
</para>
@@ -15212,7 +15219,7 @@
<literal>root</literal> user has no password initially. That
is also a security risk, so setting the password for the
<literal>root</literal> accounts is something you should do
- while you're setting up your other MySQL users. For
+ while you're setting up your other MySQL accounts. For
instructions on setting the initial passwords, see
<xref linkend="default-privileges"/>.
</para>
@@ -15273,7 +15280,7 @@
<para>
In this case, you must restart the server with the
<option>--skip-grant-tables</option> option and edit your
- <filename>/etc/hosts</filename> or
+ <filename>/etc/hosts</filename> file or
<filename>\windows\hosts</filename> file to add an entry for
your host.
</para>
@@ -15300,11 +15307,11 @@
Remember that client programs use connection parameters
specified in option files or environment variables. If a
client program seems to be sending incorrect default
- connection parameters when you don't specify them on the
- command line, check your environment and any applicable
+ connection parameters when you have not specified them on
+ the command line, check your environment and any applicable
option files. For example, if you get <literal>Access
denied</literal> when you run a client without any options,
- make sure that you haven't specified an old password in any
+ make sure that you have not specified an old password in any
of your option files!
</para>
@@ -15337,7 +15344,7 @@
</programlisting>
<para>
- If the preceding error occurs even when you haven't
+ If the preceding error occurs even when you have not
specified a password, it means that you have an incorrect
password listed in some option file. Try the
<option>--no-defaults</option> option as described in the
@@ -15364,13 +15371,13 @@
<literal>UPDATE</literal>, you must encrypt the password
using the <literal>PASSWORD()</literal> function. If you do
not use <literal>PASSWORD()</literal> for these statements,
- the password does not work. For example, the following
+ the password will not work. For example, the following
statement sets a password, but fails to encrypt it, so the
user is not able to connect afterward:
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';
</programlisting>
<para>
@@ -15378,7 +15385,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');
</programlisting>
<para>
@@ -15386,8 +15393,8 @@
when you specify a password using the
<literal>GRANT</literal> or (beginning with MySQL 5.0.2)
<literal>CREATE USER</literal> statements, or the
- <command>mysqladmin password</command> command, all of which
- automatically use <literal>PASSWORD()</literal> to encrypt
+ <command>mysqladmin password</command> command. Each of those
+ automatically uses <literal>PASSWORD()</literal> to encrypt
the password. See <xref linkend="passwords"/>, and
<xref linkend="create-user"/>.
</para>
@@ -15417,14 +15424,14 @@
<para>
If you get an <literal>Access denied</literal> error when
trying to connect to the database with <literal>mysql -u
- user_name</literal>, you may have a problem with the
- <literal>user</literal> table. Check this by executing
- <literal>mysql -u root mysql</literal> and issuing this SQL
- statement:
+ <replaceable>user_name</replaceable></literal>, you may have
+ a problem with the <literal>user</literal> table. Check this
+ by executing <literal>mysql -u root mysql</literal> and
+ issuing this SQL statement:
</para>
<programlisting>
-mysql> <userinput>SELECT * FROM user;</userinput>
+SELECT * FROM user;
</programlisting>
<para>
@@ -15509,7 +15516,7 @@
</para>
<programlisting>
-shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some-hostname</replaceable> ver</userinput>
+shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some_hostname</replaceable> ver</userinput>
Access denied for user 'root'@'' (using password: YES)
</programlisting>
@@ -15527,8 +15534,7 @@
<listitem>
<para>
- Try to find out what is wrong with your DNS server and
- fix it.
+ Determine what is wrong with your DNS server and fix it.
</para>
</listitem>
@@ -15542,7 +15548,8 @@
<listitem>
<para>
Put an entry for the client machine name in
- <literal>/etc/hosts</literal>.
+ <filename>/etc/hosts</filename> or
+ <filename>\windows\hosts</filename>.
</para>
</listitem>
@@ -15743,8 +15750,8 @@
and the password; you can also use the
<option>--password=<replaceable>your_pass</replaceable></option>
syntax to specify the password. If you use the
- <option>-p</option> option alone, MySQL prompts you for the
- password.)
+ <option>-p</option> <option>--password</option>option with
+ no password value, MySQL prompts you for the password.)
</para>
</listitem>
@@ -15879,8 +15886,8 @@
</programlisting>
<para>
- Another common example of this occurs when trying to use the
- older PHP <emphasis role="bold">mysql</emphasis> extension after
+ Another common example of this phenomenon occurs for attempts to
+ use the older PHP <literal>mysql</literal> extension after
upgrading to MySQL 4.1 or newer. (See
<xref linkend="php-problems"/>.)
</para>
@@ -16040,14 +16047,14 @@
<para>
Pre-4.1 clients can connect, although because they know
only about the old hashing mechanism, they can
- authenticate only for accounts that have short hashes.
+ authenticate only using accounts that have short hashes.
</para>
</listitem>
<listitem>
<para>
- 4.1 and later clients can authenticate for accounts that
- have short or long hashes.
+ 4.1 and later clients can authenticate using accounts
+ that have short or long hashes.
</para>
</listitem>
@@ -16057,10 +16064,10 @@
</itemizedlist>
<para>
- For short-hash accounts, the authentication process is actually
- a bit more secure for 4.1 and later clients than for older
- clients. In terms of security, the gradient from least to most
- secure is:
+ Even for short-hash accounts, the authentication process is
+ actually a bit more secure for 4.1 and later clients than for
+ older clients. In terms of security, the gradient from least to
+ most secure is:
</para>
<itemizedlist>
@@ -16197,7 +16204,7 @@
<para>
The following scenarios are possible for running a 4.1 or later
- server, including MySQL ¤t-series; servers:
+ server:
</para>
<para>
@@ -16260,16 +16267,15 @@
<listitem>
<para>
- 4.1 and later clients (including ¤t-series; clients)
- can authenticate for accounts that have short or long
- hashes.
+ 4.1 and later clients can authenticate using accounts that
+ have short or long hashes.
</para>
</listitem>
<listitem>
<para>
- Pre-4.1 clients can authenticate only for accounts that have
- short hashes.
+ Pre-4.1 clients can authenticate only using accounts that
+ have short hashes.
</para>
</listitem>
@@ -16304,7 +16310,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');
</programlisting>
<para>
@@ -16313,7 +16319,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');
</programlisting>
<para>
@@ -16438,7 +16444,7 @@
<para>
PHP programmers migrating their MySQL databases from version
4.0 or lower to version 4.1 or higher should see
- <xref linkend="old-client"/>.
+ <xref linkend="php"/>.
</para>
</section>
@@ -20099,10 +20105,10 @@
</para>
<para>
- Because we haven't had any unexpectedly crashed tables (tables
- that become corrupted for reasons other than hardware trouble)
- for a couple of years (this is really true), once a week is
- more than enough for us.
+ Because we have not had any unexpectedly crashed tables
+ (tables that become corrupted for reasons other than hardware
+ trouble) for a couple of years (this is really true), once a
+ week is more than enough for us.
</para>
<para>
Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml 2006-01-28 23:46:47 UTC (rev 1090)
+++ trunk/refman-5.1/database-administration.xml 2006-01-28 23:47:07 UTC (rev 1091)
@@ -5234,6 +5234,13 @@
battery-backed cache, which makes synchronization very
fast).
</para>
+
+ <para>
+ If the value of <literal>sync_binlog</literal> is 0 (the
+ default), no extra flushing is done. The server relies on
+ the operating system to flush the file contents
+ occasionaly as for any other file.
+ </para>
</listitem>
<listitem>
@@ -7399,7 +7406,7 @@
<para>
The number of key blocks in the key cache that have
- changed but haven't yet been flushed to disk.
+ changed but have not yet been flushed to disk.
</para>
</listitem>
@@ -12247,7 +12254,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';</userinput>
+GRANT INSERT(user) ON mysql.user TO '<replaceable>user_name</replaceable>'@'<replaceable>host_name</replaceable>';
</programlisting>
<para>
@@ -13409,7 +13416,7 @@
</para>
<programlisting>
-mysql> <userinput>SHOW GRANTS FOR 'bob'@'pc84.example.com';</userinput>
+SHOW GRANTS FOR 'bob'@'pc84.example.com';
</programlisting>
<para>
@@ -14232,8 +14239,7 @@
</para>
<programlisting>
-mysql> <userinput>GRANT ALL PRIVILEGES ON db.*</userinput>
- -> <userinput>TO david@'192.58.197.0/255.255.255.0';</userinput>
+GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';
</programlisting>
<para>
@@ -15061,9 +15067,9 @@
<title>&title-privilege-changes;</title>
<para>
- When <command>mysqld</command> starts, all grant table contents
- are read into memory and become effective for access control at
- that point.
+ When <command>mysqld</command> starts, it reads all grant table
+ contents into memory. The in-memory tables become effective for
+ access control at that point.
</para>
<para>
@@ -15098,10 +15104,11 @@
</itemizedlist>
<para>
- If you modify the grant tables using <literal>GRANT</literal>,
- <literal>REVOKE</literal>, or <literal>SET PASSWORD</literal>,
- the server notices these changes and reloads the grant tables
- into memory again immediately.
+ If you modify the grant tables indirectly using statements such
+ as <literal>GRANT</literal>, <literal>REVOKE</literal>, or
+ <literal>SET PASSWORD</literal>, the server notices these
+ changes and loads the grant tables into memory again
+ immediately.
</para>
<para>
@@ -15162,12 +15169,12 @@
<para>
It might also be that the server is running, but you are
trying to connect using a TCP/IP port, named pipe, or Unix
- socket file different from those on which the server is
+ socket file different from the one on which the server is
listening. To correct this when you invoke a client program,
specify a <option>--port</option> option to indicate the
- proper port, or a <option>--socket</option> option to
+ proper port number, or a <option>--socket</option> option to
indicate the proper named pipe or Unix socket file. To find
- out where the socket file is, you can do:
+ out where the socket file is, you can use this command:
</para>
<programlisting>
@@ -15183,7 +15190,7 @@
distributions on Linux), the installation process
initializes the <literal>mysql</literal> database containing
the grant tables. For distributions that do not do this, you
- should initialize the grant tables manually by running the
+ must initialize the grant tables manually by running the
<command>mysql_install_db</command> script. For details, see
<xref linkend="unix-post-installation"/>.
</para>
@@ -15226,7 +15233,7 @@
<literal>root</literal> user has no password initially. That
is also a security risk, so setting the password for the
<literal>root</literal> accounts is something you should do
- while you're setting up your other MySQL users. For
+ while you're setting up your other MySQL accounts. For
instructions on setting the initial passwords, see
<xref linkend="default-privileges"/>.
</para>
@@ -15287,7 +15294,7 @@
<para>
In this case, you must restart the server with the
<option>--skip-grant-tables</option> option and edit your
- <filename>/etc/hosts</filename> or
+ <filename>/etc/hosts</filename> file or
<filename>\windows\hosts</filename> file to add an entry for
your host.
</para>
@@ -15314,11 +15321,11 @@
Remember that client programs use connection parameters
specified in option files or environment variables. If a
client program seems to be sending incorrect default
- connection parameters when you don't specify them on the
- command line, check your environment and any applicable
+ connection parameters when you have not specified them on
+ the command line, check your environment and any applicable
option files. For example, if you get <literal>Access
denied</literal> when you run a client without any options,
- make sure that you haven't specified an old password in any
+ make sure that you have not specified an old password in any
of your option files!
</para>
@@ -15351,7 +15358,7 @@
</programlisting>
<para>
- If the preceding error occurs even when you haven't
+ If the preceding error occurs even when you have not
specified a password, it means that you have an incorrect
password listed in some option file. Try the
<option>--no-defaults</option> option as described in the
@@ -15378,13 +15385,13 @@
<literal>UPDATE</literal>, you must encrypt the password
using the <literal>PASSWORD()</literal> function. If you do
not use <literal>PASSWORD()</literal> for these statements,
- the password does not work. For example, the following
+ the password will not work. For example, the following
statement sets a password, but fails to encrypt it, so the
user is not able to connect afterward:
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = 'eagle';
</programlisting>
<para>
@@ -15392,7 +15399,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');</userinput>
+SET PASSWORD FOR 'abe'@'<replaceable>host_name</replaceable>' = PASSWORD('eagle');
</programlisting>
<para>
@@ -15400,7 +15407,7 @@
when you specify a password using the
<literal>GRANT</literal> or <literal>CREATE USER</literal>
statements, or the <command>mysqladmin password</command>
- command, all of which automatically use
+ command. Each of those automatically uses
<literal>PASSWORD()</literal> to encrypt the password. See
<xref linkend="passwords"/>, and
<xref linkend="create-user"/>.
@@ -15431,14 +15438,14 @@
<para>
If you get an <literal>Access denied</literal> error when
trying to connect to the database with <literal>mysql -u
- user_name</literal>, you may have a problem with the
- <literal>user</literal> table. Check this by executing
- <literal>mysql -u root mysql</literal> and issuing this SQL
- statement:
+ <replaceable>user_name</replaceable></literal>, you may have
+ a problem with the <literal>user</literal> table. Check this
+ by executing <literal>mysql -u root mysql</literal> and
+ issuing this SQL statement:
</para>
<programlisting>
-mysql> <userinput>SELECT * FROM user;</userinput>
+SELECT * FROM user;
</programlisting>
<para>
@@ -15523,7 +15530,7 @@
</para>
<programlisting>
-shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some-hostname</replaceable> ver</userinput>
+shell> <userinput>mysqladmin -u root -p<replaceable>xxxx</replaceable> -h <replaceable>some_hostname</replaceable> ver</userinput>
Access denied for user 'root'@'' (using password: YES)
</programlisting>
@@ -15541,8 +15548,7 @@
<listitem>
<para>
- Try to find out what is wrong with your DNS server and
- fix it.
+ Determine what is wrong with your DNS server and fix it.
</para>
</listitem>
@@ -15556,7 +15562,8 @@
<listitem>
<para>
Put an entry for the client machine name in
- <literal>/etc/hosts</literal>.
+ <filename>/etc/hosts</filename> or
+ <filename>\windows\hosts</filename>.
</para>
</listitem>
@@ -15757,8 +15764,8 @@
and the password; you can also use the
<option>--password=<replaceable>your_pass</replaceable></option>
syntax to specify the password. If you use the
- <option>-p</option> option alone, MySQL prompts you for the
- password.)
+ <option>-p</option> <option>--password</option>option with
+ no password value, MySQL prompts you for the password.)
</para>
</listitem>
@@ -15893,8 +15900,8 @@
</programlisting>
<para>
- Another common example of this occurs when trying to use the
- older PHP <emphasis role="bold">mysql</emphasis> extension after
+ Another common example of this phenomenon occurs for attempts to
+ use the older PHP <literal>mysql</literal> extension after
upgrading to MySQL 4.1 or newer. (See
<xref linkend="php-problems"/>.)
</para>
@@ -16054,14 +16061,14 @@
<para>
Pre-4.1 clients can connect, although because they know
only about the old hashing mechanism, they can
- authenticate only for accounts that have short hashes.
+ authenticate only using accounts that have short hashes.
</para>
</listitem>
<listitem>
<para>
- 4.1 and later clients can authenticate for accounts that
- have short or long hashes.
+ 4.1 and later clients can authenticate using accounts
+ that have short or long hashes.
</para>
</listitem>
@@ -16071,10 +16078,10 @@
</itemizedlist>
<para>
- For short-hash accounts, the authentication process is actually
- a bit more secure for 4.1 and later clients than for older
- clients. In terms of security, the gradient from least to most
- secure is:
+ Even for short-hash accounts, the authentication process is
+ actually a bit more secure for 4.1 and later clients than for
+ older clients. In terms of security, the gradient from least to
+ most secure is:
</para>
<itemizedlist>
@@ -16211,7 +16218,7 @@
<para>
The following scenarios are possible for running a 4.1 or later
- server, including MySQL ¤t-series; servers:
+ server:
</para>
<para>
@@ -16274,16 +16281,15 @@
<listitem>
<para>
- 4.1 and later clients (including ¤t-series; clients)
- can authenticate for accounts that have short or long
- hashes.
+ 4.1 and later clients can authenticate using accounts that
+ have short or long hashes.
</para>
</listitem>
<listitem>
<para>
- Pre-4.1 clients can authenticate only for accounts that have
- short hashes.
+ Pre-4.1 clients can authenticate only using accounts that
+ have short hashes.
</para>
</listitem>
@@ -16318,7 +16324,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = PASSWORD('mypass');
</programlisting>
<para>
@@ -16327,7 +16333,7 @@
</para>
<programlisting>
-mysql> <userinput>SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');</userinput>
+SET PASSWORD FOR '<replaceable>some_user</replaceable>'@'<replaceable>some_host</replaceable>' = OLD_PASSWORD('mypass');
</programlisting>
<para>
@@ -16452,7 +16458,7 @@
<para>
PHP programmers migrating their MySQL databases from version
4.0 or lower to version 4.1 or higher should see
- <xref linkend="old-client"/>.
+ <xref linkend="php"/>.
</para>
</section>
@@ -20108,10 +20114,10 @@
</para>
<para>
- Because we haven't had any unexpectedly crashed tables (tables
- that become corrupted for reasons other than hardware trouble)
- for a couple of years (this is really true), once a week is
- more than enough for us.
+ Because we have not had any unexpectedly crashed tables
+ (tables that become corrupted for reasons other than hardware
+ trouble) for a couple of years (this is really true), once a
+ week is more than enough for us.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1091 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 29 Jan |
