我们通常说的数据库高可用根本是狭义的高可用
这是学习笔记的第 2377篇文章https://p26.toutiaoimg.com/large/pgc-image/RV3hGSPGxgLFIM
在DBA的核心职责中，许多人都提到要包管数据库服务稳定高效，其中高可用建立是核心也是难点，但是从我们的实践来看，我们所说的高可用建立是相对狭义的，比如MHA，Orchestrator等，通常和业务侧明白的高可用不是一回事，因为信息源众多，大概会比较混乱，我们就可以设想4个角色来思考。
分别从业务侧，研发侧，数据分析侧，运维侧来考虑。
业务侧简单来说就是应用服务器直接连接到数据库，如果数据库连接失败，毫无疑问就是不可用，如果数据库可以连通，但是数据库服务器因为磁盘故障等写不了数据，在业务侧来看还是不可用。
MHA,Orchestrator等高可用方案是运维侧考虑的，但是还是相对狭义的，比如数据库底子运维服务异常，如监控报警服务全部失效，到了下班的时间，我想对你来说数据库就是一种裸奔的状态，这是很危险的；还有人为操作失误，因为运维角色的特殊性，通常会有较大的权限处理数据，如果有了误操作，无论怎样恢复，这本身就可以定性为数据库故障，属于数据库服务的不可用。
我们在此收拢一下思绪，画了如下的图：
https://p5.toutiaoimg.com/large/pgc-image/SjrXJNA5cAXEs1
但是显然这么多的问题，为什么现在没有发生问题，无非有三种解释，第一种是运气，这个无须过多解释，第二种就是潜伏风险，也就是确定的风险，第三种更危险，是未知的风险，通常我们关心的第二种里面的一小部分，而对于第一部分和第三部分是关心比较少的。
在此我们睁开了比较多的内容，其实这些问题是可以分级的，有些问题是最高优先级，有些则是优先级比较低的，衡量的标准可以按照业务优先级来举行评估，哪怕是一个再小的功能，一旦是因为全局核心的功能，那么就是第一优先级的。
[*]业务视角的数据库异常我总结为数据库连接失败，读取数据库异常，写入数据库异常，我会列出一些潜伏的原因和分析，供参考。
业务侧连接数据库失败
防火墙权限
主从情况防火墙不一致
数据库账号
主从情况账户及暗码不一致
数据库驱动
MySQL 8的数据库驱动版本要求较高
域名剖析
域名服务（如Consul)不可用
域名广播生效时间过长
健康查抄脚本返回异常
连接池溢出
连接数超过最大阈值
管理员账号无法登陆释放连接
中心件服务异常
中心件僵死状态
复杂SQL执行超时
集群配置无备份
多个中心件的防火墙配置不一致
中心件无法启动
中心件连接池和数据分片无法映射
高可用切换失败
VIP漂移失败
Consul域名绑定失败，均不可用
数据库服务器异常
主机硬件故障
主机操作系统故障
数据库宕机
数据库OOM
数据库bug
网络异常
IDC网络耽误异常
交换机路由异常
流量突增，到达容量上限
数据恢复异常
数据备份不可用
数据备份不完备导致无法恢复
数据恢复时长无法预估
业务侧读取数据库异常
数据表查询失败
数据表未正常创建
对象权限
指定的表，字段等无法访问
指定的存储过程，函数等无法访问
数据字典不存在
版本差异导致的数据字典不存在
技能栈差异导致的数据字典不存在
主从数据耽误
主从数据不一致导致复制异常
大事务数据处理
大表变更
VIP漂移失败
数据时间异常
ntpdate时间同步
高可用切换失败
Consul域名多重绑定，数据混写
业务侧写入数据库异常
数据表写入失败
数据表未正常创建
磁盘空间溢出
inode溢出
自增列溢出
自增列为int范例
字段值为时间，如20210922195700
数据库锁
在线大表DDL变更
事务未正确关闭
死锁
高可用切换失败
Consul域名多重绑定，数据脏读
应用服务bug
业务逻辑异常
各大平台都可以找到我
[*]微信公众号：杨建荣的学习笔记
[*]Github：@jeanron100
[*]CSDN：@jeanron100
[*]知乎：@jeanron100
[*]头条号：@杨建荣的学习笔记
[*]网易号：@杨建荣的数据库笔记
[*]大鱼号：@杨建荣的数据库笔记
[*]腾讯云+社区：@杨建荣的学习笔记
原创热文：
维护之夜，说点故事和经验
我们为什么在MySQL中几乎不使用分区表
新年大吉 总结了如下的感想
《大江大河2》最触动我的一段经典对话
MySQL 8.0给开辟方向带来的一些困扰
页:
[1]