如何使用Keycache避免修复？

Question

我有一些优化my.cnf文件的经验,但我的数据库有大约400万条记录(MyISAM).我试图从mysqldump恢复,但每次我做到最终我得到可怕的"修复与Keycache",这可能需要几天.有没有办法克服这个问题并让它成为"通过排序修复"？

我有2GB内存,双内核,大量额外的硬盘空间.

剪掉my.cnf:

set-variable = max_connections=650
set-variable = key_buffer=256M
set-variable = myisam_sort_buffer_size=64M
set-variable = join_buffer=1M
set-variable = record_buffer=1M
set-variable = sort_buffer_size=2M
set-variable = read_buffer_size=2M
set-variable = query_cache_size=32M
set-variable = table_cache=1024
set-variable = thread_cache_size=256
set-variable = wait_timeout=7200
set-variable = connect_timeout=10
set-variable = max_allowed_packet=16M
set-variable = max_connect_errors=10
set-variable = thread_concurrency=8

Answer 1

"通过排序修复"使用filesort例程,该例程又在您的tmpdir中创建了几个临时文件(通常).

如果你的tmpdir没有足够的空间,它将恢复为"通过keycache修复".这非常糟糕,因为它慢得多并且创建的索引不太理想.

还有一些其他条件,但我还没有确定它们.

计算出tmpdir的大小你需要filesort()是非常重要的; 格式数据存储在filesort缓冲区中与MYD文件不同,它通常使用更多空间.

因此,如果您的tmpdir指向小/ tmp(或tmpfs),您可能希望将其更改为更大的/ var/tmp - 如果存在的话.

Answer 2

只要表索引的最大可能大小大于变量myisam_max_sort_file_size的值,MySQL就会使用keycache对MyISAM表进行修复.

您可以通过将所有索引中的所有键的字节大小值相加并将其乘以表中的行数来计算索引的最大大小.

增加myisam_max_sort_file_size并使用磁盘上的排序重建索引,而不是使用慢速keycache方法.

Answer 3

我意外地在一个新的数据库上运行了一个修复表,我还没有设置为快速注册.myisam_max_sort_file_size与.MID文件(大小为88279393280,大约88GB)相比太小了.数据文件是85GB.该表是12亿条记录,包括ID,两个日期,一个小文本,一些bigints和一个double.我的服务器(运行在windows7下的一个盒子里的2GB虚拟linux)在Windows服务器上只有4个核心,但运行3+ GHZ.我担心这个"通过keycache修复"事件会永远耗尽 - 假设有更小的桌子的恐怖故事.

幸运的是,它"仅"花了1天,10小时和20.72秒来完成修复表的快速操作.

我最想念的是了解mysql的操作有多远,以及它可以在多长时间内完成.这对我来说还是个未知数.

我现在已经更改了my.ini文件,并使用df双重检查我有足够的磁盘空间用于那些大型临时文件.

无论如何..我的主要观点,对于陷入这个陷阱的下一个人来说可能是非常有用的知识..实际上......不要惊慌!它可能很慢,但是可以在相当低于标准的硬件上获得在一两天内整理出的10亿条记录.有三个索引,一个在日期字段上,一个在bigint字段上,另一个在ID字段上.

我会发布这个作为对其中一个解决方案的评论,但我似乎无法用这里的用户界面来计算如何做到这一点,所以我将把它作为一个解决方案.不要赞成我,这只是一个我会喜欢在这里注意的一个注释,我几乎要杀死我的"按keycache排序"线程,因为我认为可能需要一周或更长时间.每十亿条记录2天是可管理的..

编辑:现在,在同一个数据库上的修复表,但是有足够大的mysiam_max_sort_file_size设置花了10个小时,20分钟使用修复排序.使用的磁盘空间最多约为250GB,但我将myisam_max_sort_file_size设置得更高,反映了服务器上实际可用的磁盘空间.

跟踪进度很难.在构建各个索引的同时,磁盘空间上下变化,但是有一小时的暂停,没有进行任何更改.磁盘空间使用情况(由df报告).

Answer 4

谢谢Mark,是的,这正是我最终尝试并从日志中看到的,这就是它切换到"使用keycache修复"的原因,是一个空间错误.

这就是我为解决问题所做的工作,因为我不会理解它指向的事实,它/tmp/mysqltmp/最多只有2MB.

所以我这样做了:

mkdir /home/mysqltmp

chown mysql:mysql /home/mysqltmp

将my.conf中的tmp目录更改为 tmpdir=/home/mysqltmp/

现在,如果我使用df -h /home/mysqltmp,我看到的是dir有285 GB可用,所以这真的是一个很好看的视野,有足够的可用空间,而且我可以看到mysql很容易想要20GB.所以现在12小时前带我的是在20分钟内完成,即超过300万条记录插入索引.