关于mysql:京东智联云MySQL数据库如何保障数据的可靠性

MySQL 作为以后最风行的关系型数据库，在各个行业的零碎中扮演着最重要的角色。随着大家对数据价值认可的逐渐加深，数据的可靠性是最常被问到的一个问题。MySQL 是如何保证数据可靠性的？京东智联云 RDS-MySQL 又做了哪些优化和新个性来保障用户数据的可靠性和一致性？本篇文章将为大家一一揭秘。

MySQL 如何 保证数据 可靠性

MySQL 的 Innodb 存储引擎反对 ACID（原子性 Atomicity，一致性 Consistency，隔离性 Isolation，持久性 Durability）个性，正是因为保障了一致性和持久性，所以数据才是牢靠的。很多关系型数据库为保障数据库的可靠性，同时最大限度地晋升性能，采纳了预写日志（Write-Ahead Logging）的办法，MySQL 也不例外。它将数据变动先写入日志，而后立即返回给客户端更新胜利，真正的数据再异步更新到磁盘的数据文件。如果两头零碎产生故障，只有日志在数据就不会失落，这就保障了数据的可靠性。

MySQL 写入的日志就是 binlog 和 redo log 文件，上面咱们来介绍下两种日志的写入流程。

binlog写入 机制

事务执行过程中，MySQL 会将所有变更记录到 binlog cache 中，在事务 commit 的时候一起写入 binlog 文件中。

binlog cache 是由参数 binlog_cache_size 管制，默认 32KB，如果事务很大，变更内容超过了 binlog cache，则会写到磁盘中。通过命令 show global status like ‘Binlog_cache_disk_use’; 能够查看 binlog cache 写入磁盘的次数，如果数量过多，倡议调大 binlog_cache_size 参数值。

每个线程都会调配 binlog cache，然而都共用一份 binlog 文件。流程图如下：

在写入到零碎的日志文件中有两个步骤，write 和 fsync。wirte 是写入操作系统的缓存，fsync 是长久化到磁盘文件，这个操作会占用零碎的 IOPS，而它们操作的机会是通过参数 sync_binlog 管制。

l sync_binlog=0，事务提交时，只做 write 操作，由操作系统本人管制 fsync 操作。这个是最危险的，一旦操作系统宕机，binlog cache 中的变更内容全副会失落。

l sync_binlog=1，事务提交时，都会做 write 和 fsync 操作。安全性最高，然而性能损耗也是最大的。

l sync_binlog=N，事务提交时，会做 write 操作，累积 N 个事务时做 fsync 操作。一旦操作系统宕机，会失落 binlog cache 中局部变更内容。

redo log 写入机制

事务执行过程中，也是先写入内存 redo log buffer 中，而后再写入到磁盘文件。其中 redo log buffer 是所有线程共用的。与 binlog 写到文件一样，写 redo log 也有 write 和 fsync 两个操作，它们操作的理论是通过参数 innodb_flush_log_at_trx_commit 管制。

l innodb_flush_log_at_trx_commit=0，事务提交时，只将变更内容写到 redo log buffer，由后盾 Master 线程每秒 write 和 fsync 到磁盘文件。

l innodb_flush_log_at_trx_commit=1，事务提交时，执行 write 和 fsync 操作。这是最平安的配置。

l innodb_flush_log_at_trx_commit=2，事务提交时，只执行 write 操作，即只写到操作系统的缓存中，由后盾 Master 线程每秒 fsync 到磁盘文件。

对于这个参数与数据可靠性之间的关系如下表所示：

innodb_flush_log_at_trx_commit

数据库 过程异样

操作 零碎异样

0

失落最多 1s 的数据

失落最多 1s 的数据

1

不丢数据

不丢数据

2

不丢数据

失落最多 1s 的数据

参数 sync_binlog= 1 与 innodb_flush_log_at_trx_commit= 1 就是 DBA 常说的“双 1”配置，也是线上环境数据最平安最牢靠的配置。

再比照下 binlog 和 redo log 的不同之处：

binlog

redo log

记录 者

MySQL server

Innodb 引擎

记录 工夫

事务 commit 的时候

多种条件触发，随时记录

记录 内容

逻辑日志

row 格局或者 statement 格局

物理日志

数据页的变动，幂等的

两阶段 提交

binlog 和 redo log 是如何配合起到数据可靠性的作用呢，就不得不提到两阶段提交。它能够保障 binlog 和 redo log 的数据一致性。下图是事务提交时两个日志的记录流程：

如果在此过程中呈现零碎异样，每个状态下都是能够保证数据一致性的。

状态

解决

如果 innodb 曾经 commit，那 binlog 肯定有该事务的 event。

事务是一致性的，无需解决。

如果 innodb 曾经 prepare，binlog 曾经有记录该事务的 event，然而 innodb 未 commit。

前滚，innodb 须要持续提交这些事务。

如果 innodb 曾经 preprare，binlog 没有记录 event，阐明从库也没有复制这些 event。

回滚。

如果 innodb 未实现 prepare，binlog 也应该没有记录 event。

回滚。

innodb_suport_xa 参数，这个参数管制是否关上两段式提交。默认开启，如果敞开了，事务则会以不同程序的形式写入 binlog。如果宕机复原、xtarbackup 复原，都是会有数据不统一的危险。这个参数在 MySQL5.7.10 后就废除了，必须开启。

MySQL 集群数据的 一致性

MySQL 倒退到当初，集群也从主备异步复制、半同步复制、group replication 一直倒退和演变。然而它们的外围根底都是 binlog，能够说 MySQL 的数据复制都依赖于它，而集群间的数据一致性更是与 binlog 无关。次要有两个点须要特地留神。

