本文介绍了rsync和MyISAM表的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图使用rsync备份MySQL数据。这些表使用MyISAM存储引擎。



我的期望是,在第一次rsync之后,随后的rsync将非常快。



我对包含实际数据的989 MB MYD文件进行了实验:

p>

测试1 - 重新复制未修改的数据




  • rsync -a orig.MYD copy.MYD


    • 需要一段时间

    li>
  • rsync -a orig.MYD copy.MYD


    • 即时 - 加速是以百万计




测试2 - p>


  • rsync -a orig.MYD copy.MYD


    • 需要一些时间。


  • UPDATE表SET计数器=计数器+ 1 WHERE id = 12345

  • rsync -a orig.MYD copy.MYD


    • 所需时间与原始副本一样长!




什么给了?为什么rsync永远只是为了复制一个微小的变化?



编辑:事实上,测试2中的第二个rsync需要的时间与第一个。 rsync显然再次复制整个文件。



编辑:当从本地复制到本地时出现,--whole-file是隐含的。即使使用--no-whole-file,性能仍然是可怕的。

解决方案

rsync仍然必须计算块哈希值什么改变。可能是没有修改的情况是一个快捷方式看文件mod时间/大小。


I'm trying to use rsync to backup MySQL data. The tables use the MyISAM storage engine.

My expectation was that after the first rsync, subsequent rsyncs would be very fast. It turns out, if the table data was changed at all, the operation slows way down.

I did an experiment with a 989 MB MYD file containing real data:

Test 1 - recopying unmodified data

  • rsync -a orig.MYD copy.MYD
    • takes a while as expected
  • rsync -a orig.MYD copy.MYD
    • instantaneous - speedup is in the millions

Test 2 - recopying slightly modified data

  • rsync -a orig.MYD copy.MYD
    • takes a while as expected
  • UPDATE table SET counter = counter + 1 WHERE id = 12345
  • rsync -a orig.MYD copy.MYD
    • takes as long as the original copy!

What gives? Why is rsync taking forever just to copy a tiny change?

Edit: In fact, the second rsync in Test 2 takes as long as the first. rsync is apparently copying the whole file again.

Edit: Turns out when copying from local to local, --whole-file is implied. Even with --no-whole-file, the performance is still terrible.

解决方案

rsync still has to calculate block hashes to determine what's changed. It may be that the no-modification case is a shortcut looking at file mod time / size.

这篇关于rsync和MyISAM表的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-10 18:34