mysql一主多从怎么做 mysql 主从一致性方案

mysql一主多从,读取走的是什么库1,MySQL 使用3 个线程来执行复制功能(其中1 个在主服务器上 , 另两个在从服务器上 。当从服务器发出START SLAVE时,从服务器创建一个I/O线程,以连接主服务器并让主服务器发送二进制日志 。主服务器创建一个线程将二进制日志中的内容发送到从服务器 。从服务器I/O 线程读取主服务
器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中,即中继
日志 。第3个线程是SQL 线程,从服务器使用此线程读取中继日志并执行日志中包含的更新 。
2 , 如1所述,主服务器收到从服务器的同步请求后,开始向从服务器发送二进制日志
3,附件的文档可以参考下
注:你使用java程序同步数据,先不说java的效率,仅仅全部sql都同步到从表再顺序执行就有问题,反复查库,插数据,还有数据不一致的问题 , 如insert into tab values (now())等等 。
MySQL 主从 , 5 分钟带你掌握MySQL 主从一直是面试常客,里面的知识点虽然基础,但是能回答全的同学不多 。
比如楼哥之前面试小米,就被问到过主从复制的原理,以及主从延迟的解决方案,因为回答的非常不错,给面试官留下非常好的印象 。你之前面试 , 有遇到过哪些 MySQL 主从的问题呢?
所谓 MySQL 主从,就是建立两个完全一样的数据库,一个是主库,一个是从库,主库对外提供读写的操作,从库对外提供读的操作,下面是一主一从模式:
对于数据库单机部署,在 4 核 8G 的机器上运行 MySQL 5.7 时,大概可以支撑 500 的 TPS 和 10000 的 QPS,当遇到一些活动时,查询流量骤然,就需要进行主从分离 。
大部分系统的访问模型是读多写少,读写请求量的差距可能达到几个数量级 , 所以我们可以通过一主多从的方式,主库只负责写入和部分核心逻辑的查询,多个从库只负责查询,提升查询性能,降低主库压力 。
MySQL 主从还能做到服务高可用,当主库宕机时,从库可以切成主库,保证服务的高可用,然后主库也可以做数据的容灾备份 。
整体场景总结如下:
MySQL 的主从复制是依赖于 binlog 的,也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件 。
主从复制就是将 binlog 中的数据从主库传输到从库上,一般这个过程是异步的,即主库上的操作不会等待 binlog 同步的完成 。
详细流程如下:
当主库和从库数据同步时 , 突然中断怎么办?因为主库与从库之间维持了一个长链接,主库内部有一个线程,专门服务于从库的这个长链接的 。
对于下面的情况,假如主库执行如下 SQL,其中 a 和 create_time 都是索引:
我们知道 , 数据选择了 a 索引和选择 create_time 索引,最后 limit 1 出来的数据一般是不一样的 。
所以就会存在这种情况:在 binlog = statement 格式时,主库在执行这条 SQL 时,使用的是索引 a,而从库在执行这条 SQL 时,使用了索引 create_time,最后主从数据不一致了 。
那么我们改如何解决呢?
可以把 binlog 格式修改为 row,row 格式的 binlog 日志记录的不是 SQL 原文,而是两个 event:Table_map 和 Delete_rows 。
Table_map event 说明要操作的表,Delete_rows event用于定义要删除的行为,记录删除的具体行数 。row 格式的 binlog 记录的就是要删除的主键 ID 信息 , 因此不会出现主从不一致的问题 。
但是如果 SQL 删除 10 万行数据,使用 row 格式就会很占空间的,10 万条数据都在 binlog 里面,写 binlog 的时候也很耗 IO 。但是 statement 格式的 binlog 可能会导致数据不一致 。

推荐阅读