[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Before MySQL 4.0 you should not symlink tables unless you are
very careful with them. The problem is that if you run ALTER
TABLE
, REPAIR TABLE
, or OPTIMIZE TABLE
on a symlinked
table, the symlinks will be removed and replaced by the original
files. This happens because these statements work by creating a
temporary file in the database directory and replacing the original
file with the temporary file when the statement operation is complete.
You should not symlink tables on systems that don't have a fully
working realpath()
call. (At least Linux and Solaris support
realpath()
). You can check if your system supports symbolic links
by doing SHOW VARIABLES LIKE 'have_symlink'
.
In MySQL 4.0, symlinks are fully supported only for MyISAM
tables. For other table types, you will probably get strange problems
if you try to use symbolic links on files in the operating system with
any of the above commands.
The handling of symbolic links for MyISAM
tables in MySQL 4.0 works
the following way:
mysqld
is
not running) or with SQL by using the DATA DIRECTORY
and INDEX
DIRECTORY
options to CREATE TABLE
.
See section CREATE TABLE
.
myisamchk
will not replace a symlink with the datafile or index file.
It works directly on the file a symlink points to. Any temporary files
will be created in the same directory where the datafile or index file is
located.
mysqld
as root
or allow
persons to have write access to the MySQL database directories.
ALTER TABLE RENAME
and you don't move
the table to another database, the symlinks in the database directory
are renamed to the new names and the datafile and index file are
renamed accordingly.
ALTER TABLE RENAME
to move a table to another database,
the table is moved to the other database directory and the old
symlinks and the files to which they pointed are deleted. (In other words,
the new table will not be symlinked.)
--skip-symlink
option to mysqld
to ensure that no one can use mysqld
to drop
or rename a file outside of the data directory.
SHOW CREATE TABLE
doesn't report if the table has symbolic links
prior to MySQL 4.0.15. This is also true for mysqldump
, which uses
SHOW CREATE TABLE
to generate CREATE TABLE
statements.
Things that are not yet supported:
ALTER TABLE
ignores the DATA DIRECTORY
and INDEX
DIRECTORY
table options.
BACKUP TABLE
and RESTORE TABLE
don't respect symbolic
links.
frm
file must never be a symbolic link (as said
previously, only the data and index files can be symbolic links).
Doing this (for example to make synonyms), will produce incorrect
results.
Suppose 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 |
Now if one thread reads db1.tbl1
and another thread updates
db1.tbl2
, there will be problems: the query cache will be fooled
(it will believe tbl1
has not been updated so will return
out-of-date results), the ALTER
commands on tbl2
will also
fail.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |