我使用本地后端连接在同一数据中心内configuration了两台master-master复制的MySQL服务器（ MySQL-1 ， MySQL-2 ），其中包含以下选项：
innodb_flush_log_at_trx_commit=1 sync_binlog=1
我们使用一个负载均衡器在两台MySQL服务器之间来回地循环MySQL请求。 这很好，但我担心复制滞后。 例如，如果用户A在MySQL-1中插入一行，则用户A从MySQL-2中select数据可能没有被成功复制。
基本上，我的问题是，应该有多less滞后（毫秒，秒）？ 他们是否已经设置了MySQL选项来防止/减less延迟？
这取决于您的服务器性能，这与每个服务器需要处理多less个查询有关，您的表有多大，等等。 使用这种复制解决scheme应该是同步的，这在交易过程中肯定会造成一些延迟。 这只是因为每个事务都不应该被视为完全提交，除非在两个节点上都这样做。
我认为一个更安全的select是平衡基于客户端源IP的请求（如果支持/可能的话）。 在这种情况下，来自同一客户端的所有请求都将被转发到同一个数据库服务器。
我遇到了这个问题与主 – >许多奴隶安装。 这比你的情况还要糟糕，因为读取保证来自奴隶，而不是有50/50的机会。
每当用户写入数据库（如论坛post或点击“喜欢”button），他们会得到一个HTTPredirect到页面， 应该显示他们的post，但它从来没有。 redirect和后续请求的往返时间短于复制滞后。
观看SHOW SLAVE STATUS的滞后表明，它几乎总是在一秒钟之内。 但是，它确实得到了比偶尔更高。 由于复制SQL是单线程的，10秒的慢查询会导致复制滞后10秒。
我们的解决scheme最终修改了所有“刚刚发布”的页面，以便始终从主服务器而不是从服务器进行读取。 在你的情况下，确保每个Web服务器都知道前一个请求写入哪个数据库将是困难的。
更好的解决scheme可能是将最近写入的数据保存到memcached实例中。 即使你的memcached数据有10秒的到期时间，这应该足以弥补复制滞后。
滞后取决于主要来自：
以前不可能计算滞后。 我可以build议做一些密集（为你）与并发写testing读操作。