1. binlog的格局。statement、row 和 mixed。statement 格局间接将 SQL 语句记录在 binlog 文件中，因为主从库是两个独立的服务，运行环境齐全不同，所以会呈现不统一的危险，比方执行 delete from t limit 100。所以线上环境倡议应用 row 格局。
2. 数据提早。当从库呈现提早，会造成集群数据不统一。从库提早的起因很多，这里列举以下几个线上经常出现的提早起因：

a) 大事务。binlog 只有在事务 commit 时才会记录到文件，而后从库能力读取到数据变更，所以当有大事务的时候，主库提交后从库才开始执行。

b) 大并发。5.6 和 5.7 版本都反对并行复制，然而并行度无限，当主库并发较高时，从库会呈现提早。

c) 表构造 。 主库表没有主键，binlog 是 row 格局的，主库执大量行数的更新 SQL 时，从库会执行屡次全表扫描，造成提早。

d) 期待锁。从库个别会承当备份性能，应用 xtrabackup 进行备份会执行 FLUSH NO_WRITE_TO_BINLOG TABLES 和 FLUSH TABLES WITH READ LOCK 操作，在非凡状况下，这两个操作会梗塞复制的 SQL 线程，造成提早。

e)

京东智联云 RDS-MySQL数据 平安 的实现

京东智联云 RDS-MySQL 集群应用主从复制架构，为了保障用户存储数据可靠性和安全性，咱们对要害流程做了一系列优化和改善工作。以用户数据安全为己任，以用户体验为核心。

集群环境

1. 物理环境

l 硬件 ， 采纳高性能的 NVME 硬盘，最新型号物理机配置。

l 网络 ， 跨 AZ 机器的网络提早在 1.2ms 以内，配置万兆网卡。

1. 软件环境

l 数据 面，参考京东高并发、高牢靠的业务系统优化教训，京东智联云对 RDS 操作系统配置、MySQL 参数配置做了一些列优化，保障数据库集群数据的可靠性。

l 管制 面，针对集群的提早，有多组提早监控、报警；针对不同提早起因，会触发不同的优化逻辑，主动升高提早。

高可用 切换

当物理机呈现问题或者做数据迁徙时，都会波及 MySQL 集群的高可用操作，因为 MySQL 集群的复制特点，有可能会呈现数据失落的状况。京东智联云 RDS-MySQL 在切换时是要保障用户数据一致性优先的，在判断集群数据齐全牢靠的状况下，再做切换操作，保障用户的数据不失落，不写花。

主备切换逻辑图

MySQL 高可用切换流程的复杂性，不在切换的过程，而是触发切换条件的判断，上面介绍下 RDS-MySQL 主动高可用切换的判断流程。

1. 哨兵服务查看数据库和操作系统状态，发现实例服务异样，则触发多组哨兵服务的数据库服务检查和投票机制，确认服务实在不可用再进行切换流程。
2. 主库实时上报 GTID 信息，如果产生主动高可用，即主库服务不可用时，首先会比照从库的 Retrieved_Gtid_Set 值，确保从库的 IO thread 曾经拉取了主库全副的 binlog 内容。
3. 而后再比照从库的 Retrieved_Gtid_Set 和 Executed_Gtid_Set 范畴值，保障从库拉取的 binlog 全副利用实现。

高可用流程切换实现后，会对集群数据做一致性校验，并触发建设新从库的流程。

备份 复原

数据库备份是数据安全的最重要屏障，当呈现极其状况下，集群所有节点的数据都不可用，就须要依赖备份保证数据的可靠性和安全性。咱们对 RDS-MySQL 的备份、复原流程做了一系列优化，保障用户零碎在灾备时复原工夫尽量短，复原数据尽可能最新。

1. 每日全量备份，实时 binlog 备份；
2. 所有备份上传到对象存储，多备份保留，多区域寄存；
3. 定期做备份数据的有效性验证；
4. 高可用、扩容、删除等重要流程强制做数据库的数据备份；
5. 反对软删除性能，单库表复原性能。

用户 案例

京东智联云 RDS-MySQL 的用户在应用过程中，呈现过很多数据可靠性相干的案例，上面举一些典型案例来分享：

案例 1. 大事务 造成 从库 提早

问题

因为用户并发较大，集群从库呈现提早。

发现

从库对于用户是不可见的，所以从库提早用户是无需感知的。

通过后盾的监控零碎，触发从库提早报警，运维人员才发现这个问题。

解决

后台任务会扫描所有报警信息，当扫描到提早报警后，会联合该实例的其余信息定位故障起因，而后主动调整集群数据库配置，达到升高提早的目标。提早报警解除后，复原集群配置。

意义

RDS-MySQL 局部报警曾经实现了“负载异样检测”、“主动诊断”、“线上配置优化”、“优化成果跟踪”的闭环解决。

可帮忙用户疾速、平安、精确地解决集群数据安全隐患。

案例 2. 用户 误删除 表

问题

用户因为人为误操作，导致删除了线上零碎的局部数据。

发现

用户提工单，想疾速复原删除表的数据到指定工夫点。

解决

控制台提供单库、单表按工夫点疾速复原的性能。技术服务人员间接反馈给用户该性能的应用文档。用户通过自助操作，实现对删除数据的复原操作。

意义

RDS-MySQL 将备份和复原性能用到极致，两类备份形式对应多种复原流程，不便用户疾速、平安地实现复原数据库需要。

RDS-MySQL 复原流程反对：

1. 依据工夫点创立
2. 依据工夫点单库、单表本地复原
3. 依据备份创立和本地笼罩复原

通过上述内容，想必大家曾经对 MySQL 是如何保证数据可靠性有了初步理解，如果还想进一步体验体验 MySQL 服务，请点击【浏览原文】链接体验试用。

原文链接：