binlog的大量增长，单机的数据库读写分离能解决？

最新推荐文章于 2024-04-21 21:57:33 发布

Kevins Danish

最新推荐文章于 2024-04-21 21:57:33 发布

阅读量813

点赞数

本文链接：https://blog.csdn.net/weixin_36708538/article/details/81346853

版权

场景

在一个机器上只有一个mysql实例，对它既读又写，通过top、df –h和free –m来检查，发现磁盘空间满了。再进一步通过du –sh对可以的目录进行检查，发现是mysql的binlog占用空间过大。binlog的大量增长占用了较多的磁盘和cpu，导致每次数据库的connection有些缓慢

主从复制读写分离

1、读写分离

读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。
但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。所以读写分离，解决的是，数据库的写入，影响了查询的效率。

数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库主从同步。可以减少数据库压力，提高性能。当然，数据库也有其它优化方案。memcache 或是表折分，或是搜索引擎。都是解决方法。

2、主从复制

mysql主从复制是对数据库中的数据、语句做备份。
这里写图片描述

mysq支持的复制类型

基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。
基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。
混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

复制的工作过程(异步复制)

在每个事务更新数据完成之前，master在二进制日志记录这些改变。写入二进制日志完成后，master通知存储引擎提交事务。
Slave将master的binary log复制到其中继日志。首先slave开始一个工作线程（I/O），I/O线程在master上打开一个普通的连接，然后开始binlog dump process。binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件，I/O线程将这些事件写入中继日志。
Sql slave thread（sql从线程）处理该过程的最后一步，sql线程从中继日志读取事件，并重放其中的事件而更新slave数据，使其与master中的数据一致，只要该线程与I/O线程保持一致，中继日志通常会位于os缓存中，所以中继日志的开销很小。

这里写图片描述

前较为常见的Mysql读写分离分为以下两种：
1）基于程序代码内部实现在代码中根据select 、insert进行路由分类
2）基于中间代理层实现代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到，后端数据库，有以下代表性的程序。mysql_proxy,Atlas,Amoeba (自行了解)

很明显在场景中单机电脑因为binlog的大量增长导致的数据库性能降低，如果不增加机器，靠单机读写分离是提升不了多大的性能的，因为cpu和磁盘的限制摆在那里，同时有可能因为主从更新占用cpu或者主从同步延迟带来的数据的不一致导致业务失败，所以我认为还是要从以下方面思考

·进行mysql读写分离(是否更新少，查询多？是的话会考虑使用)
·通l过设置binlog_row_image=minimal 减少每一条log大小在还没搞读写分离之前可以先开启，或者开启log的自动删除，通过设置日志保留时长 expire_logs_days 自动删除
·数据库连接慢有可能包含了数据sql语句查询慢，分析sql优化语句 ·缓存层可以对读做点事情

mysql主从同步延迟原理：
主库针对写操作，顺序写binlog，从库单线程去主库顺序读”写操作的binlog”，从库取到binlog在本地原样执行（随机写），来保证主从数据逻辑上一致。
mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率比较高，下一步，问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。
有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。

非要实现数据库主从复制读写分离请参考以下链接
https://blog.csdn.net/justdb/article/details/17331569
读写分离实现一
https://blog.csdn.net/jaryle/article/details/52002727
读写分离实现二
https://my.oschina.net/xiaowangqiongyou/blog/1808561
单机实现数据库读写分离