《MySQL实战45讲》学习小结(运维篇)

丁奇老师《MySQL实战45讲》的学习小结

 

第一篇:基础概念

 

第二篇:运维管理

 

之前对数据库主要是使用,运维管理做得很少,主要是备份、备份、备份 ^_^

通过这门课,在运维管理这方面学到的知识最多,学习内容的整理也最吃力。

 

照例从问题入手。

要理解MySQL在运维方面的机制,首先要理解数据库运维面对的问题:

  1. 数据库服务崩溃,但存储器正常,如何恢复?

  2. 服务器损毁,服务器上数据损坏或丢失,如何恢复数据和服务?

  3. 误删数据,如何恢复?

  4. 系统压力超过单个数据库服务器的能力,如何分布到多个服务器?

  5. 数据库性能急剧下降,怎么办?

 

在处理这些问题之前,先理解MySQL的几个运行机制,再来梳理如何应对这些问题。

 

 

第一部分:运行机制

 

1. 日志和主备同步(第24讲,28讲)

 

主库和从库之间的数据同步过程,如下图所示:

从库上有两个线程。

io_thread负责向主库发起请求,建立长连接,然后接收主库发送的binlog,写入relay log。从库在发起请求时,可指定从哪个位置开始获取binlog。

sql_thread负责读取relay log,解析出日志里的命令,并执行。

从一个事务在主库上完成,到这个事务在从库上完成,时间差即为同步延迟。

 

如果主库掉电,事务已完成,但binlog尚未发送给备库,会导致数据丢失。

为了解决这个问题,可采用 semi-sync 模式。在主库上,事务需等待至少一个从库确认已收到日志,才能完成事务,向客户端发送response。

 

主库上有个dump_thread,负责监听来自从库的请求,并随时把binlog发送给从库。

一个主库可能要监听多个从库的请求,多个从库请求的binlog起始位置也可能不同。

因此一个主库不要带很多个从库,以免binlog的同步消耗太多资源。

 

 

2. 主备切换(第24讲,25讲,27讲)

 

主备服务器的配备,目前多采用对称结构,即主备服务器的硬件配置一致,各一台,都提供读写服务,这样一旦主库出现问题,可以快速切换到备库,对应用的影响最小。备库虽然可读写,但正常情况下不做写操作。以下的内容均以此为前提。

 

由于存在同步延迟,因此在主备切换时,从可靠性优先角度,常见做法是先把主库设为只读,待同步延迟归0后,再切换到备库。通常情况下同步延迟小于1秒,这期间出现短暂的全库只读,对应用的影响不大。(需要HA工具支持)

但如果遇到异常,导致同步延迟很大,或者主库掉电无法访问等情况,只能选择可用性优先策略。这种情况下,可能会出现数据错误,需要人工介入。

 

数据库服务器的配备,一主多从是目前使用最多的结构。

一主多从结构下,备库是从库的一种,它可能被切换为主库,而其他从库不会。

一主多从结构下的主备切换,如下图所示:

《MySQL实战54讲》第27讲 一主多从基本结构 -- 主备切换

 

在一主多从结构下,主备切换包括了从库切换master的过程。

除了主备的数据同步延迟之外,还需要考虑各从库的同步延迟,且每个从库的同步延迟不尽相同。

 

位点:

5.6版本之前,MySQL只能通过找位点的方式。

从库跟主库建立联系时,可指定从哪个binlog文件、哪个偏移量开始同步。这个文件+偏移量就是位点。但对于同一个事务(sql),在主库和备库上,位点是不同的。可通过切换时间定位到一个近似值,但并不精确。需要人工介入。

 

GTID:

MySQL 5.6版本引入了GTID以解决这个问题。

GTID = server_uuid:gno

gno是在每个MySQL实例上,单调递增的数值,在事务提交时分配。server_uuid + gno 的组合可以保证全局唯一。GTID被包含在binlog中,发给从库。

