slave库写redo、binlog不实时丢数据的场景

1.slave涉及相关文件

  slave读取master的binlog日志后,需要落地3个文件:relay log、relay log info、master info:

relay log:      即读取过来的master的binlog,内容与格式与master的binlog一致
relay log info: 记录SQL Thread应用的relay log的位置、文件号等信息
master info:    记录IO Thread读取master的binlog的位置、文件号、延迟等信息

如果当这3个文件如果不及时落地,则主机crash后会导致数据的不一致。

2.信息存储方式

在MySQL 5.6.2之前,slave记录的master信息以及slave应用binlog的信息存放在文件中,即master.info与relay-log.info。在5.6.2版本之后,允许记录到table中,参数设置如下:

master-info-repository  = TABLE
relay-log-info-repository = TABLE   

对应的表分别为mysql.slave_master_info与mysql.slave_relay_log_info,且这两个表均为innodb引擎表。

3.控制刷新参数

relay log、relay log info与master info还有3个参数控制刷新:

•sync_relay_log:默认为10000,即每10000次sync_relay_log事件会刷新到磁盘。为0则表示不刷新,交由OS的cache控制。
•sync_relay_log_info:若relay_log_info_repository为FILE,当设置为0,交由OS刷新磁盘,默认为10000次刷新到磁盘;若relay_log_info_repository为TABLE,且为INNODB存储,则无论为任何值,则都每次evnet都会更新表。
•sync_master_info:若master-info-repository为FILE,当设置为0,则每次sync_master_info事件都会刷新到磁盘,默认为10000次刷新到磁盘;若master-info-repository为TABLE,当设置为0,则表不做任何更新,设置为1,则每次事件会更新表 默认为10000

4.建议参数设置

sync_relay_log = 1
sync_master_info = 1
sync_relay_log_info = 1
master-info-repository  = TABLE
relay-log-info-repository = TABLE     

当这样设置,导致调用fsync()/fdatasync()随着master的事务的增加而增加,且若slave的binlog和redo也实时刷新的话,会带来很严重的IO性能瓶颈。

时间: 2024-12-27 13:15:23

slave库写redo、binlog不实时丢数据的场景的相关文章

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

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

InnoDB undo, redo,binlog,data什么时候写?

undo:相当于数据修改前的备份 redo: 相当于数据修改后的备份,为了保证事务的持久化,redo会一直写 Undo + Redo事务的简化过程  假设有A.B两个数据,值分别为1,2.  A.事务开始.  B.记录A=1到undo log.  C.修改A=3.  D.记录A=3到redo log.  E.记录B=2到undo log.  F.修改B=4.  G.记录B=4到redo log.  H.将redo log写入磁盘.  I.事务提交 - Undo + Redo事务的特点  A. 为

一次Mysql slave库恢复实战记录

状况描述:今天登录一个mysql数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件,最早的文件创建日期甚至是2018年,我记得在slave同步完master的日志操作记录后,会删除这些文件(默认设置不会删除,我记错了).查看mysql slave状态,发现如下报错: mysql> show slave status\G; *************************** 1. row ***************************

利用当天的xtrabackup全量备份文件搭建slave库

环境: 单台机器开启2个mysql实例 3306和3307,3306 和3307实例都开启了Gtid,并且要保证server-id不同 全量备份命令: time innobackupex --defaults-file=/data/mysql5.7/my3306.cnf -ubackupuser -p123456ccs --host=127.0.0.1 -S /tmp/3306.sock /data/backup/ 当天的xtrabackup全量备份文件记录的binlog的位置点: [[emai

使用Percona Xtrabackup创建MySQL slave库

MySQL Server 版本: Server version: 5.7.10-log MySQL Community Server (GPL) Percona Xtrabackup 版本: innobackupex version 2.4.2 Linux (x86_64) (revision id: 8e86a84) 说明: [master]:表示在master库上执行的语句 [slave]:表示在slave库上执行的语句 --执行master库的全备[master]innobackupex

mysql recovery 1 (允许停机,不许丢数据)

1.备份策略: 1)按天备份: 优点:恢复时间短,维护成本低 缺点:占用空间大,占用资源多(比如说老是要锁表) 2)按周备份: 优点:占用空间小,资源占用低 缺点:维护成本大 2.增量恢复的场景 1)数据库迁移,或者跨机房灾备. 2)增加从库. 3)认为操作失误,从库也没办法. 3.案例(可以停机,但是不能丢数据) 1)增量,全备开启 [[email protected] ~]# grep log-bin /etc/my.cnf log-bin=mysql-bin mysqldump -uroo

如何快速做一个山寨的实时“大数据”处理

前言为啥写这篇文章?因为我现在做的这套实时计算系统在公司里很难玩下去了.去年年初来到ctrip,主要就是做两个实时应用,一个是实时报警,功能是做出来了,但应用效果不好:一个是XXX(敏感应用,不敢写出来,以XXX代替),也是实现了功能需求,但想继续按自己的思路往下走是不可能了,我捉急的表达能力很难让上头去理解实时计算和传统的request-response方式的应用不同点在哪里,为啥要这么干,也很难明白上头喜欢的系统是什么样的,真是挠破头.我的方式看来是做不下去了,但总觉得还是有点价值,所以写下

MongoDB丢数据问题的分析

坊间有很多传说MongoDB会丢数据.特别是最近有一个InfoQ翻译的Sven的一篇水文(为什么叫做水文?因为里面并没有他自己的原创,只是搜罗了一些网上的博客,炒了些冷饭吃),其中又提到了丢数据的事情.大家知道作为一个数据库来说,数据的持久性基本上是数据库的最低要求了.如果MongoDB真的有那么糟糕的数据安全问题,它早就在技术选择众多的今天被无情地淘汰掉了.那么真相到底如何呢? 实事求是地来说,MongoDB确实在其发展的过程中,有一些数据持久化的问题没有处理好,特别是一些默认值的选定上.大部

百度地图云麻点之批量上传、实时显示数据篇

上篇博文你可能用到的百度地图效果(付源码)介绍了几个比较实用的百度地图特效,其中重点介绍了海量数据上传及响应的问题,前端展示可以通过LBS云麻点来展示,通过这个可以解决批量数据Marker响应特慢的性能问题.首先在百度云服务器上建完表之后,我们可以通过后台的管理平台直接把数据传上去,作为我们的初始数据.这部分数据有了之后,接下来要做的就是想办法手动同步数据,更智能一点就是实时同步数据,接下来就带你一步步实现这个过程. 这次在正文开始之前,我想先做一次吐槽君.最近压力有点儿大,先来发一下牢骚.三人