mysql cp ap_Linux / mysql：使用cp命令将mysql db文件从一个db复制到另一个db是否安全？...

对于MyISAM,复制非常简单,使用InnoDB完全100％风险(接近自杀).

从你的问题,你提出来了

cp /db1/mytable.frm /db2/mytable.frm

MyISAM数据

这样做是可以的.但是,你不能只移动.frm.您必须移动所有组件.从你的问题,让我们采取一个名为db1.mytable的表.在正常安装中,该表位于/ var / lib / mysql / db1中.表格中有三个文件组成.

> /var/lib/mysql/db1/mytable.frm

> /var/lib/mysql/db1/mytable.MYD(表数据库)

> /var/lib/mysql/db1/mytable.MYI(表索引)

您必须移动所有三个文件才能移动一个表.如果所有表都使用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的

由于InnoDB工作的基础设施,复制非常危险.有两种基本的基础结构：1)禁用innodb_file_per_table,2)启用innodb_file_per_table

InnoDB的Achilles’Heel是系统表空间文件,称为ibdata1(通常位于/ var / lib / mysql中). What is contained in that file？

>表数据页面

>表索引页面

>表MetaData(表空间标识管理列表)

> MVCC数据(支持交易隔离和ACID Compliance)

InnoDB(禁用innodb_file_per_table)

禁用innodb_file_per_table后,所有这些类型的InnoDB信息都存在于ibdata1中. ibdata1之外的任何InnoDB表的唯一表现形式是InnoDB表的.frm文件.一次复制所有InnoDB数据需要复制所有/ var / lib / mysql.

复制单个InnoDB表是完全不可能的.您必须mysqldump提取表的转储作为数据及其相应索引定义的逻辑表示.然后,您将该转储加载到同一服务器或另一台服务器上的另一个数据库.

InnoDB(启用innodb_file_per_table)

启用innodb_file_per_table后,表数据及其索引将存在于.frm文件旁边的数据库文件夹中.例如,对于表db1.mytable,ibdata1之外的InnoDB表的表现形式为：

> /var/lib/mysql/db1/mytable.frm

> /var/lib/mysql/db1/mytable.ibd

db1.mytable的所有元数据仍然驻留在ibdata1中,并且绝对没有办法解决这个问题.重做日志和MVCC数据也仍然与ibdata1一起使用.

如果您只想复制.frm和.ibd文件,那么您就会受到伤害.仅当您可以保证.ibd文件的表空间标识与ibdata1文件的metdata中的表空间标识条目完全匹配时,才能复制InnoDB表的.frm和.ibd文件.

我在DBA StackExchange中写了两篇关于这个表空间id概念的帖子

这是关于如何在表空间ID不匹配的情况下将ibdata1重新附加和.ibd文件的优秀链接：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.