错误解决,数据库跨操作系统的最快迁移方法

  1. 启动mysql,输入show processlist(关闭某一线程 kill id;); 如果有 SUPER 权限,则可以看到全部的线程...

, 如果普通的迁移,需要在原始数据库导出数据,然后在新数据库导入数据 经仔细考虑,是否MySQL的数据库文件存储...

复制代码 代码如下:

  1. 进入mysql/bin目录下输入mysqladmin processlist;
  2. 启动mysql,输入show processlist(关闭某一线程 kill id;);
    如果有 SUPER 权限,则可以看到全部的线程,否则,只能看到自己发起的线程(这是指,当前对应的MySQL帐户运行的线程)。
    得到数据形式如下(只截取了三条):
    mysql> show processlist;
    ----- ------------- -------------------- ------- --------- ------- ---------------------------------- ----------
    | Id | User | Host | db | Command | Time| State | Info
    ----- ------------- -------------------- ------- --------- ------- ---------------------------------- ----------
    |207|root |192.168.0.20:51718 |mytest | Sleep | 5 | | NULL
    |208|root |192.168.0.20:51719 |mytest | Sleep | 5 | | NULL
    |220|root |192.168.0.20:51731 |mytest |Query | 84 | Locked |
    select bookname,culture,value,type from book where id=001
    先简单说一下各列的含义和用途,第一列,id,不用说了吧,一个标识,你要kill一个语句的时候很有用。user列,显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。host列,显示这个语句是从哪个ip的哪个端口上发出的。呵呵,可以用来追踪出问题语句的用户。db列,显示这个进程目前连接的是哪个数据库。command列,显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。time列,此这个状态持续的时间,单位是秒。state列,显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个sql语句,已查询为例,可能需要经过copying to tmp table,Sorting result,Sending data等状态才可以完成,info列,显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。

数据库文件很大,约有70G,
如果普通的迁移,需要在原始数据库导出数据,然后在新数据库导入数据
经仔细考虑,是否MySQL的数据库文件存储格式在不同的操作系统相同呢?
测试过程如下:
在64位SUN机器上安装64位版的MySQL
停止MySQL服务
复制Windows上的32位MySQL的数据文件(全部,除了system和日志等)到64位机器上,
修改相应的文件和目录权限,
文件为 chmod 660
目录为 chmod 700
然后重启MySQL服务,运行正常。
总结:
别以为这个看上去很简单,许多人会错误的认为,不同的操作系统,其存储并不是通用的,而这个例子证明,相同数据库数据的存储结构是没有区别的,完全可以直接拿来使用。
附上中间遇到的一个小异常,那就是数据库的数据目录,必须有可执行的权限,也就是7的权限,6的不可以。
图片 1 
我的测试过程
图片 2

解决办法:首先需要定位到你的mysql的bin目录,里面包含myisamchk.exe文件的目录
./myisamchk -c -r 数据库表MYI文件的路径(例如:/home/mysql/var/crawlerfeedsky/aaaa.MYI)
如果还不行,就-f 强制修复

. 进入mysql/bin目录下输入mysqladmin processlist;

下面是网上收集的多种方法,大家可以测试下。
(一)
昨晚浏览自己的Blog的时候,突然发现所有页面都无法显示,到后台查看的时候,发现一个”Table ‘xxx' is marked as crashed and should be repaired” 的错误。连忙上网搜索,原来修改这个严重的错误很简单:

