MySQL数据目录结构

keaide

% chmod 700 DATADIR
以拥有数据目录的Unix用户运行此命令。确保服务器也以此用户运行，否则该命令不仅将其它人拒之门外，它也阻止服务器访问你的数据库。
状态文件出现在数据目录的顶级目录，就象数据库目录，所以你可能担心这些文件名是否与数据库名冲突或出错（如在服务器执行SHOW DATABASES语句时）。答案是不。状态和日志文件信息存储在文件中，而数据库是目录，所以可执行程序能用一个简单的stat()调用区分它们。如果你看一下数据目录，你可以区分状态文件和数据库目录，用ls -l并检查模式的第一个字符是一个"_"还是一个"d"。
你也可以简单地看一下名字，所有状态文件名包含一个点("."，而数据库目录没有（.在数据库名中是无效字符）。

keaide

3 重定位数据库目录

前面讨论的数据目录结构是缺省配置，所有数据库和状态文件均包含其中，然而，你有某些自由决定数据目录内容的位置，本节讨论为什么你可能移走部分数据目录（或甚至目录本身）、你能移走什么以及你如何做这些改变。
MySQL允许你重定位数据目录或其中的成员，由几个原因你为什么要这样做：
你能将数据目录放在你缺省所在的文件系统更大容量的文件系统上。
如果你的数据目录在一个繁忙的硬盘上，你可能把它放在不太忙的磁盘上以均衡磁盘活动。你可以把数据库和日志文件放在分开的磁盘上或跨磁盘分布。
你可能想运行多个服务器，各自有自己的数据目录，这是解决每个进程文件描述符限制问题的一种方法，特别是你不能重新配置内核以允许更高的限制。
有些系统在例如/var/run中保存服务器的部分文件，你可能想把MySQL的PID文件也放在那儿，为了系统操作的一致性。

3.1 重定位方法

有两种方法重定位数据目录的内容：
你可以在服务器启动时指定选项，在命令行或在一个选项文件的[mysqld]中。
你可以移走要重定位的东西，然后在原位置做一个指向新位置的符号连接。

两种方法都不能解决你能重定位的一切，下表总结了什么能重定位和用哪种方法重定位。如果你使用选项文件，有可能在全局选项文件/etc/my.cnf（Windows上的c:\my.cnf）指定选项。当前的Windows版本也寻找系统目录（c:\Windows或c:\NT）。表 重定位方法
重定位方法 适用的重定位方法
整个数据目录 启动选项或符号连接
单个数据库目录 符号连接
单个数据库表 符号连接
PID文件 启动选项
一般日志 启动选项
更新日志 启动选项

你也可以使用缺省数据目录中的选项文件my.cnf，但不推荐使用该文件。如果你想重定位数据目录本身，你不得不让缺省数据目录可读以便使你能在这里放置选项文件指定服务器应该在哪里找到“真正”的数据目录！这很混乱。如果你想使用一个选项文件指定服务器选项，最好使用/etc/my.cnf。

keaide

3.1 检验重定位的效果

在试图重定位任何东西之前，检验操作达到预期效果是个好主意。借助于du、df和ls -l命令获得磁盘空间的信息，但这些依赖于你正确了解你的文件系统的布局。
下面演示一个在你检验一个属目录重定位时的设计陷阱。假定你的数据目录是/usr/local/var，而你想把它移到/var/mysql，因为df显示/var文件系统有很多的空闲空间：

%df /usr /varFilesystem  1k-blocks     Used   Avail  Capacity  Mounted on/dev/wd0s3e    396895   292126   73018    80%     /usr/dev/wd0s3f   1189359  1111924  162287    15%     /var 　

重定位的数据目录在/usr文件系统上有多少空闲空间呢？要知道它，使用du -s找出该目录使用多少空间。
%cd /usr/local/var%du -s .133426

这大约是130MB，真实这样吗？在数据目录下试一下df：
%df /usr/local/varFilesystem  1k-blocks     Used   Avail  Capacity  Mounted on/dev/wd0s3f   1189359  1111924  162287    15%     /var　

这就奇怪了。如果我们为包含/usr/local/var的文件系统申请空闲空间，为什么却报告var上的空间呢？这里ls -l提供了答案：
%ls -l /usr/local....lrwxrwxrwx  1  root  wheel  10 Dec 11 23:33 var -> /var/mysql....　

keaide

输出显示/usr/local/var是对/var/mysql的符号连接，换句话说，数据目录已经被重定位于/var文件系统，并用一个指向那里的符号连接代替。通过将数据目录移到/var竟然释放了/usr上那么多空间！

3.2 重定位数据目录

要重定位数据目录，关闭服务器并把数据目录移到新位置上，然后你应该删除员数据目录并用指向新位置的符号连接代替它，或用明确指出新位置的选项重启服务器。下表列出指定位置的命令行和选项。表 数据目录重定位语法
选项源 语法
命令行 --data-dir=/path/to/dir
选项文件 [mysqld]
datadir=/path/to/dir

3.3 重定位数据库

数据库能通过符号连接的方法移走。要重定位一个数据库，关闭服务器并移走数据库目录并删除原来的数据库目录，用指向新位置的符号连接代替它，然后重启服务器。
下例显示你如何将一个数据库bigdb移到一个不同的地方：

keaide

%mysqladmin -u root -p shutdownEnter password: ******%cd DATADIR%tar cf - bigdb | (cd /var/db; tar xf -)%mv bigdb bigdb.origln -s /var/db/bigdb .%safe_mysqld　

你应该以该数据目录的拥有者执行这些命令。为了安全起见，原数据库目录改名为bigdb.orig。在你验证了服务器工作正常后，你可以删除原数据目录。
%rm -rf bigdb.orig

3.4 重定位数据库表

重定位一个单独的表不是个好主意。你可以通过把表文件移到一个不同地方，并在数据目录中创建指向这些文件的符号连接进行。然而，如果你发出一条ALTER TABLE或OPTIMIZE TABLE语句，将不进行你的修改。
每个语句通过在数据库目录中创建一个实现你修改或优化的临时表，然后删除原来的表并将临时表更名为原来的表来完成，结果是你的符号连接被删除，而且新表又回到数据库目录，这是你移走前的原表文件位置。更糟糕的是，你还没有意识到它们在那儿，继续占据着空间，而且符号连接已经被破坏，这样以后当你意识到发生的事情时，如果你忘记你把它们移到什么地方，你可能没有好办法追踪文件了。
因为很难保证具有表访问权的人不修改或优化表，所以最好把表留在数据库目录中。

keaide

3.5 重定位状态文件

你可以重中定位PID文件、一般日志和更新日志。出错日志由safe_mysqld用启动选项创建，而不能被重定位（除非你编辑safe_mysqld）。
要在一个不同位置写入状态文件，关闭服务器，然后由指定新状态文件位置的适当选项启动它。下表列出每一个文件的命令行和选项文件的语法。表 状态文件重定位语法
选项源 语法
命令行 --pid-file=pidfile
--log=lodfile
--log-update=updatefile
选项文件 [mysqld]
pid-file=pidfile
log=lodfile
log-update=updatefile

如果你用绝对路径名指定状态文件，用该路径创建文件，否则文件在数据目录下创建。如，如果你指定--pid-file=/var/run/mysqld.pid，PID文件是/var/run/mysqld.pid。如果你指定-pid-file=mysqld.pid，PID文件是DATADIR/mysqld.pid。
如果你指定无扩展名的更新日志文件，MySQL在它每次打开更新日志时产生顺序名。这些名字用一个扩展名.nnn，这里.nnn是还没被现有更新日志使用的第一个数字（如update.000,update.001等）。你可以通过明确指定扩展名来覆盖顺序名，这时服务器将只使用指定的名字。

keaide

在数据库表丢失或损坏的情况下，备份你的数据库是很重要的。如果发生系统崩溃，你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态。有时，正是MySQL管理员造成破坏。管理员已经知道表以破坏，用诸如vi或Emacs等编辑器试图直接编辑它们，这对表绝对不是件好事！
备份数据库两个主要方法是用mysqldump程序或直接拷贝数据库文件（如用cp、cpio或tar等）。每种方法都有其优缺点：
mysqldump与MySQL服务器协同操作。直接拷贝方法在服务器外部进行，并且你必须采取措施保证没有客户正在修改你将拷贝的表。如果你想用文件系统备份来备份数据库，也会发生同样的问题：如果数据库表在文件系统备份过程中被修改，进入备份的表文件主语不一致的状态，而对以后的恢复表将失去意义。文件系统备份与直接拷贝文件的区别是对后者你完全控制了备份过程，这样你能采取措施确保服务器让表不受干扰。
mysqldump比直接拷贝要慢些。
mysqldump生成能够移植到其它机器的文本文件，甚至那些有不同硬件结构的机器上。直接拷贝文件不能移植到其它机器上，除非你正在拷贝的表使用MyISAM存储格式。ISAM表只能在相似的硬件结构的机器上拷贝。在MySQL 3.23中引入的MyISAM表存储格式解决了该问题，因为该格式是机器无关的，所以直接拷贝文件可以移植到具有不同硬件结构的机器上。只要满足两个条件：另一台机器必须也运行MySQL 3.23或以后版本，而且文件必须以MyISAM格式表示，而不是ISAM格式。

keaide

不管你使用哪种备份方法，如果你需要恢复数据库，有几个原则应该遵守，以确保最好的结果：
定期实施备份。建立一个计划并严格遵守。
让服务器执行更新日志。当你在崩溃后需要恢复数据时，更新日志将帮助你。在你用备份文件恢复数据到备份时的状态后，你可以通过运行更新日志中的查询再次运用备份后面的修改，这将数据库中的表恢复到崩溃发生时的状态。
以文件系统备份的术语讲，数据库备份文件代表完全倾倒（full dump），而更新日志代表渐进倾倒（incremental dump）。
使用一种统一的和易理解的备份文件命名机制。象backup1、buckup2等不是特别有意义。当实施你的恢复时，你将浪费时间找出文件里是什么东西。你可能发觉用数据库名和日期构成备份文件名会很有用。例如：
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
%mysqldump menagerie >/usr/archives/mysql/menagerie.1999-10-02
你可能想在生成备份后压缩它们。备份一般都很大！你也需要让你的备份文件有过期期限以避免它们填满你的磁盘，就象你让你的日志文件过期那样。
用文件系统备份备份你的备份文件。如果遇上了一个彻底崩溃，不仅清除了你的数据目录，也清除了包含你的数据库备份的磁盘驱动器，你将真正遇上了麻烦。也要备份你的更新日志。
将你的备份文件放在不同于用于你的数据库的文件系统上。这将降低由于生成备份而填满包含数据目录的文件系统的可能性。

用于创建备份的技术同样对拷贝数据库到另一台机器有用。最常见地，一个数据库被转移到了运行在另一台主机上的服务器，但是你也可以将数据转移到同一台主机上的另一个服务器。

keaide

1 使用mysqldump备份和拷贝数据库

当你使用mysqldumo程序产生数据库备份文件时，缺省地，文件内容包含创建正在倾倒的表的CREATE语句和包含表中行数据的INSERT语句。换句话说，mysqldump产生的输出可在以后用作mysql的输入来重建数据库。
你可以将整个数据库倾倒进一个单独的文本文件中，如下：
%mysqldump samp_db >/usr/archives/mysql/samp_db.1999-10-02
输出文件的开头看起来象这样：# MySQL Dump 6.0# # Host: localhost    Database: samp_db#---------------------------------------# Server version 3.23.2-alpha-log## Table structure for table 'absence'#CREATE TABLE absence(  student_id int(10) unsigned DEFAULT '0' NOT NULL,  date date DEFAULT '0000-00-00' NOT NULL,  PRIMARY KEY (student_id,date));## Dumping data for table 'absence'#INSERT INTO absence VALUES (3,'1999-09-03');INSERT INTO absence VALUES (5,'1999-09-03');INSERT INTO absence VALUES (10,'1999-09-08');......　
文件剩下的部分有更多的INSERT和CREATE TABLE语句组成。
如果你想压缩备份，使用类似如下的命令：
%mysqldump samp_db | gzip >/usr/archives/mysql/samp_db.1999-10-02.gz
如果你要一个庞大的数据库，输出文件也将很庞大，可能难于管理。如果你愿意，你可以在mysqldump命令行的数据库名后列出单独的表名来倾到它们的内容，这将倾倒文件分成较小、更易于管理的文件。下例显示如何将samp_db数据库的一些表倾到进分开的文件中：
%mysqldump samp_db student score event absence >grapbook.sql
%mysqldump samp_db member president >hist-league.sql
如果你生成准备用于定期刷新另一个数据库内容的备份文件，你可能想用--add-drop-table选项。这告诉服务器将DROP TABLE IF EXISTS语句写入备份文件，然后，当你取出备份文件并把它装载进第二个数据库时，如果表已经存在，你不会得到一个错误。
如果你倒出一个数据库以便能把数据库转移到另一个服务器，你甚至不必创建备份文件。要保证数据库存在于另一台主机，然后用管道倾倒数据库，这样mysql能直接读取mysqldump的输出。例如：你想从主机pit-viper.snake.net拷贝数据库samp_db到boa.snake.net，可以这样很容易做到：
%mysqladmin -h boa.snake.net create samp_db
%mysqldump samp_db | mysql -h boa.snake.net samp_db
以后，如果你想再次刷新boa.snake.net上的数据库，跳过mysqladmin命令，但要对mysqldump加上--add-drop-table以避免的得到表已存在的错误：
%mysqldump --add-drop-table samp_db | mysql -h boa.snake.net samp_db
mysqldump其它有用的选项包括：

keaide

--flush-logs和--lock-tables组合将对你的数据库检查点有帮助。--lock-tables锁定你正在倾倒的所有表，而--flush-logs关闭并重新打开更新日志文件，新的更新日志将只包括从备份点起的修改数据库的查询。这将设置你的更新日志检查点位备份时间。（然而如果你有需要执行个更新的客户，锁定所有表对备份期间的客户访问不是件好事。）
如果你使用--flush-logs设置检查点到备份时，有可能最好是倾倒整个数据库。如果你倾倒单独的文件，较难将更新日志检查点与备份文件同步。在恢复期间，你通常按数据库为基础提取更新日志内容，对单个表没有提取更新的选择，所以你必须自己提取它们。
缺省地，mysqldump在写入前将一个表的整个内容读进内存。这通常确实不必要，并且实际上如果你有一个大表，几乎是失败的。你可用--quick选项告诉mysqldump只要它检索出一行就写出每一行。为了进一步优化倾倒过程，使用--opt而不是--quick。--opt选项打开其它选项，加速数据的倾倒和把它们读回。
用--opt实施备份可能是最常用的方法，因为备份速度上的优势。然而，要警告你，--opt选项确实有代价，--opt优化的是你的备份过程，不是其他客户对数据库的访问。--opt选项通过一次锁定所有表阻止任何人更新你正在倾倒的任何表。你可在一般数据库访问上很容易看到其效果。当你的数据库一般非常频繁地使用，只是一天一次地调节备份。
一个具有--opt的相反效果的选项是--dedayed。该选项使得mysqldump写出INSERT DELAYED语句而不是INSERT语句。如果你将数据文件装入另一个数据库并且你想是这个操作对可能出现在该数据库中的查询的影响最小，--delayed对此很有帮助。
--compress选项在你拷贝数据库到另一台机器上时很有帮助，因为它减少网络传输字节的数量。下面有一个例子，注意到--compress对与远端主机上的服务器通信的程序才给出，而不是对与本地主机连接的程序： %mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
mysqldump有很多选项，详见《MySQL参考手册》。