MySQL复制性能

我在两台机器（主要是myISAM表和基于语句的复制）之间的MySQL 5.5复制性能方面遇到严重问题。二进制日志和mysql数据目录均位于同一Fusion ioDrive上。

最近，当我们需要暂停复制大约2秒钟时，这个问题是一个大问题。3小时。没有其他负载，又花了大约10个小时再次赶上。

如何提高复制性能？机器B基本上是空闲的（很少，IO，16个中的2个内核已用完），因为只有1个mySQL线程正在写入数据。这是我的一些想法：

• 切换到基于行的复制。在测试中，这只会产生10-20％的性能提升
• 使用多线程复制升级到mySQL 5.6。我们可以轻松地将数据拆分到单独的数据库中，而基准测试似乎表明这会有所帮助，但是代码似乎还没有准备就绪。
• 一些有助于加速复制的配置变量

主要问题是，如果在暂停3小时后需要10个小时才能赶上，那么这意味着复制正在10个小时内写入13个小时的数据，或者能够以130％的数据输入速度进行写入。在不久的将来，至少要在Master计算机上进行两次写入，因此迫切需要一种提高复制性能的方法。

机器A：

• 主
• 24GB内存
• 1.2TB Fusion ioDrive2
• 2个E5620
• 千兆互连

my.cnf：

[mysqld]
server-id=71
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

log-bin=/data_fio/mysqlbinlog/mysql-bin.log
binlog-format=STATEMENT
replicate-ignore-db=mysql

log-slave-updates = true

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

机器B：

• 奴隶
• 36GB内存
• 1.2TB Fusion ioDrive2
• 2个E5620
• 千兆互连

my.cnf：

[mysqld]
server-id=72
datadir=/data_fio/mysqldata
socket=/var/lib/mysql/mysql.sock
tmpdir=/data_fio/mysqltmp

log-error = /data/logs/mysql/error.log
log-slow-queries = /data/logs/mysql/stats03-slowquery.log
long_query_time = 2
port=3306

# Performance Tuning
max_allowed_packet=16M
max_connections=500
table_open_cache = 2048
max_connect_errors=1000
open-files-limit=5000

# mem = key_buffer + ( sort_buffer_size + read_buffer_size ) * max_connections
key_buffer=4G
max_heap_table_size = 1G
tmp_table_size = 4G
myisam_sort_buffer_size = 256M
sort_buffer_size=4M
read_buffer_size=2M
query_cache_size=16M
query_cache_type=2
thread_concurrency=32

user=mysql

symbolic-links=0

plugin-load=archive=ha_archive.so;blackhole=ha_blackhole.so

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[mysql]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

哇，您有一些功能强大的硬件可以解决此问题。除了升级到Sandy / Ivy Bridge CPU以获得比Btree搜索更好的性能20-50％的性能外，您可以在硬件方面投入更多的资源。

请注意，我的专长是Innodb，所以我将

1. 忽略您是myisam并采取行动，就好像别无所求。
2. 假设此问题足以推动您升级。是的，这是升级。

通过将这些经常访问的行存储在其缓冲池中，Innodb可以帮助充分利用所有内存。您可以将其调整为所需的大小（例如80％的内存），并且新的读/写将保留在内存中，直到需要将它们推入磁盘以为最新访问的数据腾出更多空间为止。内存中的速度比FusionIO快一个数量级。

Innodb还有许多其他功能，例如自适应哈希，自动增量锁定机制等，它们可以为您的环境带来好处。但是，您比我更了解您的数据。

在innodb的世界中，一个好的短期解决方案是优化您的从属服务器-您真的需要与从属主机上的每个索引一样的主机吗？索引是插入/更新/删除的球状链，即使使用Fusion IO卡也是如此。IOPS并不是这里的全部。Sandy / Ivy Bridge proc具有更好的内存吞吐量和计算性能-它们可以使您现在拥有的Westmeres产生巨大的变化。（图总体占20-50％）。删除从属服务器上不需要的所有索引！

其次，几乎可以肯定，它仅适用于innodb，这是mk-prefetch可以知道哪些更新以及从属写入它们之前。这允许mk-prefetch首先运行读取查询，从而在单个repl运行写入查询时强制将数据存储在内存中。这意味着数据在内存中，而不在FusionIO中，这是快速数量级的性能提升。这带来了巨大的变化，这可能超出人们的预期。许多公司将其用作永久解决方案。通过查看Percona Toolkit了解更多信息。

