做了这么久的 DBA，你真的认识 MySQL 数据安全体系？

作者介绍：

强昌金
去哪儿网高级DBA
2015年加入去哪儿，担任MySQL DBA，主要负责去哪儿数据库管理平台的开发、MySQL和Redis的运维。在数据库方面，具有丰富的数据库运维、性能优化经验。

给大家分享下有关MySQL在数据安全的话题，怎么通过一些配置来保证数据安全以及保证数据的存储落地是安全的。

我是在2014年加入陌陌，2015年加入去哪儿网，做MySQL的运维，包括自动化的开发。

接下来我将从四个方面给大家介绍一下，数据库怎么通过一些配置做到数据安全的。

单机安全
集群安全
备份安全
发展

现在的行业中，数据是一个非常重要的资产。

数据是怎么保证安全呢？在日常中，大家都认为一些商业的数据库能更好的保证数据安全。他们认为对于新兴的MySQL来说，一致认为可以在互联网使用，因为互联网的数据丢了也就无所谓了，我感觉他们这是对MySQL数据库的一个误解。

我所说的数据安全是指数据落地的安全，而不是遭到黑客攻击，也不包括网络安全。

在企业刚开始起步的时候有可能资源有限，只使用单机，这时候单机有可能部署一个。

随着企业的发展，有可能单机会存在数据崩溃的问题，这将导致整个数据不可用的。因此就会往集群化的方向发展，会利用主从模式，保证数据分布到多个节点，即使某个节点崩溃后，还有其他节点是可用的。

这样就能保证真正的数据不丢吗？有可能机房出现了网络故障，或者整个机房宕机了。今年也遇到过很多整个数据不可用，备份也不可用的情况，这时候数据就丢失了。

为了更好的是保证数据安全，要进行备份。要对数据进行本地备份和远程备份，这样集群不可用的时候利用备份进行恢复。

第四方面，介绍一下MySQL基本的发展。

下面详细的对这四个部分来进行阐述。

一. 单机安全

单机安全会涉及到两个配置参数：

Double Write
innodb_flush_log_at_trx_commit

下面详细说明。

1.1 Double Write

我们企业在刚刚起步的时候只有一个节点，怎么保证我们的数据落盘？在MySQL宕机或者系统宕机数据库启动的时候它能够启起来。在启动过程中，他们会检测数据页是否是正常的，这时候我们会引入一个叫Double Write。

什么叫Double Write？对一个页面的所有操作，包括页头、页面等等，这原本是物理的操作。但是为了节约日志量，把它改成逻辑的，就会记录包括空间数、内容字段等等，等到有必要的时候才真正的将这些逻辑写变成物理写。

在写的过程中，首先保证所写的页面是正确的。如果一个页面在写的过程中由于多次写导致页面断裂，这样就不可写。这时候我们就需要一个Double Write，等于现在一个是镜像，另一个是备份。

MySQL 5.7之前有一个2M的缓存。如果在校验的过程中，这个页面有问题，就会利用Double Write将两个页面进行拷贝回来，这样我们的数据库就恢复到可用的状态。

四个问题：

两次写本身页面断裂会不会有问题？
它所要操作页面之前，记录的是数据库之前的状态是一致的。这时页面出现问题，本身就不会去写入了，就不会出现问题。
最近数据是不是一直在覆盖？
因为我们知道只有2M的空间，因此会一直覆盖去写。
性能问题？
我们知道在Double Write有两次写的。这对我们的操作是不是也有两次？我们知道它有一个缓存空间，当缓存空间满的时候，会将逻辑写变成顺序写，这对磁盘的影响是比较小的，不会导致性能消耗，但是也会带来一点点性能消耗。
可不可以没有Double Write？
有可能。

1.2 innodb_flush_log_at_trx_commit

数据库宕机分为两种情况：

数据库宕机服务器正常
服务器宕机

在宕机的时候，对提交到数据库的事务如果没有写到redo log文件中，数据就会丢失。

innodb_flush_log_at_trx_commit参数的三个值的策略：

这三个参数对数据库宕机是不是会导致数据的丢失呢？

在值为0的时候，每秒写入，在数据库宕机或者系统宕机时，都会有数据的丢失的。

在值为1的时候，每次操作都会去写入到真正的redo log的磁盘文件中，这时候不管数据库宕机还是操作系统宕机，都不会丢失。在启动的时候，redo log在文件中是可以进行恢复的。

在值为2的时候，是刷到操作系统的cache中，数据库宕机了，但是操作系统是完整的，能够写入到磁盘中，这时候数据是不会丢失的。

二. 集群安全

