|
 |
|
| |
7.6.1.2. Using Symbolic Links for Tables on Unix
You should not symlink tables on systems that do not have a
fully operational realpath() call. (Linux
and Solaris support realpath()). You can
check whether your system supports symbolic links by issuing a
SHOW VARIABLES LIKE 'have_symlink'
statement.
Symlinks are fully supported only for
MyISAM tables. For files used by tables for
other storage engines, you may get strange problems if you try
to use symbolic links.
The handling of symbolic links for MyISAM
tables works as follows:
In the data directory, you always have the table format
(.frm) file, the data
(.MYD) file, and the index
(.MYI) file. The data file and index
file can be moved elsewhere and replaced in the data
directory by symlinks. The format file cannot.
You can symlink the data file and the index file
independently to different directories.
You can instruct a running MySQL server to perform the
symlinking by using the DATA DIRECTORY
and INDEX DIRECTORY options to
CREATE TABLE. See
Section 13.1.5, “CREATE TABLE Syntax”. Alternatively, symlinking
can be accomplished manually from the command line using
ln -s if mysqld is
not running.
myisamchk does not replace a symlink
with the data file or index file. It works directly on the
file to which the symlink points. Any temporary files are
created in the directory where the data file or index file
is located.
Note: When you drop a
table that is using symlinks, both the symlink
and the file to which the symlink points are
dropped. This is an extremely good reason why
you should not run
mysqld as the system
root or allow system users to have
write access to MySQL database directories.
If you rename a table with ALTER TABLE ...
RENAME and you do not move the table to another
database, the symlinks in the database directory are
renamed to the new names and the data file and index file
are renamed accordingly.
If you use ALTER TABLE ... RENAME to
move a table to another database, the table is moved to
the other database directory. The old symlinks and the
files to which they pointed are deleted. In other words,
the new table is not symlinked.
If you are not using symlinks, you should use the
--skip-symbolic-links option to
mysqld to ensure that no one can use
mysqld to drop or rename a file outside
of the data directory.
Table symlink operations that are not yet supported:
ALTER TABLE ignores the DATA
DIRECTORY and INDEX DIRECTORY
table options.
BACKUP TABLE and RESTORE
TABLE do not respect symbolic links.
-
The .frm file must
never be a symbolic link (as
indicated previously, only the data and index files can be
symbolic links). Attempting to do this (for example, to
make synonyms) produces incorrect results. Suppose that
you have a database db1 under the MySQL
data directory, a table tbl1 in this
database, and in the db1 directory you
make a symlink tbl2 that points to
tbl1:
shell> cd /path/to/datadir/db1
shell> ln -s tbl1.frm tbl2.frm
shell> ln -s tbl1.MYD tbl2.MYD
shell> ln -s tbl1.MYI tbl2.MYI
Problems result if one thread reads
db1.tbl1 and another thread updates
db1.tbl2:
The query cache is “fooled” (it has no
way of knowing that tbl1 has not
been updated, so it returns outdated results).
ALTER statements on
tbl2 also fail.
|
|
|