第三，也是最重要的是，一旦您升级到Innodb，一定要结帐Tokutek。这些家伙有一些非常棒的东西，远超Innodb的写入/更新/删除性能。他们吹捧提高复制速度是关键优势之一，您可以从他们的基准测试中看出，对于Btrees而言，为什么Fusions疯狂的IOPS 仍然无法为您提供帮助。（注意：我没有独立验证。）它们使用直接替换btree索引的方法，虽然丑陋得多，但可以改善btree索引的许多算法速度限制。

我正在考虑采用Tokutek。如果他们释放了这么多写速度，那我就可以添加更多索引。由于它们以如此出色的比率（它们引用的25倍）压缩数据和索引，因此您甚至不必为增加的数据付出（性能，维护）价格。不过，您确实需要为他们的引擎付费（$），每预压缩GB，IIRC每年$ 2500。如果您复制了数据，它们将提供折扣，但是您甚至可以仅在从属服务器上安装Tokutek并保持原样保留主服务器。在MIT Algoritms开放课件讲座中查阅技术细节。另外，对于没有1:20观看视频的用户，他们在博客上还有大量技术文章和常规白皮书。我相信这段视频也为Big-O公式提供了快速的读取速度。我有假设读取速度较慢（总会有一个权衡！），但是公式对于我来说太复杂了，无法衡量多少。他们声称这大致相同，但是我宁愿理解数学（不太可能！）。您可能比我更容易发现这一点。

附言：我与Tokutek不隶属，我从未经营过他们的产品，他们甚至不知道我在看他们。

更新：

我看到您在此页面上还有其他问题，并认为我会参与其中：

首先，除非您有特殊的环境，否则从机预取几乎肯定不会对myisam起作用。这主要是因为预取将锁定您要写入的表，或者从属线程已锁定了预取守护程序所需的表。如果您的表在复制方面非常平衡，并且以循环方式写入不同的表，则可能会起作用-但请记住，这是非常理论性的。《高性能MySQL》一书在“复制问题”部分中提供了更多信息。

其次，假设您的从服务器负载为1.0-1.5，如果您正在运行其他proc或查询但基线为1.0，则负载可能会更高。这意味着您可能受CPU限制，而您的FusionIO可能也受此限制。正如我前面提到的，Sandy / Ivy Bridge会给人以更大的吸引力，但可能不足以使您以最短的滞后度过艰难的时期。如果此从站上的负载主要是只写的（即读取次数不多），则您的CPU几乎肯定会花费时间来计算btree插入/删除的位置。这应该加强我上面关于删除非关键索引的观点-您以后可以随时重新添加它们。禁用超线程将不起作用，更多的CPU不是您的敌人。一旦达到32GB以上的RAM（例如64GB），您就需要担心RAM的分配，但即使如此，症状也有所不同。

最后，也是最重要的一点（不要跳过这一部分；）），我假设您现在正在运行RBR（基于行的复制），因为您在切换时也提到了不小的性能提升。但是，这里可能有一种方法可以提高性能。如果您复制的表没有主键，则Mysql错误53375会显示出来。从属服务器基本上没有足够的智能来使用除主键以外的任何内容，因此，缺少主密钥将迫使复制线程对每次更新进行全表扫描。解决方法只是添加一个良性的替代自动增量主键。如果表很大（例如几万行或更大的几万行），我只会这样做。当然，这是以在表上再建一个索引为代价的，这将增加您在CPU中支付的价格。请注意，很少有理论上的人反对这一点，因为如果您不这样做，InnoDB会在幕后添加一个。幻象之一，然而，是不是针对53375.钨一个有用的防御也可以克服这个问题，但你需要使用钨时，你有你的编码直是肯定的。我上一次使用它时，任何非UTF8字符串都需要复制时，它将可怕地死掉。那是我放弃的时间。

不能解决问题，但您可以考虑使用钨复制器及其商业产品以提高灵活性。是单核上100％cpu的使用率是瓶颈吗？

因此，如果您要在从属服务器上进行备份，并且使用了myiasm表，那么您将锁定表以进行备份以防止损坏。因此，复制要等到备份完成后才能进行。然后它赶上了。