(mysql.info) symbolic-links-to-tables

(mysql.info) symbolic-links-to-databases
(mysql.info) windows-symbolic-links
 
 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  create-table. 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.
 
    * * 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.
Info Catalog
(mysql.info) symbolic-links-to-databases
(mysql.info) symbolic-links
(mysql.info) windows-symbolic-links
automatically generated byinfo2html