- 首先,。否则,服务器会抱怨不能找到授权表。恢复表后,执行mysqladmin冲水privileges告诉服务器装载授权表,并用它们来启动。数据库目录到其他地方的原始内容
复制。例如,您可以使用它们在以后的事后分析检查表(验尸)的崩溃。
酒店与最新的数据库备份文件重新加载。如果您打算使用mysqldump的所加载的文件,则需要输入它们作为mysql的。如果您打算使用从数据库文件直接拷贝(例如,使用tar或CP),它会复制他们直接回数据库目录中。然而,在这种情况下,你应该在关闭之前,该服务器复制这些文件,然后重新启动它。在备份过程中
重做日志,然后查询更新数据库表中。对于所有可用的更新日志,你可以使用它作为mysql的输入。指定--one-database选项,因此MySQL只是要还原的数据库执行查询。如果你意识到有必要使用所有的更新日志文件,可以使用包含以下命令日志的目录:
%LS-TRL更新(0-9)* | xargs的猫| mysql--。一个数据库DB_NAME
ls命令生成一个单独的日志文件更新列表,更新日志文件根据服务器(你知道,如果你其中的任何文件,排序顺序生成的顺序进行排序会发生变化,这将导致在更新日志中以错误的顺序使用)。有限公司您可能需要使用一些更新日志。例如,如果日志,因为命名update.392备份,pdate.393等产生的,可以在命令重新运行它们:
%的mysql - 一个数据库DB_NAME <录入。 392
%的mysql - 一个数据库DB_NAME <updata.393 ...
如果您正在运行的恢复,并打算使用更新日志恢复由于失误降数据的基础上,DROPTABLE或DELETE语句和丢失的信息时,一定要在开始更新日志删除这些语句。
恢复单个表
恢复单个表是非常困难的。如果是的mysqldump备份文件生成的,它只是不包含数据,您需要一个表,你需要提取的相关线路,并利用它们作为mysql的输入,这部分比较容易。困难的是,提取在该表的更新日志中使用的片段。你会发现:mysql_find_rows工具在这方面有所帮助,它可以提取多行从更新日志查询。另一种可能性是使用另一台服务器
恢复整个数据库,然后将该文件复制到表的原始数据库。这其实很容易!当文件被复制回数据库目录,确保原始数据库服务器关闭。
在解决的过程中,以下几种尝试:1.如果开启了日志,直接mysqlbinlog 使用日志恢复即可。2.如果不是删除了一个表的部分数据,而是删除整个表,那么可以在删除后马上用磁盘数据恢复软件尝试恢复。(因为删除表后会有文件被删除,而删除表的部分数据,文件还是存在)3.找数据恢复的公司,使用工具分析ibdata1(分析过程参考一页一页查看有没有历史记录存在,使用ibdata1恢复数据,应该是在了解数据表结构的前提下,数据库除ibdata1外其他数据受损不能正常使用数据库时尝试,而不是删了表数据后恢复什么的。(事实上,这个文件是存储现有表数据的,其实也可以设置成每个表一个文件。)4.mysql下有ib_logfile0和ib_logfile1两个文件,其实这两个文件里,记录了Mysql的一些事物日志,用于事务的前滚后滚,是Mysql自身使用的,这个文件用文本工具打开后,有很多乱码,但却可以查找到被删除的少量数据的insert记录,极少数的乱码通过前后语句找出了原文,最终通过事物日志恢复了删除的文件。注:用事物日志恢复,需要几个前提。1:知道被删除数据的大概位置,不要这边查找,那边又不断有新数据插入。2:因为有很多乱码,适用于查找少量数据,而不是用作大量数据的恢复,浪费体力。3:如果二进制日志没开,没有备份,那么只能用这种方法恢复了。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)