1. 故障类问题

故障01:mysql时软件版本选择错误

每一个故事的背后都有一个事故,每个故障总结一个故事

软件版本  64位 32位选择错误

故障02: 安装故障

1.用户没创建 权限没给

2.初始化 mysqld mysql_install_db

本地的mariadb没卸载, /etc/my.cnf没有删掉 ,初始化时会导致失败

3.配置文件实际情况不对应(basedir , datadir)

此处该加上一个励志的故事,融入个人情感,刚开始学mysql的不容易与坚持

4.重启,数据盘没有挂载
/dev/sdb ----> /data 没有自动挂载 导致mysql启动不了
排查思路: 日志文件中的错误信息,当时对日志不是特别熟

5.mysql升级失败 5.5 --->8.0
当时不清楚mysql的这些原因,没有注意,领导让测试8.0的环境
我就下载了一个8.0.11版本,我安装到了测试服务器,原生产核心功能表的一部分数据通过MDP工具导出来了,恢复到测试中,然后应用测试的时候直接导致无法连接,通过查看官方文档8.0的那个<what is new?>,才明白了不能大版本升级

排错思路:

主要原因就是版本的特性原因,8.0不升级数据字典,,,8.0的密码和用户管理发生了巨大变化 先升级到5.7 再升级8.0,sql_mode,数据类型差别

这个问题当时卡了一个小时,第二周就要上线了,因为也没人协助我,从网上一直搜查资料一直熬到快三点了才解决,想想这几年刚大学毕业,一直觉得差其他人好多的,所以自己就特别要强,不会的东西就一直搞搞搞,现在想想,觉得自己做的无怨无悔,这个行业带给我很多好的结果,我就认为我自己肯定行,自从经历了那么多的熬夜查文档,解决问题的那个时刻真的让我就特别的开心,现在出现故障慢慢的就不怵了

故障03:数据库连接不上

1.网络不通,防火墙

1.网络不通:
    网线坏了(老鼠咬断了  机柜压断了  被人拔了 哈哈...)
    网卡  bond 交换机  路由器  回路 网络流量满负荷
    解决思路:  监控

2.防火墙:敲错防火墙规则,上来写错了一条规则,导致内网服务器访问不了了
        不过幸亏是在测试环境做的,有个好习惯就是任何调优配置都先在测试环境中配置

3.没启动 端口 IP

4.应用端客户端工具版本过低
https://downloads.mysql.com/archives/

5.连接数(499)
    redis雪崩 穿透
    日志
    show processlist;

故障问题04: 配置文件问题

故障问题05: 多实例

故障问题06: sql_mode(groupby,时间类型) 迁移升级

故障问题07: 数据类型

故障问题08: 字符集:乱码

故障问题09: 校对规则问题

故障问题10: update问题 binlog2sql

故障问题11: DDL, 数据库夯住了

show processlist;
pt-osc

故障问题12: select查询语句慢

头一天好好的,第二天就慢了
optimize table t1;

故障问题13: 慢语句处理,同一个存储过程一天内执行了几十次

slowlog 抓到是一个存储过程,执行几十次

故障问题14: delete

binlog2sql 翻转 delete 替换为update

故障问题15: 索引问题:

荣誉索引过多,索引列比较长(前缀),联合索引(索引覆盖长度,顺序)
slowlog ----> explai ---->索引

故障问题16: 存储引擎

1. 表空间迁移
2. 每周六全备,其他时候binlog增量.
    异常断电,binlog损坏,ibdata1损坏
3. 碎片整理
    alter table t1 engine innodb;
4. 锁等待
5. 幻读,不可重复读

故障问题17:日志故障

1.reset master rm -rf 导致主从IO线程故障
   数据库如果出现损坏 无法完整恢复

2. gtid : --skip-gtids 导致数据无法恢复

3. slowlog

故障问题18: 备份恢复

1. mysqldump 加了 --set-gtid-purged=off,主从构建不成功
2. --max_allowed_packet,大表备份时报错
3. -E -R --triggers没加
4. 增量合并失败.

故障问题19: 主从

1.主从故障: IO SQL show slave  status \G
2.主从延时: 延时时间 日志量差异
3.主从不一致: 从库宕机 pt工具
4.延时从库 解决逻辑故障
5.过滤复制 只复制了部分库 没有复制mysql,查询时连接不上或没有权限
6.gtid复制搭建

故障问题20: 高可用MHA

只有vip功能 缺了binlogserver 故障提醒功能
MHA+keepalive 权重问题

故障问题21: 分布式Mycat

1.分片方式,分片策略设计不合理
2.跨分片join 全局表 ER表

故障问题:22: 优化

1. innodb_flush_log_at_trx_commit=0
2. sync_binlog=0
3. innodb_flush_method=fsync  占用大量的额外内存,
   配合固态硬盘使用 O_direct

2. 架构类

1. 一主1从+读写分离proxysql maxscale (50G)
8核32G
阈值:
并发连接 800-1000
并发查询 5W QPS
并发事物 300 TPS
2.一主3从+读写分离+延时从 (100-200G)
8核32G
阈值:
并发连接 800-1000
并发查询 8W QPS
并发事物 200 TPS
3.一主多从+级联复制+过滤复制 (300-500G)
8核32G
阈值:
并发连接 800-1000
并发查询 15-20W QPS
并发事物 200 TPS
4.MHA+ProxySQL 1主3从
1主2从做MHA+proxySQL 1从做容灾
16核64G*3 + 8核16G

阈值:
并发连接 1500-2000
并发查询 12W QPS
并发事物 400 TPS

此架构适合电商平台,物流
2T数据
5. PXC + proxySQL(MGC+maxscale)
16核64G*3 + 8核16G
阈值:
并发连接 1500-2000
并发查询 12W QPS
并发事物 400 TPS

此架构适合电商平台,物流
2T数据
6.Mycat + MHA(PXC)*3 高可用分布式集群
16核128G*7
阈值:
并发连接 3000-5000
并发查询 20W QPS
并发事物 800-1000 TPS

教育行业(大数据平台)
9T数据
7.redis sentinel+Docker
redis Cluster + k8s
8. MongDB replication
保险类公司
16核 256内存 + 40T*4台
20T左右数据 +保单
9. MongDB Sharding + HASH
数据在PB级别: 共享单车 百度地图 京东 360
16核128G*9台*40T

3. 优化类

锁等待
索引+slow
innoDB换成TokuDB(MyROCKS)

4. 升级迁移

1. zabbix
2. MongDB Sharding + HASH
数据在PB级别: 共享单车 百度地图 京东 360
3年-5年的某银行流水 30T
16核128G*9台*40T
02-01 05:03