Oracle 5.0, Справочное руководство

Страница: 610 / 3232

When Privilege Changes Take Effect
590
| %.your.domain | % | ... (all privileges set to 'Y')
+--------------------+----+-
6.2.6. When Privilege Changes Take Effect
When
mysqld
starts, it reads all grant table contents into memory. The in-memory tables become
effective for access control at that point.
If you modify the grant tables indirectly using account-management statements such as
GRANT
,
REVOKE
, or
SET PASSWORD
, the server notices these changes and loads the grant tables into memory
again immediately.
If you modify the grant tables directly using statements such as
INSERT
,
UPDATE
, or
DELETE
, your
changes have no effect on privilege checking until you either restart the server or tell it to reload the
tables. If you change the grant tables directly but forget to reload them, your changes have no effect
until you restart the server. This may leave you wondering why your changes do not seem to make any
difference!
To tell the server to reload the grant tables, perform a flush-privileges operation. This can be done by
issuing a
FLUSH PRIVILEGES
statement or by executing a
mysqladmin flush-privileges
or
mysqladmin reload
command.
When the server reloads the grant tables, privileges for each existing client connection are affected as
follows:
• Table and column privilege changes take effect with the client's next request.
• Database privilege changes take effect the next time the client executes a
USE db_name
statement.
Note
Client applications may cache the database name; thus, this effect may not
be visible to them without actually changing to a different database or flushing
the privileges.
• Global privileges and passwords are unaffected for a connected client. These changes take effect
only for subsequent connections.
If the server is started with the
--skip-grant-tables
[420] option, it does not read the grant tables
or implement any access control. Anyone can connect and do anything. To cause a server thus started
to read the tables and enable access checking, flush the privileges.
6.2.7. Causes of Access-Denied Errors
If you encounter problems when you try to connect to the MySQL server, the following items describe
some courses of action you can take to correct the problem.
• Make sure that the server is running. If it is not, clients cannot connect to it. For example, if an
attempt to connect to the server fails with a message such as one of those following, one cause
might be that the server is not running:
shell> mysql
ERROR 2003: Can't connect to MySQL server on ' host_name ' (111)
shell> mysql
ERROR 2002: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111)
• It might 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 the one on which the server is listening. To correct this when you
invoke a client program, specify a
--port
[231] option to indicate the proper port number, or a
--
socket
[232] option to indicate the proper named pipe or Unix socket file. To find out where the
socket file is, you can use this command:
shell> netstat -ln | grep mysql