MySQL 复制性能

Question

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

最近当我们需要暂停复制大约时，这个问题是一个大问题。3小时。在没有其他负载的情况下，大约需要 10 个小时才能再次赶上。

如何提高复制的性能？机器 B 基本上是空闲的（很少，IO，16 个内核中有 2 个最大化，大量空闲 RAM），因为只有 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

Answer 1

哇，你有一些非常强大的硬件来解决这个问题。除了升级到 Sandy/Ivy Bridge CPU 以从 Btree 搜索等中提高 20-50% 的性能外，没有更多的硬件可以投入使用。

请注意，我的强项是 Innodb，所以我要

1. 忽略你是 myisam 并表现得好像它不会有什么不同。
2. 假设这个问题足以促使您升级。是的，它是一个升级。

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

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

在innodb 世界中，一个好的短期解决方案是优化你的slave——你真的需要你的slave 上的所有索引吗？索引上插入/更新/删除一个球和链，EVEN与融合IO卡。IOPS 并不是这里的一切。Sandy/Ivy 桥接 procs 具有更好的内存吞吐量和计算性能 - 它们可以使您现在拥有的 Westmere 产生巨大差异。（图 20-50% 总体）。删除从站上不需要的所有索引！

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

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

我正在考虑采用 Tokutek。如果它们释放了如此多的写入速度，那么我就可以添加更多索引。由于它们以如此出色的比率（他们引用的 25 倍）压缩数据和索引，因此您甚至无需为增加的数据支付（性能、维护）价格。不过，您确实为他们的引擎支付了 ($)，每个预压缩 GB、IIRC 每年 2500 美元。如果您复制了数据，他们有折扣，但您甚至可以在您的从站上安装 Tokutek 并保持您的主站原样。查看麻省理工学院算法开放课件讲座中的技术细节。或者，他们的博客上有大量技术资料，并为那些没有 1:20 时间观看视频的人提供常规白皮书。我相信这段视频还给出了读取速度的 Big-O 公式。我有假设读取速度较慢（总有一个权衡！），但公式太复杂了，我无法衡量多少。他们声称它大致相同，但我宁愿理解数学（不太可能！）。你可能比我更好地发现这一点。

Ps 我不隶属于 Tokutek，我从未运行过他们的产品，他们甚至不知道我在看他们。

更新：

我看到你在这个页面上还有其他一些问题，我想我会插话：

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

其次，大概你的奴隶持有 1.0-1.5 的负载，如果你有其他 procs 或查询运行，但基线为 1.0，它可能会更高。这意味着您可能受 CPU 限制，这可能与您的 FusionIO 相关。正如我之前提到的，Sandy/Ivy Bridge 将提供更多魅力，但可能不足以让您以最小的延迟度过艰难时期。如果此从站上的负载主要是只写（即读取次数不多），则您的 CPU 几乎肯定会花时间计算 btree 插入/删除的位置。这应该加强我上面关于删除非关键索引的观点 - 您可以随时重新添加它们。禁用超线程将不起作用，更多的 CPU 不是你的敌人。一旦超过 32GB 内存，比如 64GB，你需要担心内存分配，但即便如此，症状也有所不同。

最后，也是最重要的（不要跳过这一部分；）），我假设您现在正在运行 RBR（基于行的复制），因为您提到了切换时性能的显着提高。但是 - 可能有一种方法可以在这里获得更高的性能。如果您在没有主键的情况下复制表，则可能会出现Mysql 错误 53375。从属基本上不够聪明，只能使用主键以外的任何东西，因此缺少主键会迫使复制线程对每次更新进行全表扫描. 解决方法是简单地添加一个良性的、代理自动递增的主键。我只会在表格很大的情况下这样做（比如几千行或更大的几十行）。当然，这是以在表上有另一个索引为代价的，这会提高您在 CPU 中支付的价格。请注意，反对这一点的理论论据很少，因为如果您不这样做，InnoDB 会在幕后添加一个。然而，幻象对 53375 并不是一个有用的防御。钨也可以克服这个问题，但是在使用钨时你需要确保你的编码是直接的。我上次玩它时，当任何非 UTF8 字符串需要复制时，它都会死得很惨。那是我放弃它的时候。