首先交代一下背景，由于某些因素的限制，我们公司目前的备份策略采用的是隔天全备的方案，增量备份则使用的是binlog server的方式，那么如何快速恢复就成为了我们需要思考的问题
偶然的机会朋友说他部门的数据库误删了，想恢复回来，他百度了一些资料，也跟着试了。但发现会报一些错，于是他就找我帮忙看一下。对于我来说，因为公司的数据库都是DBA在管控，平时都没机会操作，基本上都停留在理论上。
在我们平时的开发工作中，很多场景需要我们备份和恢复，比如数据库binlog日志备份、mvcc多版本并发控制、浏览器的回退、Chrome奔溃后重新打开恢复之前的页面。在GOF《设计模式》定义如下：
Binlog 日志，全称为 Binary Log，是 MySQL 在 Server 层产生的一种日志。这种日志包含了对数据库执行变更的所有操作（例如 SQL 语句的执行）或者对于数据库的数据变更情况，记录了实例的所有 DML 和 DDL 操作。
我们常常听人说，只要你愿意，MySQL 可以恢复至半个月甚至一个月以内的任何一个状态。网上也有很多删库跑路的段子。。。
在前一阵子，大哥问过我：”你知道MySQL的原子性是怎么保证的吗“。我懵逼了，MySQL怎么保证原子性？我不会啊。
前一段时间接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新，对DBA而言，回滚数据着实是一件头疼的事情，凡涉及到恢复线上数据必然对应用带来一定的影响。大多数情况是开发误操作delete数据，update多数行，根据之前的操作经验，本文介绍常用的恢复方法。
昨天在复习 MySQL 日志相关的知识，学的东西过一段时间后就会遗忘，遗忘后再重新思考，往往会有新的收获。想到几个问题，把它记录下来。
假设当前 ID=2 的行，字段 c 的值是 0，再假设执行 update 语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了 crash，会出现什么情况呢？
在工作中，我们误删数据或者数据库，我们一定需要跑路吗？我看未必，程序员一定要学会自救，神不知鬼不觉的将数据找回。
对于任何一个企业来说，数据安全的重要性是不言而喻的。我在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。
删库跑路的案例不在少数，今年最出名的删库跑路当属微盟，造成公司市值蒸发几十亿，赔偿商家1.5亿元，最终在腾讯云的协助下经过7*24小时的不懈努力，最终找回全部数据。我们都知道，数据就是一个公司的“命根子”，无论什么时候，数据安全都是最重要的。所以我们今天来聊聊数据恢复的几种方式。以mysql为例。
使用flashback工具，原理是修改binlog的内容，拿回原库重放。需要binlog格式为row格式，并且binlog_row_image=FULL
最近在极客时间看丁奇大佬的《MySQL45讲》，真心觉得讲的不错，把其中获得的一些MySQL方向的经验整理整理分享给大家，有兴趣同学可以购买相关课程进行学习。
备份恢复之前和同事投入了一些精力来完善，算是走上了平台化对接的一个开始，在满足功能的前提下，能够基本实现数据全备，增备和DML闪回，但是在性能和可控性方面还是存在不少的改进之处，最近梳理了下已有的备份恢复策略，准备在这个方面能有一定的成绩。
维护mysql的时候，总会遇到数据库恢复的例子。如果把备份集恢复出来相对比较简单。然而如果遇到恢复到时间点的例子，把一个MySQL实例恢复出来之后，需要执行binlog做增量恢复。 常见的办法是用mysqlbinlog解析binlog，将解析出来的内容重定向到mysql命令行执行。在MySQL手册中也是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复。事实上，这是一个经常“让人郁闷”的办法。更好的办法是，使用MySQL内部复制线程中的SQL Thread来做恢复。
MySQL 的二进制日志（Binary Log），通常简称为 binlog，是一种记录数据库中发生的更改的日志文件。它记录了对数据库进行的 INSERT、UPDATE 和 DELETE 等数据更改操作，以及数据库结构的更改（例如，ALTER TABLE）。这些日志文件对于数据恢复、数据复制和数据库的高可用性非常重要。以下是关于 MySQL binlog 的详细介绍：
还是先在粉板上记一下方便。如果掌柜没有粉板，每次记账都翻账本，效率是不是低死啦？ MySQL也有这个问题，若每次更新操作都写进磁盘，然后磁盘也要找到对应记录，然后再更新，整个过程IO成本、搜索成本都很高。 何解？采用类似酒掌柜粉板的思路。
在 MySQL架构（二）SQL 更新语句是如何执行的？中说到了 redo log 和 binlog 日志文件，在事务执行过程中，会分两个阶段写入这两份日志文件中，这也是为了保证两份日志之间的一致性，即维护 mysql 的数据一致性。
糖豆贴心提醒，本文阅读时间5分钟 血的教训，事发经过就不详述了。直接上操作步骤及恢复思路（友情提示：数据库的任何操作都要提前做好备份），以下是Mysql数据后的恢复过程： 1. 找到binlog 恢复数据的前提是必须开启Mysql的binlog日志，如果binlog日志没开启，请忽略此篇文档。binlog日志是否开启可以查看Mysql配置文件。日志位置一般在/var/lib/mysql目录或者编译安装的date目录下。也可登录Mysql用命令查看。 # cat /etc/my.cnflog_bin
我们还是从一个表的一条更新语句说起，下面是这个表的创建语句，这个表有一个主键 ID 和一个整型字段 c：
update语句也需要经过连接器、分析器、优化器、执行器，但是update语句相比select语句还是有很大不同的，更新流程设计两个重要的日志模块：
这篇文章是从Github ReadMe拷贝的，内容实践下载是没问题的，能够正常发送短信，而且也不需要服务器，本地也能跑起来
之前你可能经常听DBA同事说，MySQL可以恢复到半个月内任意一秒的状态，惊叹的同时，你是不是心中也会不免会好奇，这是怎样做到的呢？
他们有一个共同的字段, 叫做xid, 崩溃恢复的时候, 会按照顺序扫描redolog:
数据是当今Web，移动，社交，企业和云应用程序的流行货币。确保数据始终可用是任何组织的头等大事。几分钟的停机时间可能会导致收入和声誉严重损失。
日常的数据备份及恢复测试，是DBA工作重中之重的事情，所以要做好备份及测试，日常的备份常见有mysqldump+binlog备份、xtrabackup+binlog备份，无论那一种，几乎都少不了对binlog的备份，说明了binlog在数据恢复中的重要性，下面做个小测试，是工作中不少运维或者新人DBA容易犯的错。
1. 什么是两阶段提交 1.1 binlog 与 redolog 1.2 两阶段提交 2. 为什么需要两阶段提交 3. 小结 为什么要两阶段提交？一阶段提交不行吗？ 小伙伴们知道，MySQL 中的事务是两阶段提交，我们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次直接提交了不行吗？今天我们来聊聊这个话题。 关于分布式事务 seata，不懂的小伙伴可以参考松哥之前的文章，传送门： 五分钟带你体验一把分布式事务！so easy！ 看了那么多博客，还是不懂 TCC，不妨看
注意： –>binlog是二进制文件，普通文件查看器cat、more、vim等都无法打开，必须使用自带的mysqlbinlog命令查看 –>binlog日志与数据库文件在同目录中 –>在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “–no-defaults”选项
问题来自一位群友，简单说就是用 mysqlbinlog 工具读取 binlog 欲进行恢复，却发现数据并没被恢复。
MySQL 5.6.14 生产环境凌晨3点的备份,不完全恢复到中午12点. （xtrabackup_binlog_pos_innodb的内容是mysql-bin.006946 3784607） 第一种方式:mysqlbinlog 1.找到需要恢复的binlog 进入binlog目录,执行 ll | awk '{print $9}' > /tmp/binlog.index
操作系统：CentOS 7.7 MySQL版本：5.7.30，搭建主从 开启binlog，binlog_format=row 备份情况：每天00:00对数据库进行全量备份 恢复原因：某日22:00左右，执行了批量update语句，需要回滚
我们还是从一个表的一条更新语句说起，下面是这个表的创建语句，这个表有一个主键 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;
数据库恢复的先决条件是,定时备份数据库,缩小binlog恢复范围.首先我们备份测试数据库数据:
前两天因为没注意的误操作, 直接把某个数据表清掉了, 心慌慌. 怪自己学艺不精, 当时整了一下午也没把数据找回来. 当晚回来闭关研究, 终于在凌晨1点多整出来了, 特此记录, 以备不时之需.
在生产环境上，为了避免数据的丢失，通常情况下都会定时的对数据库进行备份。而Linux的crontab指令则可以帮助我们实现对数据库定时进行备份。首先我们来简单了解crontab指令，如果你会了请跳到下一个内容mysql备份。 本文章的mysql数据库是安装在docker容器当中，以此为例进行讲解。没有安装到docker容器当中也可以参照参照。
大家有没有想过为什么MySQL数据库可以实现主从复制，实现持久化，实现回滚的呢？其实关键在于MySQL里的三种log，分别是：
Flashback恢复数据的原理是通过修改binlog内容，拿回原库进行回放，前提是binlog_format=row和binlog_row_image=FULL。
MySQL可以恢复到半个月内任意一秒的状态. mysql> create table T(ID int primary key, c int);
很多年前，被公司外派到一家单位驻场开发一个OA项目，两个开发对接各部门的需求，需求还要及时生效（一边开发一边使用）。
MySQL binlog集市的事情我们做了有一段时间了，最开始的初衷是异常操作的数据恢复，主要的痛点是如果发生了业务误操作，需要紧急恢复数据的时候，通常这些误操作是对于字典配置数据的变更，而要恢复的时候成本则太高了，举个极端的例子，1T数据量的数据库，要恢复的字典数据最有1M,但是很可能需要恢复1T的数据量作为代价，有点得不偿失，所以，我们对于binlog集市是希望尽可能完整的捕获数据库的数据变化，并且能够闪回恢复。
重点文档:https://github.com/danfengcao/binlog2sql
MySQL的二进制日志（binary log），通常被称为binlog，是MySQL数据库中的一种日志文件，它记录了所有的DDL（Data Definition Language）和DML（Data Manipulation Language）语句事件，这些语句会导致MySQL数据的改变。binlog是MySQL复制的基础，也是进行数据恢复的重要手段。
MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有 DDL 和 DML 语句（除了select 语句），以事件形式记录，还包含语句所执行的消耗时间，MySQL 的二进制日志是事务安全型的。 万一遇到数据丢失的紧急情况下，可以使用 binlog 日志进行数据恢复（定时全量备份+binlog日志恢复增量数据部分）。
2PC全称是Two-PhaseCommit，翻译过来是二阶段提交，是分布式事务XA规范（XA规范是X/Open DTP定义的交易中间件与数据库之间的接口规范）的实现思路，满足CAP理论的CP，是强一致性事务。
删库跑路也是个老梗了，可见在运维数据库的过程中误删除数据，或者开发的代码有bug，造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案，例如SQL管理系统，将要执行的SQL先交由管理员审核，然后由管理员备份一个镜像数据库，在镜像上执行该SQL，并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
MySQL闪回(flashback)利用binlog直接进行回滚，能快速恢复且不用停机。
在前面几篇文章中，我们介绍了 MySQL 的高可用架构。当然，传统的高可用架构是不能预防误删数据的，因为主库的一个 drop table 命令，会通过 binlog 传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
