MySql-Binlog在MySql主从不同方面发挥着不可或缺的作用，同时我们也能通过Binlog实时监控数据的变化。本系列就讲述了怎样接收并解析Binlog。本篇就主要对接收binlog的流程做了一下探讨。
假设主备切换前，我们的主库是节点A，节点B是节点A的备库，客户端的读写都是直接访问节点A，节点B只是将A的更新同步过来然后本地执行，同步完成以后，节点AB的数据就一致了。
虚拟机环境：VirtualBox 6.0.24 操作系统：Oracle Linux Server release 6.5 x86_64 MySQL版本：5.7.33
分库分表就是我们把一个大表拆开分到不同的数据库实例上，比如将一个大表bt按照字段id（分区key）拆分成32个库中。分区key的选择尽量减少跨库和跨表查询。
备份主库时一般使用mysqldump命令 加上--master-data参数可得到起始点
修改my.ini配置文件(windows下在ProgramData文件夹的MySql文件夹下),新增修改如下配置:
墨墨导读：经常会看到看到cpu 使用率非常高的情况。在这种情况下，资源的使用监控分析才是性能故障分析的根本首要任务，通过这些分析，理解服务器如何运行，资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的。
一、什么是 GTID GTID （Global Transaction Identifiers）是对于一个已提交事务的编号，事务的唯一编号，并且是一个全局唯一的编号。GTID 和事务会记录到 binlog 中，用来标识事务。 GTID 是用来替代以前 classic 复制方法，MySQL-5.6.2 开始支持 GTID，在 MySQL-5.6.10 后完善。 有了 GTID，一个事务在集群中就不再孤单，在每一个节点中，都存在具有相同标识符的兄弟们和它作伴，可以避免同一个事务，在同一个节点中出现多次的情况。 GTID 的出现，最直接的效果就是，每一个事务在集群中具有了唯一性的意义，这在运维方面具有更大的意义，因为使用 GTID 后再也不需要为了不断地找点而烦恼了，给 DBA 带来了很大的便利性。
这是今年3月份整理的一篇博客，在做业务过程中又有了一些新的理解，所以重新进行了梳理，增加了部分示例和绘图，尽管这里分析的是MySQL的binlog 和redo log，但是这里的两段式提交的思想在做支付场景的业务的时候经常用到。
关于这种方式的更多内容，可以参考： https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery.html
明显不会，磁盘IO太慢了，如果每个请求过来 MySQL 都要写磁盘，磁盘肯定扛不住。
保证redo log和binlog可以持久化到磁盘，就可以确保MySQL在异常重启后进行数据恢复。
在生产环境上，为了避免数据的丢失，通常情况下都会定时的对数据库进行备份。而Linux的crontab指令则可以帮助我们实现对数据库定时进行备份。首先我们来简单了解crontab指令，如果你会了请跳到下一个内容mysql备份。 本文章的mysql数据库是安装在docker容器当中，以此为例进行讲解。没有安装到docker容器当中也可以参照参照。
第一步：master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中。
使用数据库的时候，我们每个操作都十分小心，尤其是不能直接在数据库上执行 update、delete 等操作，否则万一忘记加全 where 条件，可能就会造成无法挽回的结果。 有一句十分流行的调侃 — “从删库到跑路”就很形象的说明了误操作后的结果，那么如果你真的不小心执行了删库操作，真的就无法挽回了吗？ 当然不会了，通常对于线上数据库，我们都会定时冷备，dump 导出数据库的全量备份，并且保留一段时间内的所有修改日志，进而实现在必要时回滚到这段时间内的任何一秒。 这里提到的“日志”指的就是 binlog，那么究竟什么是 binlog 呢？本文我们就来详细介绍一下。
看源码太费眼睛了. 还是gdb方便点, 为了方便低版本gdb的环境, 这里就不升级gdb了.
MYSQL 在备份中会使用 FTWRL, 来获得备份的数据一致点和对应的BINLOG 的位置.众所周知 FLUSH TABLE WITH READ LOCK 会关闭所有打开的表,强制所有的表.
之所以有这样一篇文章，是因为在前几天的一个晚上，要下班的时候，业务方忽然有一个需求，是需要恢复一个表里面的数据，当时问了下情况，大概是这样的：业务方不小心在一个表里面做了一个update的操作，可能是where条件没有写对，导致表里面的数据被写坏了，但是数据目前还没有落盘，只是在内存中的值修改了，现在要求恢复到之前的数据。万幸，这份数据是平台上某些商品的价格，基本上是有限个商品，然后价格值也都是固定的，之前有对这个价格表进行备份，于是给他直接重新导入了一份价格表的数据，这个问题也算是解决了。
•当你使用了redis或者其他中间件做缓存的时候，经常发现缓存和数据库的数据不一致，只能通过定时任务或者缓存过期的方式去做一些限制。•当你使用了ES做搜索工具，使用双写的那一套方法，还在为ES和数据库不是一个事务而担忧。•当你需要迁移数据的时候，也还在使用双写的方法，如果是同一个数据库的还好，如果是不同数据库就不能保证事务，那么数据一致性也是个问题，就会写很多的修复Job和检查Job。
爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。
众所周知，MySQL5.7对于半同步增强的其中一个部分是对ack确认动作的改进。在5.6下的半同步的ack确认是在storage commit之后，这就带来了两个问题
这是很早时候写的一篇文章，今天翻看历史文章的时候发现的，觉得还是有收获，就分享出来了。以下是文章原文：
我们知道，在MySQL中，redo log是一个文件组，一般是3个文件，循环写入，写满的时候会做redo log层面的checkpoint，然后覆盖之前的redo log；而binlog是有归档功能的，每个binlog写满之后，都会重新开启下一个binlog开始写入，这也是为什么可以使用binlog来进行数据恢复的一个原因，就是因为它的归档功能。
之前的文章把 InnoDB 中的所有的锁都介绍了一下，包括意向锁、记录锁...自增锁巴拉巴拉的。但是后面我自己回过头去看的时候发现，对自增锁的介绍居然才短短的一段。
上部分状态：客户端的读写都直接访问A，B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持B和A的数据相同。
在状态1中,客户端的读写都直接访问节点A,而节点B是A的备库，只有将A的更新都同步过来，到本地执行，这样可以保证节点B和A的数据是相同的
最近在工作中，遇到了这样一个业务场景，我们需要关注一个业务系统数据库中某几张表的数据，当数据发生新增或修改时，将它同步到另一个业务系统数据库中的表中。
上篇文章我们聊了单机模式下，MySQL是如何保证数据一致性的，但是在实际的生产环境中，很少采用单机模式。现在所有的集群架构都是从MySQL的主从复制演变过来的。MySQL的主从复制是通过将主库的binlog发送至从库，从库重新提交主库的变更来实现主从数据的一致性。MySQL的主从复制主要分为三种：异步复制、半同步复制、组复制（MGR）。
redo log包括两部分内容，分别是内存中的日志缓冲(redo log buffer)和磁盘上的日志文件(redo log file)。
本文实例讲述了CentOS服务器环境下MySQL主从同步配置方法。分享给大家供大家参考，具体如下：
这些数据最终会持久化到文件中，那么这些数据在文件中是如何组织的？难道是一行一行追加到文件中的？其实并不是，「数据其实是存到页中的，一页的大小为16k，一个表由很多页组成，这些页组成了B+树」，最终的组织形式如下所示，具体的构建过程我就不详细介绍了，可以看我之前的文章《10张图，搞懂索引为什么会失效？》
本文作者：张松坡，腾讯云数据库架构师，主要负责腾讯云数据库MySQL、Redis等数据库架构设计、数据库运维、运营开发等工作。曾就职于腾讯新闻、腾讯视频。 ---- 写在前面，感谢腾讯云数据库架构师团队祝海强、杜川、刘志祥在排障思路、源码分析上面提供的帮助，让我学习到了很多，不敢居功，特此鸣谢！ 本文将以数据库实际使用中的某典型案例来分析造成主从延迟的原因。 主从延迟的原因 1、某用户在使用数据库过程中，出现主从延迟很大的情况，show slave status\G，已经差了60多个binlog了。
大家好，我是Leo。前面文章我们介绍了WAL的安全机制。可以保证数据的安全性。通过安全性我们分析了binlog，redolog日志的写入机制。今天我们分析一下主从库的实现原理！MySQL是如何保证主从库的数据是一致的呢？
最近行情越来越卷了，给大家整理了互联网大厂15道经典MySQL日志面试题，希望大家都能找到理想的offer
在前面的文章中，我不止一次地和你提到了 binlog，大家知道 binlog 可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了 binlog 就可以跟主库保持一致了呢？今天我就正式地和你介绍一下它。
> * GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
很多人，这里说的是运维工程师们，一提到写某某方案，很是头疼。不是上某度一统搜索，就是同样一句话在N个群全部群发一遍：“有没有某某方案，可以共享一下的吗？？求助，各位大佬们”，估计十有八九，全部石沉大海，杳无音讯。
大家好，我是田螺哥。金九银十已经来了，整理了15道经典MySQL日志面试题，希望对大家有帮助。
一说起MySQL使用的内存，你可能会想到各种buffer，最著名的莫过于innodb buffer pool了，它是内存使用的大户，还有sort buffer等等。除了这些buffer之外，可能还有一些细枝末节，今天我们来总结一下。
首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。
通常我们说的 MySQL 读写分离是指：对于修改操作在主库上执行，而对于查询操作，在从库上执行。主要目的是分担主库的压力。
事情是这样的，我负责我司的报表系统，小胖是我小弟。某天他手贱误删了一条生产的数据。被用户在群里疯狂投诉质问，火急火燎的跑来问我怎么办。我特么冷汗都出来了，训斥了他一顿：蠢，蠢得都可以进博物馆了，生产的数据能随便动？
在 MySQL 的主从架构在很多场景下都在使用，同时 MySQL 的同步延迟也是很多 DBA、运维、开发的同学经常面对的问题之一。本文围绕同步延迟的场景之一：无主键表，来看看延迟产生的原因，以及应对的策略。当然，从标题上也能看出来，给表建个主键是最好的办法，不过在关于这个问题，其实还有一些其他的方式可以尝试。
我们还是从一个表的一条更新语句说起，下面是这个表的创建语句，这个表有一个主键 ID 和一个整型字段 c： mysql> create table T(ID int primary key, c int); 如果要将 ID=2 这一行的值加 1，SQL 语句就会这么写： mysql> update T set c=c+1 where ID=2;
上文《MySQL数据被误删怎么办？》介绍了MySQL在故障或者误删数据后，可以通过备份+binlog的方式进行数据恢复。但是，当备份文件和binlog都丢失了呢？所以单节点是不可靠的，为了避免单节点故障带来的数据丢失以及MySQL服务的可用性，生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术，所以本文对主从复制的原理和操作展开介绍，从而全面了解这一技术。
如果在开始备份时没有指定--flush-logs参数，则需要首先查看备份时所处的位置
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
