大多数指南推荐mysqldump和简单的SQL来将一个表复制到anoter。cp怎么样?我能简单的做吗
cp /db1/mytable.frm /db2/mytable.frm
发布于 2012-03-07 17:45:09
复制对于MyISAM来说是非常简单的,并且对InnoDB来说完全是100%的风险(近乎自杀)。
从你的问题上,你提出了
cp /db1/mytable.frm /db2/mytable.frm
这样做没问题。但是,您不能只移动.frm。你必须移动所有组件。从您的问题中,我们使用一个名为db1.mytable的表。在正常安装中,表位于/var/lib/mysql/db1中。这张桌子上会有三个文件。
必须移动所有三个文件才能移动一个表。如果您的所有表都使用MyISAM存储引擎,则可以关闭mysql并进行复制。如果您只是简单地复制该表并将其放置到另一个数据库中,则应该使用SQL进行此操作。
例如,如果要将db1.mytable复制到数据库db2,请执行以下操作:
CREATE TABLE db2.mytable LIKE db1.mytable;
ALTER TABLE db2.mytable DISABLE KEYS;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
ALTER TABLE db2.mytable ENABLE KEYS;
现在,如果您只是将表从db1移动到db2,则可以这样做:
ALTER TABLE db1.mytable RENAME db2.mytable;
复制是非常危险的,因为InnoDB所使用的基础结构。有两个基本的基础设施: 1)禁用innodb_file_per_table,2)启用innodb_file_per_table
InnoDB的致命弱点是称为ibdata1的系统表空间文件(通常位于/var/lib/mysql中)。文件中所包含的内容?
禁用innodb_file_per_table后,所有这些类型的InnoDB信息都位于ibdata1中。任何InnoDB表在ibdata1之外的唯一表现形式是InnoDB表的.frm文件。同时复制所有InnoDB数据需要复制/var/lib/mysql的所有数据。
复制单个InnoDB表是完全不可能的。必须使用mysqldump将表的转储提取为数据及其相应的索引定义的逻辑表示形式。然后,将该转储加载到同一服务器或其他服务器上的另一个数据库。
启用innodb_file_per_table后,表数据及其索引将位于.frm文件旁边的数据库文件夹中。例如,对于db1.mytable表,InnoDB表在ibdata1之外的表现形式是:
db1.mytable的所有元数据仍然驻留在ibdata1中,这是绝对没有办法的。重做日志和MVCC数据也仍然使用ibdata1。
如果您正在考虑只复制.frm和.ibd文件,那么您将面临痛苦的世界。只有当您能够保证.frm文件的表空间id与ibdata1文件的元数据中的表空间id项完全匹配时,复制InnoDB表和InnoDB表的文件才是好的。
我用DBA StackExchange写了两篇关于表空间id概念的文章。
下面是关于在出现表空间ids不匹配时如何将和.ibd文件重新附加到ibdata1的优秀链接:http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file。看完这篇文章,你就会明白我为什么说要自杀了。
对于InnoDB,您只需要这样做
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
若要复制InnoDB表,请执行以下操作。如果要将它迁移到另一个DB服务器,请使用mysqldump。
发布于 2012-03-07 15:36:55
复制整个MySQL数据中心是一种实用的技术,假定MySQL服务已经停止,并且希望复制整个数据库服务器。
这是一种转换具有大型索引的数据库的有用技术,mysql转储将不包括索引,在导入时需要重新生成索引。我发现这种技术在设置MySQL奴隶时很有用。
复制单个文件将取决于正在使用的表模式,但在大多数情况下并不是合适的解决方案。
发布于 2012-03-07 23:35:53
使用xtrabackup w/ ow w/o innobackupex包装器,您就可以使用myisam和innodb数据库了。请注意,即使使用xtrabackup,还原Note数据库也不只是复制文件。告诉你是否需要更多的信息
https://serverfault.com/questions/367255
复制相似问题