京东到家程序员删库跑路 ! 讲一讲 MySQL 数据备份杀手锏 binlog

大家好,我是Tom哥~


我们都知道,数据非常重要

网上也经常看到一些段子,某公司程序员对工作不满,删库跑路,老板损失惨重,欲哭无泪。这不最近又爆出一例,京东到家程序员离职当天删库跑路!

那么有没有什么解决方案?

即使数据库真的被删了,也有备份数据,能快速恢复。甚至可以做到实时热备,即使内部炸掉外部用户也感知不到,一片风平浪静。

MySQL 作为当下流行数据库,在数据备份高可用方面非常有竞争力,今天,我们就重点来讲下

什么是 MySQL 主备

情况一:

客户端的业务操作,读、写访问的是主库

主库通过某种机制,将数据实时同步给备库

主库由于有些原因,无法正常响应客户端的请求

情况二:

完成主备切换

客户端读写,访问的是备库(此时备库升级为新主库)

那么,这里面最核心的数据同步是如何实现的?

主从同步原理

1、在备库执行 change master 命令 ,绑定主库的信息

mysql> CHANGE MASTER TO MASTER_HOST = '192.168.1.1', MASTER_USER = 'repl', MASTER_PASSWORD = 'replpassword', MASTER_PORT = 3306, MASTER_AUTO_POSITION = 1, MASTER_RETRY_COUNT = 0, MASTER_HEARTBEAT_PERIOD = 10000; 

MASTER_HOST :master主机名(或IP地址)

MASTER_PORT :mysql实例端口号

MASTER_USER:用户名

MASTER_PASSWORD:密码

MASTER_AUTO_POSITION:如果进行change master to时使用MASTER_AUTO_POSITION = 1,slave连接master将使用基于GTID的复制协议

MASTER_RETRY_COUNT:重连次数

MASTER_HEARTBEAT_PERIOD:复制心跳的周期

https://www.docs4dev.com/docs/zh/mysql/5.7/reference/change-master-to.html

2、备库执行 start slave 命令,备库启动两个线程:I/O threadSQL thread

3、master主库,有数据更新,将此次更新的事件类型写入到主库的 binlog 文件中

4、主库会创建log dump 线程,通知slave有数据更新

5、slave,向master节点的 log dump线程请求一份指定binlog文件位置的副本,并将请求回来的binlog存到本地的Relay log 中继日志中

6、slave 再开启一个SQL 线程读取Relay log日志,解析出日志里的命令,并执行,从而保证主备库数据同步

整理了一份大厂常考面试题,这份pdf包括 Java基础、Java并发、JVM、MySQL、Redis、Spring、MyBatis、Kafka、设计模式等面试题,分享给大家。

下载地址:百度云链接:https://pan.baidu.com/s/1XHT4ppXTp430MEMW2D0-Bg 提取码: s3ab


binlog 有哪几种格式

现在,让我们近距离看下 binlog 日志。

binlog 格式有三种:rowstatementmixed

接下来,我们开始一个实验:

先创建一个表

