MySQL数据安全常用解决方案.docx
- 文档编号:26943548
- 上传时间:2023-06-24
- 格式:DOCX
- 页数:20
- 大小:2.06MB
MySQL数据安全常用解决方案.docx
《MySQL数据安全常用解决方案.docx》由会员分享,可在线阅读,更多相关《MySQL数据安全常用解决方案.docx(20页珍藏版)》请在冰豆网上搜索。
MySQL数据安全常用解决方案
MySQL数据安全常用解决方案
一、MySQL高可用工具
1)Keepalived/Heartbeat
1、keepalived是什么?
Keepalived软件起初是专为LVS负载均衡软件设计的,用来管理并监控LVS集群系统中各个服务节点的状态,后来又加入了可以实现高可用的VRRP功能。
因此,Keepalived除了能够管理LVS软件外,还可以作为其他服务(例如:
Nginx、Haproxy、MySQL等)的高可用解决方案软件。
Keepalived软件主要是通过VRRP协议实现高可用功能的。
VRRP是VirtualRouterRedundancyProtocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能够保证当个别节点宕机时,整个网络可以不间断地运行。
所以,Keepalived一方面具有配置管理LVS的功能,同时还具有对LVS下面节点进行健康检查的功能,另一方面也可实现系统网络服务的高可用功能。
keepalived官网http:
//www.keepalived.org
2、keepalived服务的三个重要功能
1.管理LVS负载均衡软件
2.实现LVS集群节点的健康检查中
3.作为系统网络服务的高可用性(failover)
3、Keepalived高可用故障切换转移原理
Keepalived高可用服务对之间的故障切换转移,是通过VRRP(VirtualRouterRedundancyProtocol,虚拟路由器冗余协议)来实现的。
在Keepalived服务正常工作时,主Master节点会不断地向备节点发送(多播的方式)心跳消息,用以告诉备Backup节点自己还活看,当主Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的IP资源及服务。
而当主Master节点恢复时,备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色。
那么,什么是VRRP呢?
VRRP,全称VirtualRouterRedundancyProtocol,中文名为虚拟路由冗余协议,VRRP的出现就是为了解决静态踣甶的单点故障问题,VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。
4、keepalived原理
a)keepalived组件图
keepalived也是模块化设计,不同模块复杂不同的功能,它主要有三个模块,分别是core、check和VRRP,其中:
core模块:
为keepalived的核心组件,负责主进程的启动、维护以及全局配置文件的加载和解析;
check:
负责健康检查,包括常见的各种检查方式;
VRRP模块:
是来实现VRRP协议的。
systemcall:
系统调用
watchdog:
监控check和vrrp进程的看管者,check负责检测器子进程的健康状态,当其检测到master上的服务不可用时则通告vrrp将其转移至backup服务器上。
除此之外,keepalived还有下面两个组件:
libipfwc:
iptables(ipchains)库,配置LVS会用到
libipvs*:
配置LVS会用到
注意,keepalived和LVS完全是两码事,只不过他们各负其责相互配合而已。
keepalived正常启动的时候,共启动3个进程:
一个是父进程,负责监控其子进程;一个是VRRP子进程,另外一个是checkers子进程;
两个子进程都被系统watchlog看管,两个子进程各自负责复杂自己的事。
Healthcheck子进程检查各自服务器的健康状况,,例如http,lvs。
如果healthchecks进程检查到master上服务不可用了,就会通知本机上的VRRP子进程,让他删除通告,并且去掉虚拟IP,转换为BACKUP状态。
b)keepalived高可用架构示意图
Keepalived主要用作RealServer的健康状态检查以及LoadBalance主机和BackUP主机之间failover的实现。
Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机,或工作出现故障,Keepalived将检测到,并将有故障的web服务器从系统中剔除,当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器。
c)文字,表述
Keepalived的工作原理:
Keepalived高可用对之间是通过VRRP通信的,因此,我们从VRRP开始了解起:
1)VRRP,全称VirtualRouterRedundancyProtocol,中文名为虚拟路由冗余协议,VRRP的出现是为了解决静态路由的单点故障。
2)VRRP是通过一种竟选协议机制来将路由任务交给某台VRRP路由器的。
3)VRRP用IP多播的方式(默认多播地址(224.0_0.18))实现高可用对之间通信。
4)工作时主节点发包,备节点接包,当备节点接收不到主节点发的数据包的时候,就启动接管程序接管主节点的开源。
备节点可以有多个,通过优先级竞选,但一般Keepalived系统运维工作中都是一对。
5)VRRP使用了加密协议加密数据,但Keepalived官方目前还是推荐用明文的方式配置认证类型和密码。
介绍完VRRP,接下来我再介绍一下Keepalived服务的工作原理:
Keepalived高可用对之间是通过VRRP进行通信的,VRRP是遑过竞选机制来确定主备的,主的优先级高于备,因此,工作时主会优先获得所有的资源,备节点处于等待状态,当主挂了的时候,备节点就会接管主节点的资源,然后顶替主节点对外提供服务。
在Keepalived服务对之间,只有作为主的服务器会一直发送VRRP广播包,告诉备它还活着,此时备不会枪占主,当主不可用时,即备监听不到主发送的广播包时,就会启动相关服务接管资源,保证业务的连续性.接管速度最快可以小于1秒。
2)MHA
1、MHA介绍
方案介绍:
MHA(MasterHighAvailability)是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库的高可用,MHA通过从宕机的主服务器上保存二进制日志来进行回补,能在最大程度上减少数据丢失。
MHA由两部分组成:
MHAManager(管理节点)和MHANode(数据节点)。
MHA可以单独部署在一台独立的机器上管理多个master-slave集群,MHANode运行在每台MySQL服务器上,主要作用是切换时处理二进制日志,确保切换尽量少丢数据。
MHAManager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master,整个故障转移过程对应用程序完全透明。
2、MHA架构
3、MHAfailover过程:
a.检测到Master异常,进行一系列判断,最后确定Master宕掉;
b.检查配置信息,罗列出当前架构中各节点的状态;
c.根据定义的脚本处理故障的Master,VIP漂移或者关掉mysqld服务;
d.所有Slave比较位点,选出位点最新的Slave,再与Master比较并获得binlog的差异,copy到管理节点;
e.从候选节点中选择新的Master,新的Master会和位点最新的Slave进行比较并获得relaylog的差异;
f.管理节点把binlog的差异copy到新Master,新Master应用binlog差异和relaylog差异,最后获得位点信息,并接受写请求(read_only=0);
g.其他Slave与位点最新的Slave进行比较,并获得relaylog的差异,copy到对应的Slave;
h.管理节点把binlog的差异copy到每个Slave,比较Exec_Master_Log_Pos和Read_Master_Log_Pos,获得差异日志;
i.每个Slave应用所有差异日志,然后resetslave并重新指向新Master;
j.新Masterresetslave来清除Slave信息。
4、MHA优势/缺点
优点
1.代码开源,方便结合业务场景二次开发
2.故障切换时,可以修复多个Slave之间的差异日志,最终使所有Slave保持数据一致,然后从中选择一个充当新的Master,并将其它Slave指向它。
3.可以灵活选择VIP方案或者全局目录数据库方案(更改MasterIP映射)来进行切换。
缺点:
1.无法保证强一致,因为从故障Master上保存二进制日志并不总是可行,比如Master磁盘坏了,或者SSH认证失败等。
2.只支持一主多从架构,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库。
3.采用全局目录数据库方案切换时,需要应用感知变化,因此对应用不透明,因此要保持切换对应用透明,依然依赖于VIP。
4.不适用于大规模集群部署,配置比较复杂。
5.MHA管理节点本身的HA无法保证。
二、MySQL数据同步复制工具
1)MySQL自带数据复制模式
MySQL支持异步复制、半同步复制。
复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器。
主服务器将更新写入二进制日志文件,这些日志记录被发送到从服务器。
从服务器接收任何更新日志,然后重新执行这些更新日志。
MySQL复制原理
建立主从关系后,主服务器如果有数据修改之后,BINLOG会更新,从服务通过IO-Thread读取主服务器的BINLOG到本地的RelayLog,再通过SQL-Thread对其进行重放(replay),从而同步到本地。
MySQL有异步复制、半同步复制两种模式。
a)主从异步同步配置
注意:
配置主从同步时master和slave的配置文件中的server-id(整数值)要配置为不同。
1.Mysqlmaster-1配置操作步骤:
(1)创建数据同步的用户
GRANTREPLICATIONSLAVE,REPLICATIONCLIENTON*.*TOrepl@'%'IDENTIFIEDBY'repl';
(2)执行SHOWMASTERSTATUS;查看日志点
结果:
2.Mysqlmaster-2配置操作步骤:
(1)执行以下语句来定义连接master服务器:
CHANGEMASTERTOMASTER_HOST=’192.168.8.11’,#主mysqlIP
MASTER_PORT=3306,#主mysqlPort
MASTER_USER='repl',MASTER_PASSWORD='repl',##主mysql的同步用户和密码
MASTER_LOG_FILE='mysql-bin.000015',#主mysql的日志文件
MASTER_LOG_POS=529;#主mysql的日志文件的position
(2)启动slave:
mysql>startslave;#停止slave:
mysql>stopslave;
(3)执行SHOWSLAVESTATUS\G语句:
结果:
如果Slave_IO_Running:
Yes,Slave_SQL_Running:
Yes这两项为yes说明主从同步配置成功。
然后按照Master2为主,Master1为从再次配置,即可实现主主互备配置。
b)半同步复制
在采用半同步复制时,配置按照下面方式进行:
1.在Mysqlmaster-1端操作:
mysql>INSTALLPLUGINrpl_semi_sync_masterSONAME'semisync_master.so';
修改配置文件f内容如下,然后重启mysql
[mysqld]
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000#1second
2.在Mysqlmaster-2端
mysql>INSTALLPLUGINrpl_semi_sync_slaveSONAME'semisync_slave.so';
修改配置文件f内容如下,然后重启mysql
[mysqld]
rpl_semi_sync_slave_enabled=1
4.在Mysqlmaster-1和Mysqlmaster-2再按照同步配置的方法进行配置即可,实现半同步复制。
2)阿里巴巴数据库同步工具otter
1、项目背景
阿里巴巴B2B公司,因为业务的特性,卖家主要集中在国内,买家主要集中在国外,所以衍生出了杭州和美国异地机房的需求,同时为了提升用户体验,整个机房的架构为双A,两边均可写,由此诞生了otter这样一个产品。
otter第一版本可追溯到04~05年,此次外部开源的版本为第4版,开发时间从2011年7月份一直持续到现在,目前阿里巴巴B2B内部的本地/异地机房的同步需求基本全上了otter。
目前同步规模:
同步数据量6亿
文件同步1.5TB(2000w张图片)
涉及200+个数据库实例之间的同步
80+台机器的集群规模
2、项目介绍
名称:
otter['ɒtə(r)]
译意:
水獭,数据搬运工
语言:
纯java开发
定位:
基于数据库增量日志解析,准实时同步到本机房或异地机房的mysql/oracle数据库.一个分布式数据库同步系统
3、工作原理
原理描述:
1.基于Canal开源产品,获取数据库增量日志数据。
什么是Canal,请点击
2.典型管理系统架构,manager(web管理)+node(工作节点)
a.manager运行时推送同步配置到node节点
b.node节点将同步状态反馈到manager上
3.基于zookeeper,解决分布式状态调度的,允许多node节点之间协同工作.
4、项目资料
otter安装配置:
ottermanager安装配置:
otternode安装配置:
5、部分web截图:
图1(channel管理)
图2(映射关系列表)
图3(数据源配置)
图4(数据表管理)
二、MySQL数据备份恢复工具
详细操作手册:
1)mysqldump
1、mysqldump详解
mysqldump是MySQL安装包自带的一个数据库备份程序。
用法:
mysqldump[options][db_name[tbl_name...]]
描述:
mysqldump是一个客户端逻辑备份的工作,备份的SQL文件可以在其他MySQL服务器上进行还原。
如需备份,则至少需要对该表的select权限,需要备份视图则需要改账户具有SHOWVIEW权限,触发器需要TRIGGER。
如需锁表,则不可使用--single-transaction选项。
其他权限暂未列出。
如需还原,则需要对应的执行权限,如create表,则需要对该库的create权限。
mysqldump导出可以包括ALTERDATABASE与相关更改,其中包括导出元数据、更改字符编码,在导入对应文件时,相应的权限更改也会发生影响。
如果在服务器上备份的表均为MyISAM,也可以使用mysqlhotcopy来完成任务
2、mysqldump的优势
从性能和伸缩性考虑,mysqldump的优势包括:
在输出之前可以很方便的查看或编辑文件,你还可以克隆数据库与DBA的工作,或者将生产环境下的数据进行微小测试。
这不是作为快速备份或可伸缩性很强的方案。
即针对不同大小的数据需要安排合理时间,在需要还原时速度并不快,因为需要重新进行I/O、创建索引等。
对于大量数据来说,物理备份可能更为合适,因为他可以快速还原。
如果你的表以Innodb引擎为主,可以考虑使用MySQL的mysqlbackup命令。
因为他提供了最好的Innodb备份:
它也可以备份其他如MyIsAM与其他存储引擎;提供了更多的备份参数进行选择。
如果你的表以MyISAM引擎为主,可以考虑使用mysqlhotcopy来替代,它可能比mysqldump表现更为好。
mysqldump可以行级导出数据,或者也可以将整个表载入内存一次性导出,如果将所有数据导入内存可能会面临内存缓冲区不够的问题。
如果要行级导出数据,使用--quick选项(或者--opt,它支持--quick)。
--opt选项是默认选项,所以为了保证内存缓冲区,使用--skip-quick。
如果你使用高版本的mysqldump来备份一个低版本的MySQL服务器中的数据,使用--skip-opt代替--opt或者--extended-insert选项。
2)xtrabackup
1、xtrabackup详解
xtrabackup是Percona公司CTOVadim参与开发的一款基于InnoDB的在线热备工具,具有开源,免费,支持在线热备,备份恢复速度快,占用磁盘空间小等特点,并且支持不同情况下的多种备份形式。
xtrabackup的官方下载地址为
xtrabackup包含两个主要的工具,即xtrabackup和innobackupex,二者区别如下:
(1)xtrabackup只能备份innodb和xtradb两种引擎的表,而不能备份myisam引擎的表;
(2)innobackupex是一个封装了xtrabackup的Perl脚本,支持同时备份innodb和myisam,但在对myisam备份时需要加一个全局的读锁。
还有就是myisam不支持增量备份。
2、备份过程
(图1innobackupex备份过程)
在图1中,备份开始时首先会开启一个后台检测进程,实时检测mysqlredo的变化,一旦发现redo中有新的日志写入,立刻将日志记入后台日志文件xtrabackup_log中。
之后复制innodb的数据文件和系统表空间文件ibdata1,待复制结束后,执行flushtableswithreadlock操作,复制.frm,MYI,MYD,等文件(执行flushtableswithreadlock的目的是为了防止数据表发生DDL操作,并且在这一时刻获得binlog的位置)最后会发出unlocktables,把表设置为可读可写状态,最终停止xtrabackup_log。
3、全备恢复
这一阶段会启动xtrabackup内嵌的innodb实例,回放xtrabackup日志xtrabackup_log,将提交的事务信息变更应用到innodb数据/表空间,同时回滚未提交的事务(这一过程类似innodb的实例恢复)。
恢复过程如下图:
(图2innobackupex恢复过程)
4、增量备份
innobackupex增量备份过程中的"增量"处理,其实主要是相对innodb而言,对myisam和其他存储引擎而言,它仍然是全拷贝(全备份)
"增量"备份的过程主要是通过拷贝innodb中有变更的"页"(这些变更的数据页指的是"页"的LSN大于xtrabackup_checkpoints中给定的LSN)。
增量备份是基于全备的,第一次增备的数据必须要基于上一次的全备,之后的每次增备都是基于上一次的增备,最终达到一致性的增备。
增量备份的过程如下,和全备的过程很类似,区别仅在第2步。
(图3innobackupex增量备份过程)
5、增量备份恢复
和全备恢复类似,也需要两步,一是数据文件的恢复,如图4,这里的数据来源由3部分组成:
全备份,增量备份和xtrabackuplog。
二是对未提交事务的回滚,如图5所示:
(图4innobackupex增量备份恢复过程1)
(图5innobackupex增量备份恢复过程2)
3)思特奇分布式数据库web运维平台数据备份恢复
1、设计文档
2、实现功能
基于分布式数据库运维平台,创建可定制化备份策略的备份任务:
1)支持一次备份整个集群的MySQL或者根据业务系统灵活选择多个MySQL节点进行备份
2)备份任务的周期、类型、时间等策略可灵活定制化
3)可以实时监控查看和管理备份的集群MySQL各个节点备份状态
4)可以实时查看和管理备份的集群MySQL各个节点备份文件
5)支持全量备份、增量备份、where条件备份
3、部分web菜单截图
图1(创建新的备份任务)
图2(查看备份任务详情)
图3(查看备份任务结果)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- MySQL 数据 安全 常用 解决方案
![提示](https://static.bdocx.com/images/bang_tan.gif)