从这个错误的位点来看，在主库flush binary logs后，视乎主库的DUMP线程又在重新发送老的mysql-binlog.000035这个binlog。报错是因为以前是GTID模式，但是测试的时候已经改为了POSITION模式，是主库DUMP线程在检测主库的GTID Event和从库的GTID模式是否兼容的时候报出来的，如下图
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
经过前面文章学习，我们知道 binlog 会记录数据库所有执行的 DDL 和 DML 语句（除了数据查询语句select、show等）。注意默认情况下会记录所有库的操作，那么如果我们有另类需求，比如说只让某个库记录 binglog 或排除某个库记录 binlog ，是否支持此类需求呢？本篇文章我们一起来看下。
爱可生 DBA 团队成员，熟悉 Oracle、MySQL、MongoDB、Redis，最近在盘 TiDB，擅长架构设计、故障诊断、数据迁移、灾备构建等等。负责处理客户 MySQL 及我司自研 DMP 数据库管理平台日常运维中的问题。热衷技术分享、编写技术文档。
binlog二进制日志对于mysql数据库的重要性有多大，在此就不多说了。下面根据本人的日常操作经历，并结合网上参考资料，对binlog日志使用做一梳理： 一、binlog日志介绍 1）什么是binlog binlog日志用于记录所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。 2）binlog作用 因为有了数据更新的binlog，所以可以用于实时备份，与master/slave主从复制结合。 3）和binlog有关参数 l
由于安装数据库时将MySQL的数据目录放在了根目录下，现在存储空间不足，想通过mv将数据目录移动到其他目录下，但将数据目录移动到其他数据目录后，启动数据库失败。
MySQL是一个广泛使用的开源关系型数据库管理系统，它提供了许多强大的功能，如事务、存储过程、触发器、视图、全文索引等。但是，MySQL也有一些不足之处，比如数据的安全性和可靠性。如果数据库发生故障或损坏，如何恢复数据？如果数据库需要进行主从复制或读写分离，如何保证数据的一致性？这些问题都需要借助一个特殊的机制来解决，那就是binlog。
同大多数关系型数据库一样，日志文件是MySQL数据库的重要组成部分。MySQL有几种不同的日志文件，通常包括错误日志文件，二进制日志，通用日志，慢查询日志，等等。这些日志可以帮助我们定位mysqld内部发生的事件，数据库性能故障，记录数据的变更历史，用户恢复数据库等等。二进制日志，也叫binary log，是MySQL Server中最为重要的日志之一，本文主要描述二进制日志。
爱可生华东交付部DBA，主要负责MySQL日常问题处理及DMP产品支持。爱好跳舞，追剧。
查看master状态，即最后一个binlog日志的编号名称，及其最后一个操作时间pos结束点值
MySQL的二进制日志（binary log），通常被称为binlog，是MySQL数据库中的一种日志文件，它记录了所有的DDL（Data Definition Language）和DML（Data Manipulation Language）语句事件，这些语句会导致MySQL数据的改变。binlog是MySQL复制的基础，也是进行数据恢复的重要手段。
偶然的机会朋友说他部门的数据库误删了，想恢复回来，他百度了一些资料，也跟着试了。但发现会报一些错，于是他就找我帮忙看一下。对于我来说，因为公司的数据库都是DBA在管控，平时都没机会操作，基本上都停留在理论上。
MySQL 的二进制日志（Binary Log），通常简称为 binlog，是一种记录数据库中发生的更改的日志文件。它记录了对数据库进行的 INSERT、UPDATE 和 DELETE 等数据更改操作，以及数据库结构的更改（例如，ALTER TABLE）。这些日志文件对于数据恢复、数据复制和数据库的高可用性非常重要。以下是关于 MySQL binlog 的详细介绍：
我们在使用和维护MySQL时，一定经常听到binlog这个概念。binlog在主从复制，数据恢复等场景都有着重要作用。本篇文章主要介绍binlog的概念，功能及常用操作，旨在帮助大家对binlog有更深的了解。
在生产环境上，为了避免数据的丢失，通常情况下都会定时的对数据库进行备份。而Linux的crontab指令则可以帮助我们实现对数据库定时进行备份。首先我们来简单了解crontab指令，如果你会了请跳到下一个内容mysql备份。 本文章的mysql数据库是安装在docker容器当中，以此为例进行讲解。没有安装到docker容器当中也可以参照参照。
从案例中我们得知是中途开启的GTID，但是留下了很多未开启GTID的BINLOG，从第六部分源码bool MYSQL_BIN_LOG::init_gtid_sets()函数的分析，我们知道删除BINLOG后也会触发正向查找来获取gtid_purged(Gtid_state.lost_gtids)。当读取到第一个BINLOG的时候虽然获取到了PREVIOUS GTID EVENT但是没有GTID EVENT，而simple_recovery=flase所以需要继续查找下一个文件，直到找到同时包含PREVIOUS GTID EVENT和GTID EVENT的 那个BINLOG才会停止，那么显然这种情况下那些GTID关闭的时候生成的BINLOG将会全部扫描一遍，如果量大那么代价将是巨大的。 而案例中每半个小时会触发一次BINLOG切换，因为触发超过expire_logs_days参数设置导致BINLOG进行删除，触发了大量的BINLOG扫描。 显然有了前面的基础这个案例很容易分析。
在搭建MySQL主从的时候，change master是一个关键，如果没有使用GTID的方式，就需要使用偏移量和指定的binlog，每次需要手工去抓取这些信息，感觉还是比较费力，而且偏移量对我们来说就是一个黑盒子，到底递增多少，我们也不知道，只是给我们一个结果，但是搭建了一些环境之后，我突然发现了一些“规律”，比如下面的语句。 CHANGE MASTER TO MASTER_HOST='192.168.xxx.xxx.', MASTER_USER='rpl_user1', MASTER_PASS
勘误，昨天有一位 海外 friend 指出昨天文中 postgresql bloom 中的第四步截图是并行扫描，而没有用到bloom 索引，这里抱歉，经查实截图错误，下面是重新的截图，同时另一幅截图也有问题建立索引时缺少 USING bloom，感谢您。
binlog 就是binary log，二进制日志文件，这个文件记录了mysql所有的增、删、改语句。通过binlog日志我们可以做数据恢复，做主从复制等等。可以看到，只要有了这个binlog，我们就拥有了mysql的完整备份了。
最近开始写文章都是带两个主题，技术主题与生活主题，生活热点，还是老传统，技术在前，生活话题在后。
如果你正在使用 MySQL8.0 ，并且在使用物理热备工具，那么 binlog_expire_logs_seconds 可能不会如你预想的那样生效。
我们常常听人说，只要你愿意，MySQL 可以恢复至半个月甚至一个月以内的任何一个状态。网上也有很多删库跑路的段子。。。
开个玩笑，今天文章的主题是如何使用Mysql内置的Binlog日志对误删的数据进行恢复，读完本文，你能够了解到：
Binlog 日志，全称为 Binary Log，是 MySQL 在 Server 层产生的一种日志。这种日志包含了对数据库执行变更的所有操作（例如 SQL 语句的执行）或者对于数据库的数据变更情况，记录了实例的所有 DML 和 DDL 操作。
【转载请注明出处】：https://cloud.tencent.com/developer/article/1632663
一般正式环境使用数据库都会做全备份，但如果某个时刻数据库崩了，若利用全备份文件恢复，则在全备份到出现问题这段时间内的数据将会丢失，一般来说迫不得已也不会采取这种措施，更直接是采用binlog恢复。
Binlog日志，即二进制日志文件，用于记录用户对数据库操作的SQL语句信息，当发生数据误删除的时候我们可以通过binlog日志来还原已经删除的数据，还原数据的方法分为传统二进制文件还原数据和基于GTID的二进制文件还原数据
MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。
binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
在数据库管理领域，MySQL的二进制日志（Binlog）是一个不可或缺的组件，它记录了所有对数据库执行的更改。对于我们每位开发者而言，理解和掌握Binlog的操作和查询技能，不仅能帮助我们更好地跟踪和分析数据变动，还能在复制错误出现时，提供有效的解决方案。本文将详细介绍如何识别Binlog日志的名称和位置，以及如何查询特定位置的操作，以便于我们在遇到复制错误时，能快速定位问题并采取相应措施。
作为一个 MySQL DBA，查看分析 binlog 是日常工作的一部分。不知道你是否遇到过这样的需求：查询一个时间段内各个表的 dml 统计情况。但，如果 binlog 文件很多呢？又或者负责的业务线比较多，有多个业务都有这种需求呢？
本文简要介绍 binlog 原理及其在恢复、复制中的使用方法，更多深入分析可参考 mysql 官方文档。
假设主备切换前，我们的主库是节点A，节点B是节点A的备库，客户端的读写都是直接访问节点A，节点B只是将A的更新同步过来然后本地执行，同步完成以后，节点AB的数据就一致了。
本文简要介绍 binlog 原理及其在恢复、复制中的使用方法。
在配置文件中加入 log-bin 配置，表示启用binlog，如果没有给定值，写成 log-bin=，则默认名称为主机名。（注：名称若带有小数点，则只取第一个小数点· 前的部分作为名称）
前一段时间客户反馈复制报错 1236 ，根据报错提示该报错为从库读取到了主库不存在的 binlog 日志，导致复制中断，报错截图如下，需要帮忙分析为什么会报错 Could not open log file 原因。
go版MySQL binlog解析工具，通过解析MySQL binlog ，可以生成原始SQL、回滚SQL、去除主键的INSERT SQL等，也可以生成DML统计信息。
作用： 记录mysql数据库的一般状态信息及报错信息，是我们对于数据库常规报错处理的常用日志。
MySQL是互联网行业使用的最多的关系型数据库之一，而且MySQL又是开源的，对于MySQL的深入研究，能够加深我们对于数据库原理的理解。自从开源了mykit-data之后，不少小伙伴试用后，反馈mykit-data无法正确的解析MySQL8的binlog。于是我测试了下，mykit-data在解析MySQL5.x的binlog时，没有啥问题，能够正确的解析出结果数据。然而，在解析MySQL8.x的binlog时，总是与binlog日志位数相差12位而导致解析失败。
在我们知数堂的MySQL DBA课上讲到binlog序号是从000001开始，这时有细心的同学问到，是不是这个序号达到999999后，binlog就要重新开始了？
MySQL 中的日志比较重要的有 binlog（归档日志）、redo log（重做日志）以及 undo log，那么跟我们本文相关的主要是 binlog，另外两个日志松哥将来有空了再和大家详细介绍。 1. binlog binlog 我们中文一般称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当我们搭建 MySQL 主从的时候就离不开 binlog（传送门：MySQL8 主从复制踩坑指南）。 binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，
MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选：Mixed,Statement,Row，默认格式是 Statement。 总结一下这三种格式日志的优缺点。 默认binlog 设置 mysql> mysql> show variables like 'binlog_%'; +-----------------------------------------+--------------+ | Variable_name |
https://mp.weixin.qq.com/s/XSnFkuYzIlGWMaXIl-oPeQ
维护mysql的时候，总会遇到数据库恢复的例子。如果把备份集恢复出来相对比较简单。然而如果遇到恢复到时间点的例子，把一个MySQL实例恢复出来之后，需要执行binlog做增量恢复。 常见的办法是用mysqlbinlog解析binlog，将解析出来的内容重定向到mysql命令行执行。在MySQL手册中也是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复。事实上，这是一个经常“让人郁闷”的办法。更好的办法是，使用MySQL内部复制线程中的SQL Thread来做恢复。
log-bin = /var/log/mysql/mysql_bin #binlog日志文件,以mysql_bin开头，六个数字结尾的文件：mysql_bin.000001，并且会将文件存储在相应的xxx/xxx路径下，如果只配置mysql_bin的话默认在C:\ProgramData\MySQL\MySQL Server 5.7\Data下； binlog_format = ROW #binlog日志格式，默认为STATEMENT：每一条SQL语句都会被记录；ROW：仅记录哪条数据被修改并且修改成什么样子，是binlog开启并且能恢复数据的关键； expire_logs_days= 10 #binlog过期清理时间； max_binlog_size = 100m #binlog每个日志文件大小； binlog_cache_size = 4m #binlog缓存大小； max_binlog_cache_size = 512m #最大binlog缓存大小。 service mysql restart #重启一下
MySQL闪回(flashback)利用binlog直接进行回滚，能快速恢复且不用停机。
在MySQL中，可以通过配置max_binlog_size和expire_logs_days参数来控制二进制日志（binlog）的大小和保留期。但是，要注意的是，max_binlog_size参数设置的是单个binlog文件的最大大小，而不是所有binlog文件的总容量。当binlog文件的大小达到max_binlog_size指定的值时，MySQL会自动创建一个新的binlog文件。
纪成，携程数据开发总监，负责金融数据基础组件及平台开发、数仓建设与治理相关的工作。对大数据领域开源技术框架有浓厚兴趣。
在工作中，我们误删数据或者数据库，我们一定需要跑路吗？我看未必，程序员一定要学会自救，神不知鬼不觉的将数据找回。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
