### **在互联网时代可以说数据是公司最宝贵的资产，不出问题则罢，出问题就是满地是血的状况。** **小事故公司可能收入受损失，大事故可能直接导致公司破产** ``` 举例:最近发生的数据库事故 2020年XX公司因删库事件赔付1.5亿元 2017年数据库勒索黑客劫持2.6万余台服务 2015年XX宕机多个小时，导致股价下跌 。。。。 ``` >创业公司或者小中型公司中没有专职的DBA，一般由技术leader或者运维人员来维护，中大型公司都会有一些专攻数据库方面的牛人，专门的职位叫做DBA，对于公司的DBA他们的价值不可小觑，公司只要稍具规模，就必须做好数据库的建设和维护工作，这也体现了DBA的重要性,也意味着DBA责任重大。 >一个公司的数据库如果从来不出问题，那一定是因为流量小，或者没有业务量，出问题也是学习的最好机会，如何在出现问题时候用最快的速度修复，这些都至关重要。 ### **1、关于数据库最常见的问题** **1.1、数据库选型** >对于大部分技术人员来说，公司使用哪一个数据库，基本上无须你来决定，在加入一个公司的时候，大部分的技术选型早已经确定，除非是刚创业公司你是公司的技术负责人或者总监，可能会确定技术选型。尤其是数据库，一旦选型再迁移的成本（学习、试错）非常大。因此除非是技术有颠覆性的有事或者目前有难以攻克的技术问题，否则很少有公司会费时费力的做大的迁移。 >其实无论是技术选型还是技术转型，有一个不能忽视的因素就是，技术人员能否驾驭这种技术，或者说是技术人员和技术领导熟悉这种技术。 >因为每个公司的业务不同，数据库系统的应用场景也不一样，每个公司针对不同的业务场景可能会使用多种数据库，所以选型也不相同，但是可以肯定的是，没有那个系统一定是最好的。 ``` 例如： 支付相关的业务需要强事务，强一致性支持的：开源的Mysql、PostgreSQL、新的分布式TiDB ,付费的oracle等 日志分析业务搜索相关的：Elasticsearch 缓存、秒杀相关：Redis、Cuchbase、Memcached 大数据分析：Hive、Cassandra、clickhouse 文档型数据库：Mongodb 图数据库：TigerGraph、Neo4j、Amazon Neptune、JanusGraph ``` >这也就是为什么很多公司选择多个数据库并存，并通过不同的技术和架构给予相关的业务场景最优的支持了，一旦选型失误，就会有频繁的问题出现，直接影响到用户体验。 >所有的技术选型和设计，都有它的应用场景，这也就是为什么很多公司选择多个数据库并存，并通过不同的技术和架构给予相关的业务场景最优的支持了，一旦选型失误，就会有频繁的问题出现，直接影响到用户体验。 **1.2、数据库相关架构** 一说到架构大家一般会想到： >单实例：很容易理解，单库概念. 垂直分组：单实例添加副本，如Mysql主从同步，读写分离，Mongodb的副本集、读写分离. 水平分片：比如写一本书，非常厚上万页，为了方便阅，读作者分成册（10小本）如Tidb分布式关系型数据，redis的cluster，Mongodb的分片等. >架构还包括数据库上层的缓存系统设计、程序语言对数据库连接的处理、代理层功能，以及和二级制日志相关的数据管道的搭建，其中包括数据系统的分区、备份等设计。 >像以前，很多公司把所有的数据都放在一个数据库里面，（我们最早也是这样，全部放在oracle数据库，oracle数据达到8TB，数据库最大连接数3000），随着业务不断增长，开始出现各种各样的问题，因为各种连接池和吞吐量的限制，基本没有办法进行扩展。开始设计数据标的拆分，将相关的数据放在一起，不那么相关联的放在另一个库，甚至放在了文档型数据库Mongodb中，逐渐缓解了可扩展性的问题。 >**随着微服务的流行，数据库也要进行拆分，无业务关联的可以拆成不同的尽可能小的数据库，程序可以通过dubbo接口去调用，相互独立，相互不影响** **1.3、数据库瓶颈** >配置过Nginx服务的小伙伴们都知道，当前端web服务流量增大时，只需要增加nginx的实例修改配置即可，但是数据库出现瓶颈时可不一定直接添加实例就能解决的。 >只要是数据库，就有吞吐量的限制，数据库访问瓶颈便是自然流量增长或者流量突增造成的，只要业务增长，总有一天数据库访问会达到一个上线。在这个问题到来之前，你需要进行各种垂直拆分或者水平扩展来提升整个上限（要做的工作很多的），或者你可以通过缓存如（CDN、nginx、redis）或者其他机制进行分流。 >例如流量突然暴增：可能是攻击，也可能是进行了推广活动，比如限时抢购、秒杀这样的 攻击我们需要提前做一些压测或者访问方面的缓存能降低数据库的压力。 推广活动我们需要和业务产品运营沟通提前预案。 索引：不要过度依赖索引，无效的索引可能会更糟糕 事务：关联事务、分布式事务，尽量拆成小的事务执行 **1.4、遇到的人为错误** 再好的系统，操作方式不对也是枉然，更何况并不是所有额工程师都是数据库专家，所有人为的错误是最常出现的问题。 #### 1.4.1、人为错误可以分为两种： >操作数据库时候犯的错 执行程序或者脚本犯的错 #### 操作数据库时犯错的概率比较低，但是影响却很大，几乎所有公司都会有类似的传奇事件，可以归纳这几类； #### 1.4.1.1、 有意无意的删除数据库核心数据: >文章开始的例子也写了，故意删除公司数据，对公司会造成不可估量经济损失，而且也会断送自己的工程师职业生涯，也会面临牢狱之灾。 >操作数据库时候失误操作，要尽快恢复数据，尽可能挽回损失。很久之前，凌晨12点多操作数据库（IT行业加班很普遍），进行删除测试数据库时候，不了心连上了线上数据库，进行了删除操作，执行完成就收到报警信息，瞬间头脑清晰。庆幸的是恢复的及时，损失不太大，之后操作都改为早上5点执行，有异常能及时发现，（晚上操作完了有可能就去睡觉 了）。 1.4.1.2、 修改表结构误操作： >工程师上线新版本，代码中添加修改表结构操作，导致数据库被锁长达几个小时，该业务线业务几个小时出现服务异常。 工程师修改表结构不加where条件等操作，导致该表中数据被覆盖掉。 1.4.1.3、索引问题误操作： >在java的某个底层框架中，在初始化时候，默认有添加索引的操作，再一次预发布，上线测试中，导致线上数据库直接被锁数小时（环境隔离的重要性）。 某一个程序或者脚本中查询没有索引的数据，导致全表扫描，加上一些接口相互调用访问，经常会出现数据库的所有连接被占用的情况，导致查询没有办法执行。 1.4.1.4、物理误操作： >机房断电、断网，记得第一份工作时候，在公司机房上架、下架服务器，拔错电源插头，导致测试环境服务不可用（办公室机房放测试开发环境，正式环境在运营商机房托管），虽然没有影响线上业务，但是这件事时刻铭记在心。 #### 1.5、数据安全 >数据安全包括三个方面也就是：CIA(Confidentiality, Integrity, Availability) （1）保密性：不允许未经授权的用户存取信息； （2）完整性：只允许被授权的用户修改数据； （3）可用性：已授权的用户可以对数据进行存取。 >物理安全：确保存储物理设备安全，别被雷击、盗窃了 防火墙：对数据库访问进行限制，例如允许那个路由访问数据库的端口 运维安全：对运维行为进行流程化管理，提供事前审批、事中控制、事后审计、定期报表等功能，将审批、控制和追责有效结合，避免内部运维人员的恶意操作和误操作行为 数据库审计：实时记录网络上的数据库活动，对数据库操作进行细粒度审计 数据加密：从技术角度对数据进行加密，通过数据加密能够有效防止明文存储引起的数据内部泄密、高权限用户的数据窃取，从根源上防止敏感数据泄漏 漏洞扫描：通过数据库和代码进行漏洞扫描能够有效的评估数据库系统的安全漏洞和威胁并提供修复建议 数据备份：在数据库出现异常情况，可以及时恢复，误删除，机房断电导致数据损坏 ### **2、新手入行应该先学习哪个数据库?** >推荐以开源MySQL为开始(80~90互联网企业都在用，薪资相较OracleDBA要高一些(资本 集中)，上手相对容易)，mysql熟悉以后，任何的关系型数据库系统都是相通的，掌握了MySQL，其他的关系型数据库都不在话下 ，非关系型数据库相对关系型都比较简单，而且部分理念也相通。 **持续学习：** >其实不止是DBA，整个运维体系都在做转变，传统的玩法效率低、重复工作多，已经不适用互联网公司高速度、快节奏的发展了，所以说DBA工作内容需要转变，思想也需要转变，应该向着如何快速交付、提高数据库整体稳定性、高效率运维 、打造适合更多适合业务需要的数据库产品方案，甚至给研发输出数据架构方案等这些方面发展。 **数据库前沿技术：** >例如DB自动化管理平台 主机管理：主机增删改、主机资源（cpu、disk、men） 实例管理：实例增删改、实例主从切换 审计管理：sql审核、sql回滚 日志管理：binlog、慢查询 任务管理：定时任务 日常维护：批量sql执行、配置修改、自动扩容 **目前北京DBA就业形势：** >招聘待遇，月薪2w-3w的占比居多，达到50%-60%，经验要求3-5年的居多。 **持续学习 只为认识更大的世界** 1.2.2