每个MySQL实例都维护了一个GTID集合,记录“这个实例执行过的所有事务”。

在主备切换时,从库会发送本实例的GTID集合,例如 set B 给新的主库 A'。新的主库 A' 对比自己的和从库B的GTID集合,先检查set B在本实例上全部存在,再发送 set A' - set B 这些事务的binlog给从库B,然后就回到正常的binlog同步。

GTID的全部集合很大,MySQL应该会定期移除历史,不断提高水位。这个教程中未涉及,是猜测。

GTID除了解决主备切换时的同步问题,还可以用来在同步时跳过特定的事务。

 

 

3. 缓存和落盘(第12讲,23讲)

 

为了提升性能,MySQL对数据的读写都优先在内存上进行,并选择合适的时机将数据读入内存、将修改结果同步到磁盘。不仅对数据如此,对日志也使用这个策略。

 

 

为了保证数据可靠性,需要控制redo log和binlog尽快写入磁盘。

MySQL提供了两个参数来控制:

  • innodb_flush_log_at_trx_commit = 1 每次事务提交时都将 redo log 直接持久化到磁盘

  • sync_binlog = 1 每次提交事务都会执行 fsync

 

redo log的刷盘有两点说明:

  • 根据上一篇redo log + binlog 实现crash-safe的机制,有binlog的情况下,有prepare状态的redo log即可恢复数据。因此,一个事务只需要等待redo log prepare刷盘,不用等redo log commit刷盘。

  • redo log cache为共用,在一个事务提交时,把该事务最后一条日志及在此之前的所有redo log刷盘,实现group commit,提升IO效率。

 

在这样的机制下,我们可以认为MySQL的数据(及log)不会丢失。

后续关于运维问题的小结,均在此基础上进行。

 

 

第二部分:运维场景

 

1. 数据库服务崩溃,但存储器正常,如何恢复(第2讲,23讲)

 

先明确恢复的目标。

站在应用的角度,提交了事务,数据库服务返回response,即认为数据已更新。这类数据需要恢复。如果事务未提交,数据库服务崩溃,则数据不应更新,数据库恢复后的状态,同事务回滚。

如果提交了事务,但未收到response服务器连接就断开了,事务的状态依赖于数据库的log来判断。

 

详见如下流程图:

 

几点说明:

  1. 客户端发出“提交事务”命令后,服务器成功返回,则客户端认为事务完成、数据已更新。但是,如果 2、3 这两步都是异步请求的话,在服务器崩溃时,binlog和redo log有可能都未被持久化。因此教程中建议采用“双1”配置,保证在一个事务完成前,binlog和prepare状态的redo log被持久化,以保证能恢复数据。

  2. 客户端发出提交“提交事务”命令后,服务器崩溃,客户端没有收到response,这种情况下,只要binlog已持久化,即视为事务已完成,需要用相应的redo log恢复数据。

  3. 数据的持久化,即“flush脏页”,必然是异步的。

 

 

2. 服务器损毁,服务器上数据损坏或丢失,如何恢复数据和服务

这个问题分两种情况,一是主库损毁,二是从库损毁。两种情况都要利用备份。

 

2.1 主库损毁:

如果做了热备份,就可以将备库切换为新的主库。见上文的“主备切换”。

如果原主库上的binlog尚未被发送到备库,会发生数据损失。

binlog被发送到备库,转存为relay log后再被执行。这里有个时间差。只要业务上能接受,应在relog log都被执行后再开放服务(至少把写操作放在这个时间点后)。

如果没有热备,那就只能用 全量备份 + 全量备份时间点之后的binlog备份 来恢复。数据损失大。

 

2.2 从库损毁

从库损毁,只要主库正常,数据不会丢失。重建从库即可。

先把从库恢复到某个时间点的数据版本,再执行这个时间点之后的binlog。前一步通过物理拷贝恢复,后一步为逻辑恢复。完成这个操作后,再从主库获取后续的binlog(用位点或GTID找齐)。