MyISAM-table

  • recovering (with sort) MyISAM-table '/bak/lib/mysql/yourealcn/biz_user.MYI'
    Data records: 20414
  • Fixing index 1
  • Fixing index 2
  • Fixing index 3
  • Fixing index 4
    (三)
    Caused by: java.sql.SQLException: Table '表名' is marked as crashed and should be repaired
    解决办法:
    ./myisamchk -c -r 数据库表MYI文件的路径(例如:/home/mysql/var/crawlerfeedsky/aaaa.MYI)
    如果还不行,就-f 强制修复
    (四)
    今天上服务器一看,发现网页错误,无法连接数据库服务器。mysql服务自己down掉了,然后重新启动服务器,发现网页无法打开,提示: [mysql]Table tblName is marked as crashed and should be repaired
    Mysql提示tblName表格已损坏,需要修复,解决方法:
    进入到对应的数据库目录:
    cd /var/lib/mysql/dbname
    使用myisamchk修复:
    shell> myisamchk -r tblName
    (五)
    我用的修复命令是:myisamchk -r bbsthreads
    其中bbsthreads是我出问题的表名,当然使用这个命令还得进入mysql你所出问题的数据库的表的存放路径,具体更详细的命令可以看帮助:myisamchk --help;
    如果用以上命令你不能解决问题请看后面,后面的内容是我转载的。
    我的网站出问题了,访问一看,果然全屏报错,检查mysql日志,错误信息为:
    Table '.dedecmsv4dede_archives' is marked as crashed and should be repaired
    提示说cms的文章表dede_archives被标记有问题,需要修复。于是赶快恢复历史数据,上网查找原因。最终将问题解决。解决方法如下:
    找到mysql的安装目录的bin/myisamchk工具,在命令行中输入:
    myisamchk -c -r ../data/dedecmsv4/dede_archives.MYI
    然后myisamchk 工具会帮助你恢复数据表的索引。重新启动mysql,问题解决。
    问题分析:
    1、错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。
    问题的编号为145
    2、问题解决办法。
    当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。
    这三种修复方法如下所示:
    % myisamchk --recover --quick /path/to/tblName
    % myisamchk --recover /path/to/tblName
    % myisamchk --safe-recover /path/to/tblName
    第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。
    检查和修复MySQL数据文件
    如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧:
    如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容:
    mysql> DELETE FROM tblName;
    在删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。
    如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。
    启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。
    3、myisamchk工具介绍(见mysql的官方手册)
    可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。
    调用myisamchk的方法:
    shell> myisamchk [options] tbl_name ...
    options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk --help得到选项列表。
    tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk,你必须指定数据库目录的路径,因为myisamchk不知道你的数据库位于哪儿。实际上,myisamchk不在乎你正在操作的文件是否位于一个数据库目录;你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复操作。
    如果你愿意,可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ .MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如,如果你在数据库目录,可以这样在目录下检查所有的MyISAM表:
    shell> myisamchk *.MYI
    如果你不在数据库目录下,可通过指定到目录的路径检查所有在那里的表:
    shell> myisamchk /path/to/database_dir/*.MYI
    你甚至可以通过为MySQL数据目录的路径指定一个通配符来检查所有的数据库中的所有表:
    shell> myisamchk /path/to/datadir/*/*.MYI
    推荐的快速检查所有MyISAM表的方式是:
    shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI
    如果你想要检查所有MyISAM表并修复任何破坏的表,可以使用下面的命令:
    shell> myisamchk --silent --force --fast --update-state
    -O key_buffer=64M -O sort_buffer=64M
    -O read_buffer=1M -O write_buffer=1M
    /path/to/datadir/*/*.MYI
    该命令假定你有大于64MB的自由内存。关于用myisamchk分配内存的详细信息,参见5.9.5.5节,“myisamchk内存使用”。
    当你运行myisamchk时,必须确保其它程序不使用表。否则,当你运行myisamchk时,会显示下面的错误消息:
    warning: clients are using or haven't closed the table properly
    这说明你正尝试检查正被另一个还没有关闭文件或已经终止而没有正确地关闭文件的程序(例如mysqld服务器)更新的表。
    如果mysqld正在运行,你必须通过FLUSH TABLES强制清空仍然在内存中的任何表修改。当你运行myisamchk时,必须确保其它程序不使用表。避免该问题的最容易的方法是使用CHECK TABLE而不用myisamchk来检查表。

预防措施:...

也可能其中任意方法都可以适用于本数据库。我暂时没有条件测试,有条件的去测试一下,有望解决数据库报此错误的问题。
预防措施:
1、一定要备份一次数据库,起码保留了表结构,有些可有可无的数据,可以直接覆盖。
2、重要的数据要经常注意备份,一般一个月左右备份一次。
3、出现此类错误,一般能够解决,经jb51.net测试下面的方法是比较可行的。

  • recovering (with sort) MyISAM-table 'jb51_soft'
    Data records: 7216
  • Fixing index 1
  • Fixing index 2
  • Fixing index 3

本文由ca88手机版登录发布于亚洲城ca88手机版官网,转载请注明出处:错误解决,数据库跨操作系统的最快迁移方法

TAG标签: ca88手机版登录
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。