缓解MySQL写入压力和主从延迟的尝试

缓解MySQL写入压力和主从延迟的尝试

http://mp.weixin.qq.com/s?__biz=MzA5Njg5ODMzMg==&mid=208512935&idx=1&sn=a605bb3b2f944f7fdce820b940e0888b&scene=2&from=timeline&isappinstalled=0#rd

最近单位需要用MySQL存放大量的日志数据.
写入压力很大,并且有很大的主从延迟.

具体环境如下
MySQL 5.6.14
服务器(单CPU,6核心,12线程 32G内存)
服务器硬盘(共33T,Raid5)


1第一个尝试,分散IO

一般我们使用/dbdata挂载点存放数据文件
/data挂载点存放日志文件(redo log file,binlog,relay log等)
这样的好处是将随机IO和顺序IO分开,不形成争用.

缺点是/data挂载点的IO使用率一般较低.

当然,这种情况在一般用途的数据库并无大碍.

但是在Insert密集的数据库,数据文件所在的物理设备使用率会一直保持在100%.而日志文件所在的物理设备使用率一般也就是5%左右,甚至更低.

这时,也许可以考虑将一部分表的数据文件移动到日志文件所在的物理设备,以平衡IO资源使用.

MySQL的datadir在/dbdata挂载点,
police_im_user_mac数据库通过软链接,实际指向/data的挂载点.
这样,会将一部分的随机IO分散到/data挂载点,减轻/dbdata挂载点的压力,并且减小了CPU的等待



2第二个尝试,一个库一个表

因为MySQL 5.6的多线程复制是基于数据库的.
而我们每个表的写入压力都很大,所以修改了结构,每个数据库只有一个表.然后启动多线程复制(实际上就是多个SQL线程),并且设置传输压缩

slave_compressed_protocol=on （Master,Slave都需要配置）slave_parallel_workers=10



3第三个尝试,修改参数

innodb_flush_log_at_trx_commit = 0
innodb_support_xa=0
sync_binlog=0
增加innodb_buffer_pool_size
将innodb_max_dirty_pages_pct设置的更大
将redolog file size设置的更大

经过这些修改,写入压力和主从延迟有了很大的缓解.
但是启动slave_parallel_workers,一旦出现SQL线程异常导致的复制中断,恢复之后,可能会出现1062号错误

这是因为多SQL线程的线程同步机制可能有问题,一旦复制中断,现象上看,等同于Slave异常关机.

时间： 2024-10-10 14:14:25

缓解MySQL写入压力和主从延迟的尝试的相关文章

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍 从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

实时刷新缓存-处理mysql主从延迟的一些设计方案

概要: 在项目开发当中,经常有这样一种场景,对数据库进行添加.修改.删除操作的应用直接连接master库,只对数据库进行查询的应用,会先建立一个中央缓 存,例如redis或者memcache,如果缓存没有命中,那么直接访问slave库.下文会介绍一下在刷新中央缓存时,如果发生主从延迟,应该如何处 理.也即是,当应用System-A 把数据库写入master库的时候,System-B应用在读取slave库的时候,master库的数据还没同步到slave库,如果这个时候刷新缓存 的话,会直接把旧的数

MySQL 主从延迟几万秒 Queueing master event to the relay log（转）

数据库版本Server version:    5.6.24-log Source distribution 问题描述 数据采集平台业务数据库由于批量灌数据导致主从延迟上万秒. 复制线程长期处于Queueing master event to the relay log状态. 监控数据显示1.Seconds_Behind_Master 维持在6w秒左右,且有上升趋势.2.主库有大量的binlog积压无法同步到从库,但主从库的网卡流量都很低远未达到瓶颈.3.从库的qps与tps很低,维持在几百左右

MySQL主从延迟现象及原理分析详解

一.现象 凌晨对线上一张表添加索引,表数据量太大(1亿+数据,数据量50G以上),造成主从延迟几个小时,各个依赖从库的系统无法查询数据,最终影响业务. 现在就梳理下主从延迟的原理. 二.原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述,MySQL 主从复制依赖于三个线程:一个线程(),两个线程(和).主从复制流程如下图: master 服务器和 slave 服务器连接时,创建以发送数据: 一个对应一个 slave 服务器

MySQL 主从延迟复制方法总结

mysql 5.6开始已经支持主从延迟复制,可设置从库延迟的时间.延迟复制的意义在于:主库误删除对象时,在从库可以查询对象没改变前状态. 方法介绍 1.percona公司pt-slave-delay工具 主库: [[email protected] ~]$ login Logging to file '/tmp/master.log' Warning: Using a password on the command line interface can be insecure. Welcome

专职DBA-MySQL主从延迟复制

专职DBA-MySQL主从延迟复制 本次实验环境延用MySQL主从异步复制的搭建环境 mysql集群企业级架构方案 1.根据对数据库的访问请求实现读写分离(读从写主) 2.根据不同的业务拆分多个从库以提供访问 一主五从 3从提供外部用户读请求访问(读写分离.LVS负载均衡) 1从用于内部用户读访问(业务后台.数据分析.搜索业务.财务统计.定时任务.开发查询等) 1从用于数据库定时全备份,以及增量备份(开启binlog) 3.实现对主库的高可用 (1).heartbeat+dbrd+mysql方案

Mysql丢数据及主从数据不一致的场景

Mysql丢数据及主从数据不一致的场景 随着对MySQL的学习,发现了MySQL的很多问题,最重要的就是丢数据的问题.对于丢数据问题,我们应该了解丢数据的场景,这样在以后的学习中多考虑如何去避免及解决这些问题. 1.MySQL数据库层丢数据场景   本节我们主要介绍一下在存储引擎层上是如何会丢数据的. 1.1.InnoDB丢数据   InnoDB支持事务,同Oracle类似,事务提交需要写redo.undo.采用日志先行的策略,将数据的变更在内存中完成,并且将事务记录成redo,顺序的写入red

MYSQL的读写分离主从延时问题

如何实现 MySQL 的读写分离? 其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去. MySQL 主从复制原理的是啥? 主库将变更写入 binlog 日志,然后从库连接到主库之后,从库有一个 IO 线程,将主库的 binlog 日志拷贝到自己本地,写入一个 relay 中继日志中.接着从库中有一个 SQL 线程会从中继日志读取 binlog,然后执行 binlog 日志中的内容,也就是在自己本地再次执行一遍 S

MySQL的3节点主从同步复制方案测试

上接<MySQL的3节点主从同步复制方案> 六．测试主从同步复制 现在我们来测试下,mysql的主从同步. 1.在主库插入测试数据 先在主库MasterA 上给m_s_rep数据库插入和删除2条数据.如下: mysql> insert into test(id,content) values(3,'data3'); mysql> insert into test(id,content) values(2,'data2'); mysql> select * from test;