从库损毁,主要考虑的是应用的影响,需要尽快发现问题,把原来指向从库的请求重定向到其他库,并通知运维人员,尽快重建从库。

尽快发现数据库出现异常,这很重要,早发现早处理,减少对业务造成的影响。这也是HA的基础。

 

判断数据库是否出现问题,有很多种方式,见第29讲,这里不再赘述。

 

3. 误删数据,如何恢复(第31讲)

 

误删行:

根据binlog,flashback(binlog_format=row,binlog_row_image=FULL)

恢复操作不要直接在主库上执行。在别的库上执行,并确认后,再将其恢复回主库。

 

误删库/表:

全量备份,加增量日志恢复。重放增量日志时,跳过误操作的那个语句。最好使用GTID模式。

要求线上有定期的全量备份,并且实时备份binlog。

因为全量备份可能是数天前的,重放增量日志很慢,要着重考虑如何加速恢复速度。

 

rm删除数据

即上一条,服务器损毁、数据损坏的情况。

建立有高可用机制的MySQL集群应对这种情况,并做好备份。

 

强调两点:

- 做好预案,尽量把恢复过程固化为工具定期演练

- 预防数据误删,例如:只分配必要的权限,删除前先做标记(更新、重命名)。

 

 

4. 系统压力超过单个数据库服务器的能力,如何分布到多个服务器(第28讲)

 

一主多从结构,主库可读写,从库只读,这是典型的读写分离结构,以分摊主库的压力。

在这种结构下,客户端访问数据库服务,有两种方案

  1. 客户端自行制定访问哪个库

  2. 通过一个proxy层,由proxy来选择访问哪个库

 

两种方案,都会遇到“过期读”的问题。即由于存在同步延迟,在从库上读到的不是最新数据。

存在几种不同的处理方案:

  1. 强制走主库,由客户端判断业务上是否必须读取最新的数据,是则指定访问主库。

  2. sleep,多用在写完之后的读,例如发帖后的查看,控制延迟1秒再发查看请求。看起来很笨拙,但很实用。主从延迟,正常情况下不超过1s。

  3. 等待从库获取最新数据,这又可细分3种方法
     - 等待 seconds_behind_master = 0
     - 先查已接收的最新位点,等待从库执行的最新位点跟前者一致
     - 先查备库已收到的所有日志的GTID集合,等待这些事务在从库上都已经被执行

后两种方法,只能保证已接收的日志都已经被执行,无法处理主库执行后,从库还未接收日志的情况。为了解决这个问题,需要结合 semi-sync 机制。

 

 

5. 数据库性能急剧下降,怎么办(第22讲)

 

首先分析原因,按照原因,对症下药。必要时,牺牲一定的可靠性,来提升可用性。

可能的原因:

连接风暴、慢查询、QPS突增、长事务、online DDL、死锁检测。

 

应对策略

  • 白名单、账号管理,可用于屏蔽来自特定服务器、特定应用的请求,避免局部问题拖垮整体。

  • sql动态重写,可临时屏蔽大量占用资源的问题sql,或强制其使用正确的索引。

  • online DDL是风险比较高的操作,最好在从库上执行,然后做主从切换,再在原主库上执行。

  • 长事务往往会带来并发问题,应进行监控,发现问题,及早解决。

 

这里要再次强调下:

  1. “消灭问题”优于“解决问题”。设立规范、流程,减少人为操作失误。良医治未病。

  2. 建立监控体系,定期监测长事务、慢SQL等问题,尽早发现,不让小问题堆积成大问题。

  3. 问题应对方法流程化、工具化,定期演练,遇到问题时才能快速响应。功夫在平时。

 

 

本文内容为丁奇老师《MySQL实战45讲》的学习笔记,只是一个提纲。

这门课程的内容和组织方式,每一讲的思考题、大家的留言、老师的点评,都非常棒。

继续推荐。

 

 

黄鹤

2019-12-03

参与评论 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

黄鹤

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值