sql线程的重放是否真正能100%没问题呢？冲突和延迟真正解决了吗？
本帖最后由 xtjsxtj 于 2015-04-20 08:13 编辑以前5.5的半同步，后来innosql和现在的mysql5.7也只是保证了io线程binlog的不延时吧？不管怎样它还是半同步，并非强一致。sql线程的重放是否真正能100%没问题呢？冲突和延迟真正解决了吗？即使是并行复制能实时的上跟上主库的变更吗？
举个极端情况的例子，主备同时连接，主库写后马上去重库读，大量压力测试下，是否备库总能读到正确数据呢？
看了下全复制，只是让IO线程等待SQL线程的执行，再唤起IO线程读event，那IO线程等待的时候，event不是又变多了吗，这个不能解决主从的完全时实吧
还有安全复制，这个应该是解决了最终一致性，数据是不会丢失，如果主库并发写的压力很大的话，从库还是有落后的可能
真正的完全同步，是不是应该等到从库SQL也一起提交了，才返回应答给master呢，当然这样性能是个问题
用行动说话，顶起没商量
延迟问题，等从库执行完了主库再返回，恐怕性能就不行了。
只能在应用层或者商业逻辑层解决，比如这个用户/session刚刚写过，那么10秒内都分给到主库的链接。
或者是直接决定你们商业上用户能接受一点不一致，刷新一下就好了。
页:
[1]