mysql在保障数据安全 方面,提供了很多可配置的功能和特性,正确的使用这些功能和特性,是保障数据安全的根本。
单机安全
从单实例的角度来看数据落盘的安全要考虑mysql实例进程挂掉和mysql实例所在的操作系统挂掉的情况,类似于其他关系型数据库,mysql提供了undo log和redo log来保证数据库非正常重启后数据恢复的机制,同时mysql采用了热油的double write机制来保证写入磁盘数据的完整性和正确性,double write可以采用参数innodb_doublewrite来控制,而且日志刷盘的策略,有个非常重要的参数叫innodb_flush_log_at_trx_commit,这个参数取值的不同决定了日志刷盘策略的不同,也决定了mysql提供的数据安全级别的不同。
集群安全
在任何时候,都可能会出现数据库服务器硬件或操作系统故障,继而导致无锡服务器无法启动,操作系统不能正常加载,或者是mysql进程无法启动的情况,这时候,要保障mysql的数据库安全,需要借助mysql集群部署,并根据mysql的特性正确配置,在使用mysql集群的过程中,又有两种截然不同的处理思路。
*使用mysql原生的replication来搭建基于master-slave脱坡结构的异步mysql集群,mysql开发者很早就意思到数据库复制的重要性,2000年左右就已经开始支持replication,随着mysql功能的不断健全,mysql对replication支持也越来越完善,binlog的存储优化及可控的刷盘策略,replication信息存储,半同步机制,多线程复制技术,多源复制技术等,最终都优化了mysql集群的搭建,为mysql数据安全提供了保障。
备份安全
如果碰到了极端的情况,我们提供线上服务的mysql主库宕机,同时这个集群的其他从库也不可用,那么,如果要保障数据安全,唯一可以依赖的就是数据库的备份了,正确及时有效的数据库备份时必不可少的,mysql是在生产中久经验证的,其支持备份的各种工具和方案也是层出不穷,比较流行的mysql备份工具由percona出品的percona xtrabackup,大厂一般用NBU备份恢复。
mysql实例安全保证
在mysql内部,有很多机制来保证数据库自身的数据安全,主要关注innodb引擎,从innodb管理机制原理说起,逐步深入,并且结合mysql的各种参数组合对数据库安全方面的影响。
double write
保证了数据页的正确性,虽然开启了double write之后,每个页面都写了两遍,这对数据库性能有一定的影响,但是由于所写的页面都缓存到内存中,每一部分的缓存空间慢了之后才真正写入到文件中,而且两次写入时将若干数量的页面组合起来形成连续的空间入到两次写的空间中,这样就形成了顺序写,对于磁盘来说,顺序写消耗的性能比较低,实际上经过测试,两次写使性能降低了10%左右,但是对于SSD来说,两次写已经不是问题,如果不开启此参数,可能导致页面写失败,那么mysql在宕机时可能导致数据库无法启动,丢失数据。
REDO LOG
REDO LOG是用来做数据库 crash recovery的,这时保证数据库安全非常重要的功能之一,redo日志记录了所有对innodb数据库的修改操作,在innodb存储引擎中,一般默认有两个日志文件,数据库创建之后,会自动新建两个名为ib_logfile0,ib_logfile1的文件,如果整两个文件不存在,innodb在启动的过程中,会根据配置的参数或默认值,重新创建redo log。
REDO LOG刷盘机制
当提交事务时,可以通过参数innodb_flush_log_at_trx_commit来控制REDO LOG写入的机制,参数不同,产生的行为不同。
-innodb_flush_log_at_trx_commit=0:当事物提交时,mysql不会处理日志缓存区的内容,也不会去处理日志文件的刷盘操作,由mysql的后台master线程每个1秒将缓存区的文件刷新到日志文件中。
-innodb_flush_log_at_trx_commit=1;事务提交时,会将日志缓冲区的日志写入到文件中,同时会刷新到磁盘中,保证数据库事务完全不会丢失。这种设置影响数据库性能。
-innodb_flush_log_at_trx_commit=2:事务提交时,会将日志缓存区日志写入到文件中,但是不会刷新到磁