社区
MySQL
帖子详情
原来data文件夹下的数据库文件(*.opt,*.frm)怎样导到当前数据库中
billowcn
2006-12-02 06:03:38
数据库:mysql5.0.18-nt
参考书给的数据库data文件夹,怎么把它导到当前数据库中呢?谢谢!
...全文
226
3
打赏
收藏
原来data文件夹下的数据库文件(*.opt,*.frm)怎样导到当前数据库中
数据库:mysql5.0.18-nt 参考书给的数据库data文件夹,怎么把它导到当前数据库中呢?谢谢!
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
3 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
懒得去死
2006-12-03
打赏
举报
回复
你的表类型是什么?
如果是MYISAM
那没有数据文件。
最好还是原来用mysqldump导出来,然后在用的时候导到新库,要不然回出现权限等的问题。
billowcn
2006-12-02
打赏
举报
回复
是这样复制的,用sqlyog打开后,库和表都有,但表都没有字段了.会是什么原因呢
mschen
2006-12-02
打赏
举报
回复
把Data整个复制过来就行了.
数据库
灾难性恢复(
数据库
技术;灾难性;恢复;数据备份)
目录 摘要 3 ABSTRACT 3 1. 灾难类型 4 2. 恢复类型 4 3. 恢复的级别 4 4. 需要防止的故障级别 4 4.1 可接受的数据丢失量 5 4.2 允许用于恢复的时间量 5 4.3 备份和恢复 5 5. 灾难恢复方案 5 5.1 简单备份 6 5.2 备份和日志保留 7 6. 高级存储备份 8 7.
数据库
恢复 9 摘要 随着
数据库
技术在各个行业和各个领域大量广泛的应用,在对
数据库
应用的过程
中
,人为误操作、人为恶意破坏、系统的不稳定、存储介质的损坏等等原因,都有可能造成重要数据的丢失。一旦数据出现丢失或者损坏,都将给企业和个人带来巨大的损失。这就需要进行
数据库
恢复。 关键词:
数据库
技术;灾难性;恢复;数据备份 ABSTRACT With the
data
base technology in various industries and a large number of wide application in various fields, in the process of
data
base applications, artificial misuse, human vandalism, system instability, damage to storage media and other reasons may have resulted in important
data
lost. Once the
data
appears lost or damaged, both businesses and individuals will give enormous losses. This need for
data
base recovery. Abstract:
Data
base technology; catastrophic; recovery;
Data
BackupDevice Driver;
Data
Backup; Logical Block Address;
数据库
灾难性恢复 1. 灾难类型 为了使
数据库
损失降低到最小程度,需要一个恢复策略,确保它起作用,并经常实行策略,一些灾难类型包括: 1. 系统故障。电源故障、硬件故障或软件故障都能够使
数据库
处于不一致状态。 2. 事务故障。用户无意
中
会用错误数据修改
数据库
,从而毁坏
数据库
。 3. 介质故障。如果磁盘驱动器变得不能使用,那么可能会丢失所有或部分数据。 4. 自然灾难。系统所在的设施可能会遭受火灾、洪水或其它类似灾难的损坏。 2. 恢复类型 DB2 考虑到了下列恢复类型: 1. 崩溃恢复。这种类型的恢复通过撤销(回滚)未提交的事务来防止
数据库
处于不一致状态。 2. 版本恢复。这种类型的恢复通过使用从 BACKUP 命令获取的备份映像来恢复先前的
数据库
版本。恢复的
数据库
将包含在执行 BACKUP 命令时所处状态的信息。如果在执行备份之后针对
数据库
执行进一步操作,那么该信息将丢失。 3. 前滚恢复。这种类型的恢复通过使用完全
数据库
备份,结合日志
文件
来扩展版本恢复。必须先恢复备份以用作基线;然后在该备份之上应用日志。该过程会将
数据库
或表空间恢复到某个特定时间点。前滚恢复要求启用归档日志记录。 3. 恢复的级别 建立灾难恢复计划对于现代企业至关重要。企业
数据库
中
的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR计划时,有三个关键级别问题。 4. 需要防止的故障级别 要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密?备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。 4.1 可接受的数据丢失量 所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的,但由于可能需要的复杂性和费用(尤其是如果所防止的故障级别非常高),这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。 4.2 允许用于恢复的时间量 恢复所需的时间量类似于高可用性的目标。它与高可用性解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量,而灾难恢复则可能以小时和天来进行衡量。不过并非总是这样,但这个差异区分了对这些解决方案的相对期望。 4.3 备份和恢复
数据库
备份创建了
数据库
的时间点映象,它是灾难恢复解决方案的基本组件。DB2 提供了几种备份,包括脱机备份、联机备份和增量备份。从备份恢复所需的时间取决于
数据库
的大小和可用于执行恢复的硬件资源。 由于
数据库
备份只捕获时间点的数据,因此无法通过一个简单恢复来恢复备份之后发生的任何数据更改。要恢复备份之后完成的事务,就需要应用日志
文件
。可以从备份和日志
文件
(通过在日志
文件
中
进行“前滚”来应用)来恢复
数据库
。这允许恢复到某个时间点或恢复到日志
文件
结束。 因此,如果 DR 解决方案必须恢复自上次备份以来的事务,那么保留日志
文件
是非常关键的。有两个提高日志保留的 DB2 特性:双日志记录和用户出口工具,已在关于
数据库
复制 HA 选项的部分
中
进行了讨论。 5. 灾难恢复方案 灾难恢复方案可以分成三类:简单备份、备份和日志保留、高级存储备份 。 虽然不是每个解决方案都清晰地被划入这三类
中
的某一类,但它们确实为您理解灾难恢复选项提供了合理的框架。 5.1 简单备份 MySQL表保存为
文件
方式,很容易备份。要想保持备份的一致性,对相关表执行LOCK TABLES操作,然后对表执行FLUSH TABLES。你只需要读锁定;这样当你复制
数据库
目录
中
的
文件
时,允许其它客户继续查询表。需要FLUSH TABLES语句来确保开始备份前将所有激活的索引页写入硬盘。 备份
数据库
的另一个技术是使用mysqldump程序或mysqlhotcopy脚本。 1. 完全备份
数据库
: 2. shell> mysqldump --tab=/path/to/some/dir --
opt
db_name 或: shell> mysqlhotcopy db_name /path/to/some/dir 只要服务器不再进行更新,还可以只复制所有表
文件
(*.
frm
、*.MYD和*.MYI
文件
)。mysqlhotcopy脚本使用该方法。(但请注意如果
数据库
包含InnoDB表,这些方法不工作。InnoDB不将表的内容保存到
数据库
目录
中
,mysqlhotcopy只适合MyISAM表)。 3. 如果mysqld在运行则停止,然后用--log-bin[=file_name]选项来启动。二进制日志
文件
中
提供了 执行mysqldump之后对
数据库
的更改进行复制所需要的信息。 对于InnoDB表,可以进行在线备份,不需要对表进行锁定; MySQL支持增量备份:需要用--log-bin选项来启动服务器以便启用二进制日志;当想要进行增量备份时(包含上一次完全备份或增量备份之后的所有更改),应使用FLUSH LOGS回滚二进制日志。然后,你需要将从最后的完全或增量备份的某个时刻到最后某个点的所有二进制日志复制到备份位置。这些二进制日志为增量备份;恢复时,按照下面的解释应用。下次进行完全备份时,还应使用FLUSH LOGS或mysqlhotcopy --flushlogs回滚二进制日志。如果MySQL服务器为从复制服务器,则无论选择什么备份方法,当备份从机数据时,还应备份master.info和relay-log.info
文件
。恢复了从机数据后,需要这些
文件
来继续复制。如果从机执行复制LOAD
DATA
INFILE命令,你应还备份--slave-load-tmpdir选项指定的目录
中
的SQL_LOAD-*
文件
。(如果未指定,该位置默认为tmpdir变量值)。从机需要这些
文件
来继续复制
中
断的LOAD
DATA
INFILE操作。 如果必须恢复MyISAM表,先使用REPAIR TABLE或myisamchk -r来恢复。99.9%的情况下该方法可以工作。如果myisamchk失败,试试下面的方法。请注意只有用--log-bin选项启动了MySQL从而启用二进制日志它才工作; 1. 恢复原mysqldump备份,或二进制备份。 2. 执行下面的命令重新更新二进制日志: 3. shell> mysqlbinlog hostname-bin.[0-9]* | mysql 在某些情况下,你可能只想要从某个位置重新运行某些二进制日志。(通常你想要从恢复备份的日期重新运行所有二进制日志,查询不正确时例外)。 还可以对具体
文件
进行选择备份: • 要想复制表,使用SELECT * INTO OUTFILE 'file_name' FROM tbl_name。 要想重载表,使用LOAD
DATA
INFILE 'file_name' REPLACE ...并恢复。要避免复制记录,表必须有PRIMARY KEY或一个UNIQUE索引。当新记录复制唯一键值的旧记录时,REPLACE关键字可以将旧记录替换为新记录。 如果备份时遇到服务器性能问题,可以有帮助的一个策略是在从服务器而不是主服务器上建立复制并执行备份。如果使用Veritas
文件
系统,可以这样备份: 1. 从客户端程序执行FLUSH TABLES WITH READ LOCK。 2. 从另一个shell执行mount vxfs snapshot。 3. 从第一个客户端执行UNLOCK TABLES。 4. 从快照复制
文件
。 5. 卸载快照。 只创建
数据库
备份确实创建了一个 DR 解决方案。它也许是非常有限的,这取决于您的环境。通过从“活动”的系统上移走所创建的备份,可以提高保护的级别。增加
数据库
备份的频率也降低了数据丢失的风险。备份软件对于创建和维护 DB2 备份可能非常有帮助。例如,IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允许在其软件控制的设备上直接备份和维护 DB2
数据库
的解决方案。这些设备可以是磁带库或另一种存储设备。 简单备份适合于只读
数据库
或由能轻松重新创建的批处理作业填充的
数据库
,或者在备份之间不必维护
数据库
更改的情况下。 表 1.简单备份的优缺点 优点: 缺点: 保护级别:
数据库
备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 备份之间的数据更改可能会丢失(运行增量备份来降低风险的影响) 恢复所需的时间:
数据库
恢复需要很长时间 5.2 备份和日志保留 保留
数据库
日志
文件
与
数据库
备份一起创建了更完善的 DR 解决方案。日志
文件
允许恢复备份之间发生的数据更改。该解决方案的真正复杂性在于保护日志
文件
以确保它们在恢复期间的可用性。如果选择实现双日志记录,DB2 可以将日志
文件
放在不同的位置,如果确保这些位置在不同的存储器阵列上,那么保护级别就会得到提高。但是,日志
文件
仍面临存储子系统故障。如在高可用性的日志传送选项
中
所提到的,用户出口程序可以提供重定位日志
文件
的替代方法。 用户出口可以将已关闭的日志
文件
移到
当前
系统可用存储阵列之外的位置,从而提高保护级别。这里的告诫是它只移动已关闭的日志
文件
。即使已实现了双日志记录,包含活动事务的日志
文件
仍面临因阵列丢失或存储设备故障而产生的丢失。该解决方案适合于大多数面向商业事务的环境。 它均衡了最小化数据丢失风险的需要和维护 DR 解决方案所需的成本。 表 2.备份加日志保留的优缺点 优点: 缺点: 保护级别:
数据库
备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 如果使用适当的步骤来维护日志
文件
,会大大降低数据丢失的风险 恢复所需的时间:
数据库
恢复需要时间,应用日志
文件
将增加恢复时间 6. 高级存储备份 我们在高可用性下的高级存储选项部分
中
讨论过这个主题,相同的原则在这里也适用。正如在那部分
中
所见的,STANDBY方法允许当
数据库
副本处于暂挂状态时在辅助系统上执行
数据库
备份。 创建
数据库
副本已经创建了 DR解决方案的一部分。备份副本提高了保护级别。如果用双日志记录和用户出口程序正确实现了这个高级存储备份,那么它就为核心企业
数据库
生成了最好的 DR解决方案。 该解决方案最适合处于企业活动核心的
数据库
系统。示例可能包含了供应链管理和在线代理系统。 表 3.用于灾难恢复的高级存储备份优缺点 优点: 缺点: 保护级别: 保护级别本来就很高,而且可以通过耦合存储子系统来提高保护级别。 数据丢失的风险: 如果采用双日志记录和用户出口程序,会大大降低数据丢失的风险 恢复所需的时间: 恢复所需的时间非常短。 7.
数据库
恢复
数据库
恢复
中
心理解为: (1)当
数据库
出现损伤或由于人员误操作、操作系统本身故障所造成的数据看不见、无法读取、丢失。工程师通过技术手段读取将数据都恢复为可以读的数据,数据恢复不是靠一两种软件就可以完成,往往需要数个工程师靠经验不同的方式才能恢复数据,当然
数据库
恢复还包括各种操作系统:除普通的WINDOWS外,还有Unix、Linux、APPLE机,而以UNIX为多。 (2)
数据库
数据已经存在,但是无法正常使用,提示错误,都应归属为数据修复,举例说明:SQL SERVER
文件
打开提示LDF
文件
损坏,或错误823等等。
数据库
恢复实际上就是利用技术手段把不可见或不可正常运行的数据
文件
恢复成正常运行的过程。 方法一 如何附加
数据库
(企业管理器) 1、展开服务器组,然后展开服务器。 2、右击"
数据库
",然后选择"所有任务"/"附加
数据库
"。 3、输入要附加的
数据库
的 MDF(master 数据
文件
)名称。如果不确定
文件
位于何处,单击浏览("...")搜索。最多可以指定16个
文件
名。 4、若要确保指定的MDF
文件
正确,请单击"验证"。"原
文件
名"列列出了
数据库
中
的所有
文件
(数据
文件
和日志
文件
)。"
当前
文件
位置"列列出了
文件
的名称和路径。如果Microsoft? SQL Server? 找不到指定位置的
文件
,则附加操作将失败。可以对"
当前
文件
位置"列进行编辑,并且
文件
的
当前
位置必须在该列
中
才能使附加操作得以进行。例如,如果在分离操作前改变了
文件
的默认位置,则必须指定
当前
位置才能使附加操作顺利进行。 5、在"附加为"框内,输入
数据库
的名称。
数据库
名称不能与任何现有
数据库
名称相匹配 6、指定
数据库
的所有者。 7、单击"确定"按钮。新附加的
数据库
的
数据库
节点即创建在"
数据库
"
文件
夹
中
。 方法二 sp_attach_db 将
数据库
附加到服务器。 语法 sp_attach_db [ @dbname = ] 'dbname' , [ @filename1 = ] 'filename_n' [ ,...16 ] 参数 [@dbname =] 'dbname' 要附加到服务器的
数据库
的名称。该名称必须是唯一的。dbname 的数据类型为 sysname,默认值为 NULL。 [@filename1 =] 'filename_n'
数据库
文件
的物理名称,包括路径。filename_n 的数据类型为 nvarchar(260),默认值为 NULL。最多可以指定 16 个
文件
名。参数名称以 @filename1 开始,递增到 @filename16。
文件
名列表至少必须包括主
文件
,主
文件
包含指向
数据库
中
其它
文件
的系统表。该列表还必须包括
数据库
分离后所有被移动的
文件
。 返回代码值 0(成功)或 1(失败) 结果集 无 注释 只应对以前使用显式 sp_detach_db 操作从
数据库
服务器分离的
数据库
执行 sp_attach_db。如果必须指定多于 16 个
文件
,请使用带有 FOR ATTACH 子句的 CREATE
DATA
BASE。 如果将
数据库
附加到的服务器不是该
数据库
从
中
分离的服务器,并且启用了分离的
数据库
以进行复制,则应该运行 sp_removedbreplication 从
数据库
删除复制。 权限 只有 sysadmin 和 dbcreator 固定服务器角色的成员才能执行本过程。 示例 下面的示例将 pubs
中
的两个
文件
附加到
当前
服务器。 EXEC sp_attach_db @dbname = N'pubs', @filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\
Data
\pubs.mdf', @filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\
Data
\pubs_log.ldf' 请参见 CREATE
DATA
BASE sp_attach_single_file_db sp_detach_db sp_helpfile sp_removedbreplication 系统存储过程
用(*.
frm
*.MYD *.MYI)
文件
恢复MySql
数据库
保存下来以防以后遇到 今天还原mysql
数据库
时,看到那个
data
文件
夹
下好几个
文件
,还没有.sql
文件
,没有见过,总结下。
Data
文件
夹
里面包括:
数据库
名
文件
夹
,
文件
夹
里包括,*.
frm
,*.MYI,*.MYD,并且包含一个db.
opt
文件
。分别介绍一下:*.
frm
----描述了表的结构*.MYI----表的索引*.myd----保存了表的数据记录db.
opt
-...
MySQL查看
数据库
文件
的存放路径、直接导入.
opt
/.
frm
/.ibd等
数据库
文件
问题: 为了直接导入.
opt
/.
frm
/.ibd等
数据库
文件
,我们需要知道
数据库
存放的路径。 在MySQL的安装目录
中
没有找到
data
(
数据库
存放的地方)的
文件
夹
,我们需要找到
数据库
文件
data
的存放目录,解决办法如下: 解决方法 在MySQL的cmd
中
输入以下命令(MySQL5.7 Command Line Client): show variables like '%
data
dir%'; 效果图 导入.
opt
/.
frm
/.ibd等
数据库
文件
将相应的
数据库
文件
夹
直接拖入上述
数据库
文件
存储位置C:\P
如何将*.
frm
,*.MYD和*.MYI格式的
文件
导入MySQL
中
frm
,myd,myi是属于MySQL存储数据的
文件
,*.
frm
是描述了表的结构,*.MYD保存了表的数据记录,*.MYI则是表的索引 方法: 找到你的mysql的安装目录下的
data
文件
夹
(找到my.ini
文件
,打开找到
data
dir="E:/phpStudy/MySQL/
data
/",新建一个
文件
夹
,
文件
夹
的名称是你想设计的库的名称,把这些
文件
(
frm
,myd,myi格式的
文件
)放到此文...
.
frm
_.myd_myi转换为.sql导入mysql
数据库
_怎么把
opt
myi myd
frm
等
文件
转换为sql
数据库
格式...
今天找了个案例,琢磨了半天,才分析大概出来,
数据库
是.
frm
,.myd,myi备份,不会导入mysql,到网上找了些资料,导入成功。把mysql
数据库
的*.
frm
,*.myd,*.myi,
文件
导到
数据的方法1、最简单就是,直接拷贝到
数据库
的的
data
下的
数据库
文件
夹
,前提是mysql的版本一致,字体一致。此方法简单快捷但不是没个人都能做到。2、就是在本地机器安装mysql
数据库
转换*.
frm
,*....
MySQL
56,687
社区成员
56,710
社区内容
发帖
与我相关
我的任务
MySQL
MySQL相关内容讨论专区
复制链接
扫一扫
分享
社区描述
MySQL相关内容讨论专区
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章