目的
随着公司业务不断的发展，架设在开源数据库(MySQLRedis等)业务系统数量越来越多。为了科学、有效的管理开源数据库，确保数据库的高效稳定运行的同时，通过制度规范保障企业数据信息安全，给业务系统提供可持续的数据库服务。
适用范围
适用于架设在开源数据库(MySQLRedis)方案下的业务系统使用。
普通常用MySQL+Redis架构部署
3.1MySQL集群和中间件(读写分离+分库，DB+中间件网络分层)
说明：
(1)、项目业务拆分：业务大项目做业务垂直分割，同时MySQL层根据业务需求切割分库（比如：电商项目拆成订单子模块，物流派送子模块，用户子模块等）。数据库根据业务划分切分库后，不同模块之间数据交互通过接口来进行数据通信；
(2)、MySQL存储层：采用MySQLGroupRreplication(组复制)三节点，若项目暂时没有多数据机房部署(多个DC)需求，就使用单主模式(1主2从，见上图：其中M1,S11,S12)。上图关于S13和S14两台从库，一台S14从库专提供给ElasticSearch或者大数据做Binlog增量数据抽取；另一台S13从库可以提供做延迟备份从库，该从库和其主库数据同步延迟12个小时(可配置)，用于防范DDLDML误操作及时恢复；S11和S12为OLTP业务系统读从库，M1为其主库。若程序代码发送含事务SQL包(包含SELECT,INSERT/UPDATE/DELETE代码包)，那么中间件会将该SQL包放到主库执行，即主库也会支持部分读操作流量。
另：若后期有多机房需求，才开启多主模式（例如：2个主或者3个主库都可以写入）。
(3)、DB系统架构和高可用说明：
3.1、MySQL组复制单主模式+proxysql。在当前主库宕机后，组复制会重新选举一个新主库，结合proxysql重新识别新主库和从库，重新将读写路由到生存的DB节点上；
3.2、proxysql+haproxy结合使用，使得proxysql负载均衡，以及负责proxysql的高可用。而中间件proxysql负责MySQL的读写分离以及分库；
(4)、中间件和DB存储层网络分离：中间件和DB层网段分离，采用不同网段IP，APP通过中间件访问数据库，DB层只开通端口映射到中间件层，确保DB安全；
(5)、禁用MySQL的存储过程，函数，触发器和事件：由于MySQL的存储过程，函数，触发器和事件执行性能不好，特别在高并发的应用程序，因此不建议在MySQL数据库上部署存储过程，函数，触发器和事件；
3.2RedisCluster集群
说明：
(1)、目前采用Redis官方集群模型，从节省硬件资源和业务初始上线流量预估，暂使用6节点安装部署(3主3备)，后期可扩容节点。
(2)、由于该RedisCluster层设计目的是为了加速业务程序的访问速度，重点在REDIS内存访问上，因此建议程序代码将系统核心数据在写往REDIS同时，最好在MYSQL库存储一份(虽然Redis集群也会开启RDB和AOF数据存储)；
数据库备份和恢复管理
MySQL集群备份和恢复管理：
(1)、物理备份工具：生产备份和恢复都采用perconaxtrabackup开源工具进行物理文件备份和恢复；
(2)、备份策略为：每天一备份，备份策略分别为：物理全备份+Binlog备份；或者物理全备份+增量日志备份+Binlog备份；
分类说明：
若业务凌晨流量很小或者基本没流量，可以在MySQL主库部署物理备份工具，进行凌晨物理备份。若OLTP业务凌晨流量很高，那么需将物理备份部署在从库(目前可规划大数据从库)，避免影响到业务使用。由于考虑到在从库做备份，当集群从库宕机，修复该从库运维难度增大，故建议当OLTP业务在凌晨时段不繁忙情况下，物理备份放在主库；
若整库容量在项目初期数据量较小，备份时长可控，建议采用物理全备份+Binlog备份。物理全备每天一备份和压缩，本地保留最近3份(视磁盘充足情况)，每次备份完成将最新备份包发往备份中心服务器。Binlog备份每过15分钟(可调整)备份一次最新生成的Binlog日志，并且压缩发送到备份中心服务器；若整库容量较大(比如：容量超过G)，或者备份时间不可控，可以使用物理全备份+增量日志备份+Binlog备份，减少对业务系统的影响。
(3)、恢复管理说明：
(a)当数据库整个集群损毁(包含所有主备库)，MySQL恢复采用全量物理备份进行物理文件恢复，以及利用基于备份包所处的事务位点往后到灾难点前所有BINLOG日志进行事务日志前滚，恢复整库数据；
另：MySQL物理备份包存储目录/data01/DBbackup/xtrabackup/mysql_full_backup_lszc/，binlog事务日志备份/data01/DBbackup/binlog/mysqlbinlog_backup_lszc/，备份脚本所存放的目录为：/data01/DBbackup/scripts/
RedisCluster集群备份和恢复管理
(1)、备份策略：由于每日一备份RDB和AOF文件，并且压缩发往备份中心服务器；
(2)、恢复管理：由于RedisCluster设计目的为了加速应用程序访问数据的速度，因此当集群完全崩溃后，可以直接通过当天凌晨的备份RDB和AOF文件来启动Redis以恢复DB。
5.MySQL数据库权限管理
5.1应用程序访问账号
(1)、应用程序访问DB账号权限控制：应用程序访问MySQLDB权限为(仅为DML语句):INSERT,UPDATE,DELETE,SELECT。该生产库账号权限交由项目负责人保管；
(2)、权限控制目的：
(a)为了确保数据安全和稳定运行，防范开发人员DDL误删除整库数据(droptruncate等)；
(b)由于DDL语句(例如：DB结构变更语句-alter等)在业务流量高峰期执行容易造成DB堵塞进而影响到业务系统使用；
5.2只读账号
(1)、只读账号权限设置和目的：
MySQLDB只读账号权限为：SELECT，该生产库账号权限交由项目负责人保管。设置该账号的目的为了防范开发人员在查询生产系统数据时，发生DML误操作(UPDATEDELETE误操作)，影响业务系统使用。因此建议开发组人员平时查询生产库数据，使用只读账号来访问DB；
MySQL数据库误操作恢复(数据闪回)
DML误操作恢复
根据开发人员反馈的发生DML误操作的时间点，采用binlog2sql闪回工具(部署在主库上)分析那个时间段的BINLOG，然后生成反转SQL语句，重新将数据写入到临时表，提供给开发人员进行数据确认后，最终进行数据恢复到生产环境中。
6.2DDL误操作恢复
根据开发人员反馈的发生误操作的时间点，通过已部署的备份延迟库进行前滚到灾难点前一刻，将数据通过mysqldump导出后，重新导入到主库临时表，进而提供给开发组进行确认后，最终将数据恢复到生产环境。
大数据抽取OLTP系统数据说明
增量抽取方式
在MySQL集群规划中，设计了一台MYSQL从库专门提供给大数据或者ElasticSearch做binlog增量数据抽取使用，这个从库没有业务系统OLTP的流量。
MySQL数据库流量日志获取(中间件生成)
8.1业务访问数据库审计流量获取
业务访问数据库日志流量通过中间件异步生成（DB端也可以部署审计插件有性能损耗，不建议)。用于系统异常数据跟踪，以及问题分析和审计，同时可以为项目全链路日志监控提供数据库端流量日志数据（设置流量日志保留策略，确保磁盘拥有足够的空间）。
MySQL安装部署
9.1MySQL源码编译部署(CentOS7+MySQL8.0.16)
由于需要根据项目实际需求(是否需要满足ACID，是否写多读少或者读多写少)，通过源代码编译选择具体需要的引擎(InnoDB，TokuDB，列式存储引擎等等)。本次安装是采用满足通用OLTP事务型业务的通用安装方法。
(0)、关闭Linux防火墙和禁用SELINUX
systemctlstopfirewalld
systemctldisablefirewalld
vi/etc/selinux/config
SELINUX=disabled
(1)、设置LINUXOS打开文件和资源限制：
vi/etc/security/limits.conf
#Endoffile
*softnofile
*hardnofile
*softnproc
*hardnproc
(2)、安装依赖
yuminstallperlmakeautomakeopensslopenssl-develncursesncurses-develbison*
yuminstallcentos-release-scl–y
yuminstalldevtoolset-4-toolchain–y
sclenabledevtoolset-4bash
注意：由于MYSQL8版本源码时使用了C++14标准来编写，为了确保源代码编译不出现警告或者错误，建议升级GCC版本到5.3来进行编译。
(3)、安装编译工具cmake
wget