标签:cpu核数 中断 内存 就是 需要 操作系统 strong 应用程序 巡检
转自:http://blog.51cto.com/qianzhang/1198503
一. 数据库生命周期
结合软件生命周期、项目的开展,数据库的生命周期,大致可分为这么几个阶段。
1. 规划
在立项后,对于数据库平台的软硬件选型,以及大致的数据库架构。
1.1 配置多少台服务器,服务器的内存大小/磁盘空间、IOPS/CPU核数/网络带宽等;
1.2 选择的操作系统与数据库产品,及相应版本;
1.3 整体架构,比如是否考虑:HA,Scale out, load balance, 读写分离等策略。
2. 开发
开发的工作,通常是在测试环境上进行的,开发结束后搬到生产环境。
2.1 数据库设计;
2.2 SQL编程及调试;
2.3 开发过程中的SQL优化。
3. 实施
开发的数据库程序到生产环境的部署。到这里,基本是项目上线了。后面就进入了运维阶段。
二. 运维做些什么
从上面的图来看,运维是项目上线后的工作。看看从项目上线开始,运维都做了什么。
1. 部署环境
1.1 数据库安装(如果服务器太多,可以选择静默安装);
1.2 参数配置(实例、数据库参数);
1.3 权限分配(登录、数据库用户权限)。
2. 备份/还原
对于数据库来说,有个可用的备份是非常重要的,防止有数据损坏,用户误操作等造成的数据丢失。保证了数据的存在,运维才有意义,否则其他工作做的再好也是白搭。
3. 监控
对于运维来说,首先要保证数据库的运行,然后就是运行中系统的性能。所以监控主要分为这两点:
3.1 数据库运行状态,有没有什么数据库中断或异常、错误或警告?
3.2 数据库性能,有没有什么性能问题或者性能隐患?
4. 故障处理
在监控过程中发现,或者系统用户反馈出来的数据库错误或者警告,进行诊断并修复。
5. 性能优化
在监控过程中发现,或者系统用户反馈出来的数据库性能问题,进行优化。
6. 容灾
容灾只是手段,最终还是为了保证系统的可用性,通常选择的策略有:故障转移集群、镜像、日志传送、异地备份等。
如果在实施时,已经部署了容灾策略,那么这时只要做一些状态监视即可。
也有系统是在上线一段时间之后,才补充部署容灾策略的。
7. 升级/迁移
7.1 升级
通常是在本机进行,硬件不变,比如:更换操作系统、数据库的版本、打补丁;
7.2 迁移
通常是需要升级硬件,比如:更换新的服务器,所以把数据库搬到新的服务器上;
也有在本机“迁移”,只是为了移动数据库文件的位置。
7.3 迁移+升级
不过很多时候,都是在迁移中做升级,也就是换了新的服务器,也换了软件版本。
8. 健康检查
通常叫做巡检或者HealthCheck。可能是每天、每月、每年的。
事实上如果把巡检的内容做到每天、每小时、甚至每X分钟,那就是一个准实时的系统监控。
9. 系统用户反馈的数据库问题
用户反馈出来的任何数据库问题,需要DBA去做处理,即便有时诊断出来并非数据库的问题。
从广义上来看,除去数据库开发外的其他任务,都应该算在运维职责之内。
问:那么数据库运维到底都有哪些日常任务?
答:把上面的每项任务要做的事情一个个罗列出来就可以了。
比如,数据库运行状态监控包括:数据库服务是否中断、磁盘空间、错误日志检查、数据库一致性检查、作业运行状态、索引碎片检查等等。
后面会逐个分解各项任务的详细清单。
三. 运维过程中的问题解决
运维过程中遇到问题时,如果能够通过自己/他人的经验解决,那么固然好;
但如果没有解决思路的话,通常是这样去查:
1. 查日志:操作系统/数据库/应用程序日志中,有没有相关的错误/信息提示;
2. 查错误号:官方文档/网友分享中,有没有解决方案;
3. 如果都没有找到,那么就中奖了,自己分析不出就团队分析,团队分析不出找官方支持,当然有的时候,官方支持也不是一定能解决。
注意:对于在线系统,这么慢慢查下去,时间可能消耗太久,会影响用户体验。通常是优先快速解决问题,那怕只是用临时应急方案,以保证系统的可用性,然后再去分析根本原因,彻底解决,以防止下次再发生。
标签:cpu核数 中断 内存 就是 需要 操作系统 strong 应用程序 巡检
原文地址:https://www.cnblogs.com/gered/p/9269938.html