(3.2)数据库运维做些什么

转自: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. 如果都没有找到,那么就中奖了,自己分析不出就团队分析,团队分析不出找官方支持,当然有的时候,官方支持也不是一定能解决。

注意:对于在线系统,这么慢慢查下去,时间可能消耗太久,会影响用户体验。通常是优先快速解决问题,那怕只是用临时应急方案,以保证系统的可用性,然后再去分析根本原因,彻底解决,以防止下次再发生。

原文地址:https://www.cnblogs.com/gered/p/9269938.html

时间: 2024-10-07 11:25:06

(3.2)数据库运维做些什么的相关文章

从一个简单的约束看规范性的SQL脚本对数据库运维的影响

原文:从一个简单的约束看规范性的SQL脚本对数据库运维的影响 之前提到了约束的一些特点,看起来也没什么大不了的问题,http://www.cnblogs.com/wy123/p/7350265.html以下以实际生产运维中遇到的一个问题来说明规范的重要性. 如下是一个简单的建表脚本,表面上看起来并没有什么问题.其中创建了3个约束,一个主键约束,一个唯一约束,一个默认值约束,该脚本执行起来没有任何问题. USE Test GO if exists(select 1 from sys.tables

一个兼职DBA的数据库运维经验 小米科技 [email protected] 2011

一个兼职DBA的数据库运维经验 小米科技  [email protected] 2011 报警监控系统粒度太大,不好用(我们公司现状)数据库状况:十个服务器,惠普HP380G7 戴尔R710 ,都做了主从全部sas盘 15K RAID10服务器内存24G数据库跟业务混用,不是专门给数据库用 导致出问题(我们公司现状)备份用的xtrabackup 数据库不大:160G 70G 30G程序支持分库分表 --------------------------问题 io util% 100%(学)正常io

MySQL数据库运维课程

MySQL数据库运维课程 http://www.dataguru.cn/article-4834-1.html?union_site=comm100 课程大纲 第一课:机器选型.系统规划 第二课:安装部署 第三课:压力测试 第四课:性能优化 第五课:字符集和权限安全 第六课:日志系统 第七课:备份与恢复1 第八课:备份与恢复2 第九课:常用工具 第十课:MySQL集群 第十一课:分布式集群 第十二课:集群高可用(HA)和容灾演练 第十三课:自动化运维 第十四课:监控和审计系统 第十五课:成长规划

【数据库运维】数据库(服务器)的时区设置及世界主要地区的时区

[时区设置不当会有什么问题] 当进行海外项目运维的时候,经常会遇到时区设置的问题,如果时区设置不当 或者 相同项目的服务器之间的时区不一致,都会有导致项目的数据异常的风险. 如果数据表的字段使用了date类型的字段,字段的默认值是sysdate,并且程序插入记录的时候使用了字段的默认值,那么就有可能导致数据异常.在修改数据库服务器的时区时,也是需要谨慎操作的. [服务器时间同步的方法] # 时间同步服务器请修改为要求的地址(建议使用Windows的地址,因为世界上大部分个人电脑使用的是Windo

与“十“俱进 阿里数据库运维10年演进之路

导语阿里巴巴集团拥有超大的数据库实例规模,在快速发展的过程中我们在运维管理方面也在不断的面临变化,从物理器到容器.从独占到混布.从本地盘到存储计算分离.从集团内到大促云资源,从开源的MySQL到自研分布式数据库,运维管控进行了自我革新与进化. 作者--谭宇(花名:茂七),阿里巴巴高级技术专家.2009年加入阿里,对分布式系统和数据库领域有很大的兴趣.目前负责阿里巴巴集团数据库中台建设,支撑了集团数据库在容器化.存储计算分离.在离线混部.大规模迁移建站以及智能运维等技术探索与落地. 本文梳理了阿里

数据库运维保障

数据库运维保障 国庆假期本来是可以开开心心去玩的,但是由于某些突发情况,例如天灾导致的数据库故障的情况还是有可能出现 如果出现这种情况不但破坏了国庆假期玩乐的美好心情,节后上班也可能由于没有做好预防措施要遭遇领导挨批. 为了避免发生这种情况,对于公司业务系统的相关运维人员来说不能掉以轻心,一定要做好预防措施. 以下是总结的一些突发情况预防措施 1.做好公司业务系统的监控报警,关键时刻启动应急预案 2.服务器选择双电源服务器,避免单电源故障造成的服务器宕机 3.选择优质的机房,机房一定要有发电机,

XXMySQL数据库运维变更流程

MySQL数据库运维变更流程 草拟时间:2015.11.13制订时间:修订时间: 0x00 目的 规范MySQL数据库的运维人员变更流程,降低操作流程引发的安全隐患,减少人为的错误风险. 0x01.场景 1.业务人员根据业务需要进行数据订正,库表字段结构变更的相关需求.2.运维人员根据数据库日常运维,故障处理与性能优化的变更需求. 0x02.类型 1.数据订正(insert,update,delete相关操作) 重大变更  数据订正表的总数据条数100W以上,且表属于核心业务.        数

DBA_Oracle数据库运维监控(案例)(待学习)

2014-07-27 BaoXinjian 一.摘要 1 - 数据库账户是否锁住监控 2 - 数据库表空间大小 3 - 进程异常停止监控 4 - Session中处理时间过长的进程监控 二.案例1 - 账户是否锁住监控 1. 如何监控 2. 如何处理 三.案例2 - 表空间大小不够监控 1. 如何监控 2. 如何处理 四.案例3 - 进程异常停止监控 1. 如何监控 2. 如何处理 五.案例4 - Session中处理时间过长的进程监控 1. 如何监控 2. 如何处理 DBA_Oracle数据库

谈谈数据库运维自动化

当你写了太多的数据库脚本,做了太多的自动化工作时,面对零散的新需求,尝试自动化时是否需要按使用频率提高自动化水平. 假如有个常见需求,数据库里删除一个大表里的部分数据,或者redis删除一个key 做为运维,需要考虑表有多大,是否要循环删除,删除条件是否有索引, redis的数据类型,如果是list,set,zset,需要考虑大小,是否需要循环清理 第一阶段,把循环删除动作写在一个循环脚本里. 运行脚本完成这次任务 第二阶段,把这个脚本做成通用性,以后再有类似的同样的需求,可以传参过来完成 第三