mysql|数据|数据目录    10 . 2节讨论了在其缺省配置中的数据目录的结构。所有数据库和状态文件都包含在其中。但是，在确定数据目录内容的布局中管理员有某些职责。本节讨论为什么要移动数据目录的各个部分（甚至是字典本身）、可以移动什么，以及怎样进行这些移动。
    MySQL允许您重定位其中的数据目录或元素。这样做有几个原因：
    可以用比缺省定位的文件系统更大的容量在文件系统中放置数据目录。
    如果数据目录在繁忙的磁盘上，可以将其放置到较少使用的驱动器上，以平衡物理设备之间的磁盘活动。为了类似的原因，可以将数据库和日志文件放在不同的驱动器上，或在驱动器之间对数据库进行再分布。
    您可以运行多个服务器，并且每个服务器都有属于自己的数据目录。这是一种解决总进程文件描述符限制问题的方法，尤其是当不能重新配置系统的核心以得到更高的限制值时。
    某些系统将PID 文件保存在诸如/var/run 的目录中。为了系统运作的一致性，您可以将MySQLPID 文件也放在那里。

重定位方法

    有两种对数据目录重定位的方法：
    可以在命令行或在一个选项文件的[mysqld] 组上，在服务器启动时间指定一个选项。
    可以移动要重定位的内容，然后在原始的位置中做一个指向新位置的s y m l i n k （symbolic link，符号链接）。
    两种方法的任何一种都不能为您进行全部的重定位工作。表10-4 综合了可重定位的内容以及可用于重定位的方法。如果您使用一个选项文件，可以指定在全局选项文件/ e t c / my.cnf（Windows中的c:\my.cnf）中的选项。当前的Windows 版本还访问系统目录（c:\windows 或c:\N T）。
    您还可以使用缺省数据目录的选项文件my.cnf（该目录编译在服务器中）。笔者不建议使用此文件。如果要重定位数据目录本身，必须保持缺省数据目录的完整性，以便在数据目录中放置一个选项文件，该文件将说明服务器应该在哪里找到“真正”的数据目录！真乱。如果想要用一个选项文件来指定服务器的选项，则最好使用/ e t c / my.cnf。


估计重定位的效果

    在试图对任何东西进行重定位之前，检验该操作是否将具有所期望的效果是一个好主意。笔者倾向于用d u、df 和ls -l 命令来获得磁盘空间信息，但是所有的命令都依赖于对文件系统布局的正确理解。
    以下例子将显示出一个神秘的中断以密切注意何时估计数据目录的重定位。假定数据目录是/ us r / l o c a l / v a r，并且想将其移动到/ v a r / mysql，因为df 指出该/var 文件系统有较多的可用空间（如下例所示）：

    重定位的数据目录能释放/usr 文件系统中多少空间？为了查找空间数量，可使用du-s 来查看该目录使用了多少空间：

    这大约为13 0 MB，应该对/usr 产生相当大的变化。但这是真的吗？可在该数据目录/ us r 中试一下df 命令：

    真奇怪。我们请求的是包含/usr/local/var 系统文件的可用空间，可为什么df 报告了v a r 的空间呢？下面的ls -l 做出了回答：

    该输出结果表明/usr/local/var 是对/var/mysql的一个s y m l i n k。换句话说，数据目录已经被重定位到/var 文件系统中，并且用指向/var 文件系统的symlink 所取代。有关通过移动数据目录到/var 中来释放大量的/usr 空间的工作就到此为止了！
    教训：花几分钟的时间估计重定位的效果是一个有价值的投资。不用花很长的时间就会发现您可能不能达到自己的预期目标，这样可以使您避免浪费大量的移动数据目录的时间。

重定位数据目录

    为了重定位数据目录，应关闭服务器，将数据目录移动到新的位置。然后应该或者删除原来的数据目录并用指向新位置的symlink 来代替它，或者使用直接指明新位置的一个选项来重新启动服务器。表10 - 5列出了指定该位置的命令行和选项文件的语法。


重定位数据库

    数据库只能通过symlink 方法来移动。为了重定位数据库，应关闭服务器，移动数据库目录。删除原来的数据库目录，用指向新位置的symlink 来代替它，然后启动服务器。
    下面的例子说明怎样将数据库bigdb 移动到另一个位置：

    重定位的预防措施
    在执行任何重定位操作之前应该关闭服务器，然后再重新启动它。对有些类型的重定位（如移动数据库目录），保持服务器的运行状态是可能的（尽管不建议这样做）。如果要这样做，您必须确保服务器没有访问将要移动的数据库。还应该确保在移动数据库之前发布了FLUSH TABLE 语句，以便确保服务器关闭所有打开的表文件。不履行这些预防措施可能导致表的毁坏。
    应该以数据目录所有者的身份来执行这些命令。为了安全起见，将原来的数据库目录重新命名为b i g db . o r i g。在验证了服务器与重定位服务器正常工作之后，可以删除原来的目录：
    % rm -rf bigdb.orig

重定位数据库表

    对单个的表进行重定位不是好主意。可以通过将表的文件移动到另一个位置并在该数据库目录中创建指向这些文件的symlink 来进行。但是，如果曾经发布过ALTER TABLE 或OPTIMIZE TABLE 语句，则所做的这些修改将被取消。
    每个语句通过在数据库目录中创建一个实现变更和最优化的临时表进行操作，然后删除原来的表，将该临时表重新命名为原来的名称。其结果是： symlink 被删除，新的表回到数据库目录中，该目录是您移动表之前的原始表所在位置。因此，移出该数据库目录的旧的表文件仍然在原位置上─您甚至已经不记得它们的存在，但它们仍然占用着空间。同样，symlink 已经消失，因此，当您意识到所发生的一切时，如果已经不记得是在哪里移动的，将没有任何好办法去捕捉这些文件。
    要想确保访问该表的任何人都不更改或优化该表是困难的（因而撤消任何企图的重定位），因此最好保留该数据库目录中的这些表。

重定位状态文件

    可以用启动选项重定位PID 文件、常规日志和更新日志。错误日志由safe_mysqld 创建且不能够重定位（除非编辑s a f e _ mysqld）
    为了在另一个位置写状态文件，应关闭服务器，然后用指定新状态文件位置的恰当选项重新启动它。表10 - 6列出了每个文件的命令行和选项的语法。
    删除一个重定位的数据库
    您可以用DROP DATABASE 语句删除一个数据库，但是旧版本的MySQL在删除已经重定位的数据库时是有难度的。该数据库中的表被正确地删除了，但在服务器试图删除该数据库目录时会出现错误，这是由于该目录是一个symlink 而不是真正的目录。MySQL管理员必须手工删除该数据库目录和指向它的s y m l i n k。自MySQL3.23 以来，这个问题已经得到解决。

    如果以绝对路径名指定一个状态文件的名称，则用该路径名创建该文件。否则，该文件在该数据目录下创建。例如，如果您指定- -
pid - file = /var/run/mysqld.pid，则该PID 文件为/ v a r / r un / mysqld . p i d。如果您指定-- pid - file = mysqld.pid ，则该PID 文件为DATA D I R/ mysqld . p i d。
    如果指定一个没有带扩展名的更新日志，则MySQL在打开该更新日志时将生成顺序的名字。这些名字用. n n n 扩展名创建，这里的.n n n是未被已有的更新日志文件使用过的第一个号码（如， up date . 0 0 1、up date . 0 0 2等等）。可以通过指定包含明确的扩展名来忽略顺序名字的生成，然后服务器将仅使用您指定的这个名字。