我运行的服务需要能够支持大约 4000+ IOPS 并保持副本滞后 <=1 second to function properly.
我正在使用 AWS RDS MySQL 实例并有 2 个只读副本。我的服务在只读副本上遇到了巨大的副本延迟峰值,因此我与 AWS 支持人员联系了一周,试图了解为什么我会遇到延迟 - 我配置了 6000 IOPS,而且我的实例非常强大。他们给了我各种各样的理由。
更改实例类型、从 5.5 升级到 MySQL 5.6 以利用多线程并替换底层硬件后,我仍然随机看到明显的副本滞后。
最终,我决定开始修改参数组,更改只读副本的配置,我可以找到涉及复制过程的任何内容,现在终于体验到了<= 1 second of replica lag.
以下是我更改的设置及其似乎成功的值(我复制了默认的 mysql 5.6 参数组,并更改了这些值,将更新的参数组应用到只读副本):
innodb_flush_log_at_trx_commit=0
sync_binlog=0
sync_master_info=0
sync_relay_log=0
sync_relay_log_info=0
请阅读每一项内容以了解修改的影响:http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html
其他需要注意的事项:
Convert any MyISAM tables to InnoDB
Upgrade from MySQL < 5.6 to MySQL >= 5.6
Ensure that your provisioned IOPS are > the combined read/write IOPS you require
Ensure that your read replica instances are >= master instance
如果其他人有任何可以在只读副本或主数据库上修改的其他参数以获得最佳复制性能,我很想听到更多信息。
更新2014年7月8日
为了利用我设置的Mysql 5.6多线程复制:
slave_parallel_workers=5 (Set it to the number of read replica DBs you have running)
我在这里找到了这个:
https://blogs.oracle.com/MySQL/entry/benchmarking_mysql_replication_with_multi
Mysql 复制按顺序在单个数据库上执行所有事务,而 master - 可以并行执行这些事务。
您可能在单个 DA 上执行大部分更新,这就是不允许您利用多线程复制的原因。
检查副本服务器上的
iostat
。大多数时候这些问题的发生是因为机器上的高IO。
为了减少机器上的 IO - 您可以进行一些额外的更改:
增加
innodb_buffer_pool_size
- 这是您应该更改默认值的第一件事。如果此实例仅运行 mysql - 您可以在此处分配大约 80% 的可用内存。同时验证以下参数:
log_slave_updates = false
binlog_format = STATEMENT
(如果您配置了 MIXED 或 ROW binlog_format - 从这里验证您是否理解这意味着什么 http://dev.mysql.com/doc/refman/5.6/en/binary-log-setting.html
如果您有大量数据被多次更改 - 增加
innodb_max_dirty_pages_pct
到 90 或 95% 值得检查。经过多年一致的数据库负载后,我出现了极大的延迟。为了解决这个问题,除了原始帖子中的设置外,我还必须添加:
binlog_format=ROW
slave_rows_search_algorithms=TABLE_SCAN,INDEX_SCAN
这篇转发文章中推荐了这些。重启后延迟很快就消失了