CREATE TABLE `person` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `income` bigint(20) NOT NULL COMMENT '收入',
  `expend` bigint(20) NOT NULL COMMENT '支出',
  PRIMARY KEY (`id`),
  KEY `idx_income` (`income`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='个人收支表';

插入4条记录:

insert into person values(50,500,500);
insert into person values(60,600,600);
insert into person values(70,700,700);
insert into person values(80,800,800);

查看binlog模式:

查看当前正在写入的binlog文件:

查看 binlog 中的内容,我们先来看下 row 模式

show binlog events in 'mysql-bin.000001';

说明:

SET @@SESSION.GTID_NEXT='ANONYMOUS’

BEGIN  开始一个事务

Table_map  记录更新了哪个库、哪张表

Write_rows 记录做了什么操作,详细看binlog需要借助mysqlbinlog工具。

COMMIT /* xid=157 */  结束一个事务

查找 binlog 文件的物理位置:

root@167bfa3785f1:/# find / -name mysql-bin.000001
/var/lib/mysql/mysql-bin.000001

借助 mysqlbinlog 命令,查看具体内容:

mysqlbinlog -vv mysql-bin.000001 --start-position=2986;

红框中的内容表示执行了插入命令,insert into person values(80,800,800);

其中,@1、@2、@3 表示表 person 的第几个字段,不用原始名称,是为了节省空间。

修改 binlog 格式,设置为 STATEMENT ,查看日志格式:

set global binlog_format='STATEMENT';

设置之后,需要退出mysql重新连接,才能看到生效

show binlog events in 'mysql-bin.000001';

从图中我们可以看出,当 binlog_format=statement 时,binlog 里面记录的就是 SQL 语句的原文。

其中,use tomge  :表示要先切到对应的数据库

如果想从指定位置查看binlog,可以增加 from 可选参数,如下:

show binlog events in 'mysql-bin.000001'  from 5168;

statement 与 row 对比:

statement 格式的binlog记录的是sql语句;row 格式的binlog记录的是event(Table_map,Write_rows,Delete_rows)

当 binlog 在 statement 格式下,记录的是sql语句,在主库执行时可能使用的是索引 A;但是同步给备库执行时,可能用了 索引B。

索引不同,同一条sql语句,运行结果可能也不一样。

针对这个场景,我们建议采用 row 格式的 binlog。

即使我们使用了带where 条件(如:income>720)的delete语句,但 binlog 记录的是要删除的主键id(id =80 ),所以不会出现差错。

mixed 格式 的binlog 是个啥?

由于 statement 格式的binlog 可能会导致主库、备库间的数据同步不一致,因此我们会采用 row 格式。

但是,row 格式占用的空间很大,写 binlog 也要占用大量的 IO 资源。

所以,官方提出一种mixed混合模式,集成了两者的优点。

内容如下:

mysql会自动判断statement格式,是否会引发主备不一致的问题

如果statement格式会引起主备不一致的问题,自动使用row格式。

如果statement格式不会引起主备不一致的问题,那么就用statement格式,

恢复数据

当然,我们还建议把MySQL 的binlog设置成 row 模式,因为它可以用于数据恢复。我们来看下 insertupdatedelete 三种DML操作如何来恢复数据的。

1、delete:

当我们执行 delete 命令时,如果 binlog_row_image 设置了 'FULL',那么 Delete_rows 里面,包含了删掉的行的所有字段的值。

如果误删了,因为 binlog 记录了所有字段的值,反向执行 insert  就可以了。

binlog_row_image 设置为 MINIMAL,只记录关键信息,比如 id=80

2、insert:

row 格式下,binlog 会 记录 insert 的所有字段值。

如果误操作,只需要根据这些值找到对应的行,再执行 delete 操作即可

3、update:

row 格式下,binlog 会 记录 update 修改前、修改后的整行数据。

如果误操作,只需要用修改前的数据覆盖即可。

通过命令来恢复数据:

如果要执行数据恢复,可以使用下面命令

mysqlbinlog mysql-bin.000001  --start-position=1  --stop-position=3000 | mysql -h192.168.0.1 -P3306 -u$user -p$pwd;

mysql-bin.000001 文件位置从 1到3000 的 binlog 在 192.168.0.1机器的数据库上回放,还原。



关于我:

Tom哥计算机研究生,校招进阿里,期间还拿了百度、华为、中兴、腾讯 等6家大厂offer,P7 技术专家。出过专利CSDN博客专家

多年的大厂浸染,参加多次淘宝双11大促活动,在系统架构方面有丰富经验,沉淀总结在微信公众号:微观技术

他专注于微服务、高并发、高性能缓存、分布式架构、高可用、团队管理等方面,喜欢挖掘开源框架亮点设计,内容都是面试官喜欢考察的强烈推荐关注一波。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,457评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,837评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,696评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,183评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,057评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,105评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,520评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,211评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,482评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,574评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,353评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,897评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,489评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,683评论 2 335

推荐阅读更多精彩内容