这个问题不在于如何解决复制问题,而是要找出复制速度慢所导致的bug。为了提高性能,我们不希望所有查询都是同步的,只希望将查询标识为关键读取。
我们的galera集群上有时会出现关于同步的bug。例如,我们的web应用程序在写入数据后执行重定向,但在下一页上显示过期状态。在开发环境上我们没有这些问题。在具有某些服务器负载的生产环境中,如果读取几毫秒前写入的数据,则另一个节点有时不同步。
为了解决这个问题,我们使用节点钉住进行关键读取,从以前编写的同一个节点进行读取,我们正在进行实验 SET SESSION wsrep-sync-wait=6;
对于这里描述的insert/updates/delete,避免减少这种行为(现在使用rick james提到的位“1”)。
如何测试复制速度慢导致的错误?
我们的想法是模拟一个非常慢的同步来测试我们的应用程序的关键读取行为。是否有一些配置选项可以让galera集群在重载下像这样工作?galera有一个内置的流控制来减慢速度,但是我找不到可靠的方法来强制集群进入流控制。这个解决方案不必仅仅依赖mysql,一个缓慢的虚拟卷加上类似“innodb\u flush\u method”的东西可能也会有帮助。
(更新以改进问题)
2条答案
按热度按时间pexxcrt21#
设置地理上分散的群集。也许可以为远程节点使用云服务。
如果每个节点位于不同的大陆,则每个节点的往返延迟为100-200ms
COMMIT
.iyr7buue2#
你需要包括
1
因为你在读书。