在单机的过程中，通过两个参数保证我们的数据落盘。然而，有可能服务器宕机了，再也启动不起来了，这时我们的数据等于是全部丢失了，或者可以利用备份数据进行恢复一部分的数据，这种情况对我们的企业就会导致一定的影响。

主从复制

异步复制
半同步复制

MySQL Galera Cluster

此时，我们可以通过集群的模式，如搭建一主多从或者多主等等，来保证我们的数据在多个节点都有的，即使一个节点宕机以后，可以把读写服务切换到另一个节点，保证数据可用的。

2.1. 主从复制

2.1.1 sync_binlog

主从复制是异步的模式。

在默认情况下，我们都会使用简单的主从复制进行保证一主多节点进行同步。

在复制过程中最重要的一个东西就是sync_binlog，它在等于0的时候，每次刷新到cache中；等于1的时候会同步到磁盘中。

这个参数对数据丢失的影响：

同样数据库宕机分两种，一种是系统的宕机，一种是数据库宕机。数据库宕机已经写入到OS的cache中，因此不会丢失。如果恰好这时操作系统宕机，就等于丢失OS cache了，如果sync_binlog 值为0，将会丢失数据了。

2.1.2 binlog_format

二进制日志格式有三种：

STATEMENT
MIXED
ROW

我们现在主要使用ROW格式，会存在一个问题，就是我们日志量会稍微大一些。

2.1.3 与复制POS点相关参数

在主从复制过程中，有两个重要的文件:

一个是记录master-info
一个是记录relay-log-info

从MySQL 5.7版本，已经使用表结构了，建议这么做。

这两个sync-master-info和sync-relay-log-info参数，如果存在宕机，我们能知道之前复制的点在什么位置。

relay_log_recovery个参数，如果设置为1，它会找到MySQL线程最新执行的最后的位置，然后利用那个位置，重新创新一个relay-log，这个值对我们来讲非常重要。如果不设为1，会导致我们在启动过程中，点不是最新的点，会导致事物的冲突，甚至会导致主从复制的冲突。

2.2 半同步

主要说说一下三点：

半同步复制特性
半同步与异步对比
半同步参数: rpl_semi_sync_master_wait_point

2.2.1 半同步复制特性

主库和从库会存在延时的，可能从库没有接收到主库的binlog信息。

MySQL 推出了一个半同步复制，就是主库会等待从库中至少一个节点，是否真正的获取到binlog日志，并且刷新到redo log文件中。

半同步有哪些特性呢？

从库告知主库是否为半同步
主库事务提交会被阻塞
从库写入relay log后通知主库
主库等待超时后，自动转换为异步复制
主从必须同时开启半同步

首先会告诉主库自己是否配置了半同步，并且主库提交事物的时候，这个线程会进行阻塞，等待从库进行回复。如果真的没有回复，它会把这个从库降成异步复制。如果有回复，进行确认后，主库的线程就会继续做其他的事务，那么在这个过程中，它是会被阻塞掉的。

从库接收到主库的binlog后，会写入到redo log。

在半同步的复制过程中，每个事务提交的时候，会等待至少一个从节点，如果从节点已经获取到了binlog，这时候主节点才会真正的提交做后续的操作，这时候就可以保证至少有一个节点是和主节点的数据是一致的。

2.2.2 半同步复制特性

最主要的区别在于半同步复制能保证至少一个从节点会与主节点数据一致性。

2.2.3 rpl_semi_sync_master_wait_point

在半同步过程中，有一个重要的参数rpl_semi_sync_master_wait_point来进行控制，就是主库的线程提交事务后，在整个进程进行等待还是在提交事务以后再去等待。

首先讲一下这两个配置有什么影响。

AFTER_COMMIT提交完进入等待状态，等待一个从库，现场回复一个ACP确认。从库汇报了ACP确认后，进入后续的状态，就是将结果通知到客户端。

在这个状态的情况下，可能会导致从库丢数据，之所以这样是因为我们在引擎层已经提交了，这时候我们在等待的过程中，其实在这个主库上的其它会话是能够知道这个事务已经提交的结果。但是如果此时主库还在等待过程中主库宕机了，并且不可恢复，这时从库有可能没有接收到数据的，在主库上它认为这个事务已经提交成功了，就会导致从库根本没有拿到这个binlog，因此会丢失这个事务的数据。

为了解决这个问题，在MySQL 5.7会推出另外一种状态进行等待—-AFTER_SYNC，就是同步完立马进行等待。

如果这时候主库宕机了，从库有可能接收到这个binlog，并且应用到从库的数据库中，这时主库还没有进入到提交，因此主库的数据是没有提交的，有可能从库会多出一部分数据。

我个人认为，多出的数据，总比丢失的好。当我们的服务切入到从库，服务在处理的过程中，会根据多出来的数据做相应的处理，总比没有相对来说更好一些。