跳到正文
首页
MySQL
运维避坑
MySQL运维避坑案例整理
MySQL运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 34
个案例 。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 41 期｜MySQL swap
90%+并逐渐耗尽问题分析
专辑文件：01.html，第 1 个案例
查看原文 现象： MySQL所在龙蜥8.6服务器swap
90%+并逐渐耗尽，物理内存使用不到40%，/etc/sysctl.conf中配置的vm.swappiness=1，即尽可能的使用内存，实际却是尽可能使用swap，vm.swappiness=1并未生效。；测试在龙蜥8.6
、centos 8.5中都会出现此（4.x内核），在centos
7.9中不会出现此。；/sys/fs/cgroup/memory/system.slice/mysqld.service/memory.swappiness处置过程： cat /proc/$(pidof mysqld)/cgroup -->
"2:memory:/system.slice/mysqld.service" mysqld进程已经被放进
system.slice/mysqld.service 这个 cgroup;；cat
/sys/fs/cgroup/memory/system.slice/mysqld.service/memory.swappiness
--> 60 该值并不为1;运维建议： 永久固化 MySQL 服务 cgroup 的 swappiness
配置，将其固定为 1，保证数据库优先使用物理内存，严控 Swap
使用；完善同类操作系统参数配置标准，针对 4.x 内核系统，新增 cgroup
内存参数检查项，统一数据库服务配置规范；增加服务器 Swap
使用率监控告警，及时发现异常置换行为，提前干预处置
第 39 期｜MySQL
备份恢复后启动数据库报错问题分析
专辑文件：03.html，第 4 个案例
查看原文 现象： 备份恢复后启动数据库报错。处置过程： 问题一：无法打开undo
tablespace；备份恢复完成无报错，启动数据库失败，报错提示；unable to open
undo tablespace运维建议： 备份恢复前，必须将源库 my.cnf
完整同步到目标库，仅修改路径，不改动业务参数；innodb_undo_tablespaces、innodb_redo_log_capacity、plugin_load；等关键配置
第 38
期｜MySQL迁移达梦微服务无法正常启动问题分析
专辑文件：04.html，第 8 个案例
查看原文 现象： 使用flyway迁移，微服务无法正常启动。处置过程：
使用flyway迁移微服务；发现服务一直启动不了，通过查看日志发现关键报错；“Schema
""snc_data_platform"" contains a failed migration to version
1.41.0.202503271100 ”运维建议： 微服务启动失败优先排查 Flyway
迁移状态；快速删除失败记录恢复服务。；MySQL 迁移达梦必须做 SQL
脚本适配
第 38
期｜MySQL迁移达梦 平台功能无法正常使用问题分析
专辑文件：04.html，第 9 个案例
查看原文 现象：
对cmdb服务数据库从mysql迁移到达梦后，平台功能无法正常使用。处置过程：
迁移达梦后服务正常启动无异常报错；主要异常情况有以下几点；平台再接入主机的时候，观测洞察中不能同步监控指标情况，监控模板中可以正常获取到样本数据，查看服务也没看见报错信息，流批也正常运行中；运维建议：
clobAsString=1（或clobAsString=true）是达梦数据库JDBC连接URL中的一个关键参数，主要作用是将数据库中的CLOB（含TEXT）大文本字段直接映射为Java字符串类型，以简化开发中的数据处理；达梦JDBC驱动默认将CLOB字段映射为dm.jdbc.driver.DmdbClob对象，而非直接的Java字符串；这意味着当你查询CLOB字段时，ResultSet.getObject()返回的是一个CLOB对象的地址（如dm.jdbc.driver.DmdbNClob@3b*****），而不是实际的文本内容。尝试直接使用该对象进行序列化、JSON转换或字符串拼接时，极易出现类型转换异常。
第 34
期｜MySQL重建主备问题分析
专辑文件：08.html，第 6 个案例
查看原文 现象：
客户MySQL架构为级联主备，主-->备-->备库的备，由于备库的备只是作为应急恢复使用，不影响业务正常使用，所以没有配备告警，导致同步延迟不断积累已经差异1月左右，无法自动恢复，需要重建主备。处置过程：
由于客户担心主备断连，会有风险，所以经最后验证确认，；决定使用XtraBackup热备进行恢复。；在BCLinux系统安装xbk，需要把libgcrypt.so.11、libgcrypt.so.11.8.2上传到/usr/lib64下
否则无法使用。运维建议：
生产环境必须实施全面的监控覆盖，以主动发现并规避潜在风险；备份策略应严格依据系统架构进行定制，确保其有效性及可恢复性
第 34
期｜MySQL赋权使用通配符时可能出现权限覆盖问题
专辑文件：08.html，第 7 个案例
查看原文 现象：
MySQL赋权使用通配符时可能出现权限覆盖的问题。处置过程： mysql> show grants
;；+-----------------------------------------------+；| Grants运维建议： 尽量不要使用对数据库的通配赋权
第 33
期｜mysql复制延迟及数据一致性问题
专辑文件：09.html，第 7 个案例
查看原文 现象： 关于MySQL复制延迟及数据一致性问题。处置过程：
MySQL主从复制效率低下，一直被诟病，复制延迟可能影响故障切换的响应时间；；由于配置及管理因素也常常引发主从数据不一致；复制延迟及一致性问题可能导致严重的业务风险。运维建议：
确保binlog格式为rowW；；谨慎设置slave-skip-errors,修复主从错误时谨值跳过错误或事务；；设置备库只读，避免误操作从库；
第 33 期｜MySQL备份异常
专辑文件：09.html，第 8 个案例
查看原文 现象：
因业务需要重新搭建备库，MySQL数据库主库全量备份报错。；LSN不匹配导致MySQL备份异常。排查与原因：
这套库是从别的库复制过来的，业务复制的时候导致LSN与实际的LSN不一致。；备份复制的数据页比日志更新，导致无法通过日志恢复一致性。；备份期间持续写入处置过程：
检查表文件完整性（无异常）；；调整重做日志配置（未解决）；；重做备份-使用mysqldump进行逻辑备份全库，再导入备库搭建主从同步。运维建议：
该从库原先是业务侧搭建的；；实施方案需经过评审。
第 33
期｜mysql数据库磁盘使用率异常
专辑文件：09.html，第 9 个案例
查看原文 现象：
mysql数据库磁盘使用率异常上升（一天上涨大概300G）。处置过程：
排查发现数据库五分钟binlog日志平时十几M现在激增至2G左右，查看当前数据库是否有长事务会话和执行频率高的更新删除语句，查看发现有几十万条更新语句一直在执行。；因为业务使用canal来监听数据库binlog日志，一直未释放磁盘，在数据库找到异常的binlog连接，kill会话，因为canal有重连机制，还会读取断开时间点的日志，在canal上找到kill是异常的日志，确定是哪个任务。；删除对应的canal任务，重建后数据库磁盘释放。运维建议：
第三方系统一直推送异常数据，kafka消费异常，代码上存在循环更新错误逻辑，五分钟就会更新200万条数据。
第 33
期｜mysql数据库服务不可用
专辑文件：09.html，第 10 个案例
查看原文 现象：
业务高峰期时，认证系统的采购服务用户反馈服务不可用，同时监控也发出多个应用服务拨测超时的告警。应用组对purchase-service服务做内存快照及线程快照，线程无阻塞，进入等待线程发现疑似有线程死锁情况，其他方面内存、磁盘、负载、cpu、网络均无异常。数据库查看只有几条执行了4分钟左右的SQL，开发反馈与该SQL无关。；应用同事将连接池连接数配置从8修改为200，并重启purchase-service服务，告警恢复，但一段时间后告警重新出现。此时查看数据库，发现有60多个线程在运行该SQL，执行时间超过10分钟。处置过程：
该SQL（多表联查）执行计划虽然均走索引，但是其中一张表使用的索引效率很低，开发反馈该业务近期没有改动，过去该SQL执行正常也很快。；在上周五夜间，业务组有上线操作，对该SQL中的一张表写入了80多万行数据，数据发生较大变化，导致相关业务SQL执行计划改变，周一业务高峰期查询性能下降。；删除该低效索引；运维建议：
当该参数condition_fanout_filter值为ON时；优化器在估算多表连接的行数时，会结合存储引擎层过滤（基于索引的
rows 值）和 Server 层过滤（基于 WHERE 条件的 filtered
值），最终行数估算公式为：rows × filtered / 100；；当设置为 OFF时
第 31 期｜mysql无法正常备份
专辑文件：11.html，第 4 个案例
查看原文 现象：
mysql-xtrabackup备份时发生堵塞，无法正常备份。处置过程：
检查备份日志；备份日志中出现长事务导致备份无法完成.分析长事务的sql，优化完sql后，备份正常。；xtrabackup备份时添加了ftwrl-wait-timeout参数，但是没有添加kill-long-queries-timeout参数。运维建议：
使用xtrabackup备份时，如果开启ftwrl-wait-timeout参数,可同步添加kill-long-queries-timeout参数和kill-long-query-type=select参数，避免备份时出现堵塞。
第 31 期｜mysql定时任务不跑
专辑文件：11.html，第 5 个案例
查看原文 现象：
Mysql数据库开了定时任务，但是任务不跑，需要排查原因。处置过程： Show variables like
‘%event%’,event_scheduler参数开启；手动创建event；发现event确实不跑。运维建议：
需要对mysql-error日志进行监控分析，如果出现error级别的错误通过短信告警的方式通知出来，避免出现定时任务不跑导致数据丢失的情况。
第 27
期｜MYSQL数据库排序规则报错 ERROR 1267
专辑文件：15.html，第 6 个案例
查看原文 现象： MySQL8.0.21调用视图，排序规则报错；ERROR
1267；(HY000): Illegal mix处置过程：
查看视图定义；发现涉及到的俩张表的字符集排序规则不同，创建视图时 MySQL
会自动使用 convert 函数转换字符集，；mysql8.0 utf8mb4运维建议：
创建数据库实例时需指定参数；character_set_database（默认值：utf8mb4）；；character_set_server（默认值：utf8mb4）
第 27
期｜mysql主库的服务器由于硬件问题导致服务器宕机重启
专辑文件：15.html，第 7 个案例
查看原文 现象：
MYSQL数据库；ysql主库的服务器由于硬件问题导致服务器宕机重启，主从切换后，复制报错；Could
not处置过程：
查看高可用组件日志，主从切换的GTID一致，并未丢数；在从库执行show slave
status\G；发现从库比主库多了一个GTID，用mysqlbinlog解析这个gtid，发现这个事务涉及的表和报错表是同一张。运维建议：
本次故障的一个重要教训是，在生产环境中应尽量避免使用非事务表；（如MEMORY表）；内存表虽然具有访问速度快、不占用磁盘空间等优点，但其数据在数据库重启时会丢失，这可能导致复制中断、数据不一致等严重问题。因此，在生产环境中应优先考虑使用事务表
第 26 期｜MYSQL数据库
专辑文件：16.html，第 8 个案例
查看原文 现象： 并发查询索引失效,导致cpu打满。处置过程：
通过processlist抓取当前慢查询，定位到慢sql语句。；查看执行计划、表结构、表中索引和数据分布情况来分析这条SQL，is_hide
is null or t.is_hide =
'0'约为全表数据，biz_name上有一个区分度较差的索引，但是ignore
index限制了该索引的使用，location 为varchar类型，location in
(1000,2000,6600,)写法会导致索引失效，且in后面接了超过200个值，即便是值加上单引号书写正确，在MySQL里面也不会走上索引(参数限制eq_range_index_dive_limit，超过限制不会用该索引预估cost，因为dive开销太大)。；所以突破的关键在运维建议：
清晰了解何种条件下满足索引合并；当查询条件涉及多个字段，且这些字段上都有索引时，可以考虑使用索引合并来优化查询性能。；在优化SQL时，要充分考虑表结构、索引和数据分布情况
第 26 期｜MYSQL数据库
专辑文件：16.html，第 9 个案例
查看原文 现象： MySQL主从出现大量延迟。处置过程：
电渠数据告警延迟，登录数据库中排查发现备库一直卡死到某个gitd中，导致备库执行时间很长，通过解析binlog日志发现为一条delete全表删除语句，该表数据6千万左右，通过和客户业务沟通后，备库跳过该gtid事物，快速恢复备库复制状态。；处理具体步骤；登陆MySQL备库，检查备库延迟状态，获取到执行到主库的binlog运维建议：
对SQL语句进行严格的评估和测试；从这次故障中，我们深刻认识到DELETE全表数据操作的危害性。在数据量较大的情况下，DELETE全表操作会导致长时间的锁表，进而影响数据库的性能和可用性。；因此，我们在上线前对SQL语句进行严格的评估和测试，禁止使用DELETE全表数据操作。对于需要清空表数据的情况，可以考虑使用DROP
TABLE后重新CREATE TABLE的方式，或者使用TRUNCATE TABLE语句。
第 22
期｜MySQL双主单写集群的从节点报错主从复制中断
专辑文件：20.html，第 1 个案例
查看原文 现象：
MySQL双主单写集群的从节点，按如下顺序执行变更操作后，主节点业务正常读写，但从节点报错主从复制中断。；基于原表结构创建一个新表；create
table处置过程：
定位详细报错信息，此时错误日志记录的错误信息为；[ERROR] [MY-013146]
[Repl] Replica SQL；for channel运维建议：
DDL变更应在主节点执行；在MySQL双主单写集群中，所有DDL变更（如表结构修改、索引创建或删除等）都应在主节点上执行，以确保变更的一致性和同步性。从节点应仅用于数据复制和读取操作，以避免复制中断和数据不一致的风险。；数据一致性
第 22 期｜MySQL存在主从延迟
专辑文件：20.html，第 2 个案例
查看原文 现象：
巡检发现有一套接维的MySQL存在主从延迟的情况，核实表数据较大，检查从库发现某条delete语句执行耗时，导致从库SQL线程一直在执行此事务卡死。处置过程：
检查MySQL主从状态；存在主从延迟问题。；show full
processlist检查MySQL进程运维建议：
加强SQL审核流程；细化审核标准；在SQL语句上线之前，应建立严格的审核流程，包括但不限于对SQL语句的性能评估、安全性检查以及是否符合数据库设计规范。审核时应特别关注SQL语句是否可能引发性能问题，如全表扫描、大量数据操作等。
第 21
期｜MySQL测试环境修改root密码报错
专辑文件：21.html，第 3 个案例
查看原文 现象：
Mysql测试环境-root忘记密码，设置skip-grant-tables修改root密码报错。；error
1396:opeartion；alter user failed for处置过程： 查看mysql版本：mysql
8.0.31。；查询一下安全模式开关；show variables like运维建议：
深入了解数据库版本特性；不同的数据库版本在功能和安全性方面可能存在显著差异。在处理特定问题时，首先需要确认数据库的具体版本，以便了解该版本特有的行为、限制和最佳实践。；在本次事件中，我们注意到MySQL
8.0.31版本对sql_safe_updates的设置更为严格，这直接影响了我们尝试通过UPDATE语句直接修改authentication_string字段的能力。
第 21
期｜mysql从库故障，报错重复的分区名
专辑文件：21.html，第 4 个案例
查看原文 现象： mysql从库故障，报错重复的分区名。处置过程：
查看报错，从库在执行ddl的时候出现了问题，报错原因分区重复。；检查主库和从库的表结构信息，表结构，分区一样。；检查从库是否有添加分区的任务，show
events查看发现有一个job在启用。运维建议：
理解错误本质；分区重复错误；当MySQL在从库执行DDL操作时遇到分区重复的错误，通常意味着尝试创建的分区名称已经存在。这种错误可能是由于同步过程中的数据不一致或配置错误导致的。
第 21
期｜mysql备库日志应用延迟问题分析
专辑文件：21.html，第 5 个案例
查看原文 现象： mysql备库日志应用延迟，sql_thread提示等待
Waiting for Replica Worker queue，延迟161143+秒。处置过程： show
processlist查看等待的执行语句，delete from t where
date>'2021-01-01';分析表上无主键、无索引，数据量400w+，删除行数200w+。；典型的无主键大数量操作导致延迟的问题。row模式的同步在备库这种情况，其实是要进行200w+次全表扫描，即使使用了batched
delete，也是很庞大的操作量。；处理方案可选的有运维建议：
强化数据表创建标准；主键的重要性；在数据库设计中，主键是不可或缺的一部分。它不仅帮助唯一标识表中的每一行，还能极大地提升查询、更新和删除操作的效率。
第 13
期｜mysql5.7升级版本后版本回退导致数据文件损坏
专辑文件：29.html，第 10 个案例
查看原文 现象：
mysql5.7升级mysql8版本回退出现引发数据文件损坏，数据库启动失败。处置过程：
通过分析数据库日志，当回退mysql版本到5.7时，以mysqld_safe安全方式启动mysqld进程，拉起服务时读取ibdata共享表空间文件失败，无法加载表元数据到服务层；初步判断ibdata数据文件损坏。；由于备份共享存储空间不足，导致最近的备份失败，所以无法采用全备方式来恢复数据运维建议：
在进行任何升级或回退操作之前，详细评估版本兼容性和官方文档，确保所有步骤符合最佳实践和兼容性指南；强化数据备份机制，确保备份任务的成功执行，并定期验证备份数据的完整性和可恢复性；扩展或优化备份存储空间，避免由于存储空间不足导致的备份失败
第 12
期｜MYSQL主从从复制从库中断处置
专辑文件：30.html，第 5 个案例
查看原文 现象：
业务mysql以主从从的方式进行搭建，其中主从io进程断开，导致主从从失败。处置过程：
因国产化系统替换，数据库迁移到国产BC系统，执行数据交换任务，以全量数据写入的方式写入当天最新的数据，对应写入的表数据量较大，缓冲区过小，心跳机制检查失误产生报错。根据告警时间，定位到具体的数据交换任务。；调整任务时间，使其错开执行，未再出现
IO 复制异常的问题。运维建议：
尽量避免一次性提交大量更改：将大型事务拆分为较小的子事务，并在每个子事务之间定期提交，以减轻IO压力。
第
10 期｜mysql从库延迟持续增长，从库长时间卡在insert into as
select事务上
专辑文件：32.html，第 5 个案例
查看原文 现象： mysql从库延迟持续增长，从库长时间卡在insert
into as
select事务上。；由于业务主库数据不受影响，卡住的事务只能等待执行完成后追加延迟事务，通过该像业务发起性能优化；业务文本字段使用专门的文本存储，数据库放文本存储的地址。处置过程：
查看卡住事务走索引，不存在sql性能问题；；检查insert数据大小差不多3万多条，数据量也不大；；检查表结构发现表有2个大文本字段，通过统计发现数据大小差不多2G；运维建议：
文本字段使用专门的文本存储，数据库放文本存储的地址。
第 10 期｜mysql误删数据恢复
专辑文件：32.html，第 6 个案例
查看原文 现象： 业务反馈一张表执行delete操作没加where
条件，需要进行数据恢复。处置过程：
定位业务操作删除时间点范围，查询当前binlog日志类型是否为row；；通过业务方提供时间点，解析对应binlog日志，找到binlog日志中删除表的gtid、位点信息，记录下位点；；通过binlog2sql解析原数据binlog特定位点之间进行内容，生成反向业务sql语句；运维建议：
定期对于数据的全备、binlog备份做检查，通过自动化平台每天早上巡检，巡检结果邮件通知，保障数据库的可用性和可靠性。；对于恢复的业务数据验证，需要在测试环境进行校验，不要直接导入至生成环境中，以防导入数据有问题和重新再导入，影响现有生产环境性能。；执行相应删除操作，需特别注意，最好双人复核，减少人为操作引起的故障。
第 10
期｜mysql执行一条join语句很慢
专辑文件：32.html，第 7 个案例
查看原文 现象：
业务反馈一条关联join语句执行很慢，查询时间超过半小时左右。处置过程：
找到业务提供相应的sql语句或通过查询相应慢日志；；查询对应的关联表结构和相应表的数据量大小；；通过初步分析，join关联语句后面条件判定确实满足驱动表为小表，被驱动表所查询的列为索引；运维建议：
业务低峰期修改表字符集，保证join关联语句生效；；业务修改后，目前该语句得到了优化，查询时间从未优化前半小时左右，提升到几分钟内。；注意隐藏的转换，如字符串类型等于整型、被驱动表查询的列未使用到索引、索引查询数量大于30%等；
第 7
期｜mysql二进制日志未自动清理处置
专辑文件：35.html，第 8 个案例
查看原文 现象：
mysql8.0.23，二进制日志未自动清理，设置了binlog_expire_logs_seconds的值，由于日志未自动清理，导致挂载点使用率过高报警。处置过程：
经过查询mysql8.0存在以下两个参数；expire_log_days和binlog_expire_logs_seconds两个参数，binlog_expire_logs_seconds的优先级高于expire_log_days。binlog_expire_logs_seconds的值设置为604800（单位秒，即7天），expire_log_days的值为0（表示日志不自动清理）。；经过检查发现，在修改过参数之后未执行flush
logs使参数生效。运维建议： 完善变更步骤，在变更步骤中确保flush
logs被执行。
第 6 期｜Mysql
性能全面下降，业务访问超时无响应
专辑文件：36.html，第 7 个案例
查看原文 现象： mysql
sql性能全面下降，业务访问超时无响应。处置过程：
优先检查主机内存、cpu、io；发现故障时间io写入降为零。；检查sql，发现业务那个时段业务在跑批量更新数据。；观察实时io发现，数据频繁的读写一块盘，且该块盘的最大iO才3M-5M之间；后通过主机检查发现该业务进行了多次少量扩容，底层挂了12块盘，从最开始的50G扩容到400G，最大的一块盘150G。运维建议：
多次扩容的虚拟机需要进行单盘io评估。
第 4 期｜MYSQL单表损坏恢复
专辑文件：38.html，第 3 个案例
查看原文 现象： mysql单表损坏，导致业务受阻。排查与原因：
判断为os层文件损坏,通过mos进一步确认为文件损坏；；通过设置innodb_force_recovery尝试恢复,从value
1--6仍然无法恢复,和业务沟通先drop故障表,恢复其他业务；；使用备份+binlog异机恢复故障表,业务确认数据后导出并导入生产库。处置过程：
mysql不断crash重启,日志提示访问表的page错误；Trying to access page
number 1212435777；space 27, space运维建议：
一定要做备份；；必须做定期恢复演练。
第 4
期｜MYSQL主从同步延迟处置
专辑文件：38.html，第 4 个案例
查看原文 现象： Mysql主从同步延迟。处置过程：
监控短信告知mysql主从复制的延迟时间。；登录数据库查看从库的SLAVE日志(SHOW
SLAVE STATUS),发现当前延迟（Seconds_Behind_Master:3500）较大。；SHOW
PROCESSLIST未发现事务锁，且当前活跃连接数大概10几个（4核的CPU），某几条delete、update执行时间过长。运维建议：
调整数据库服务器的磁盘IO监控告警阈值。；配置合适的延迟监控项告警阈值。；对参数进行调整innodb_flush_log_at_trx_commit=2
sync_binlog=0
第 3
期｜MYSQL从库的延迟告警处置
专辑文件：39.html，第 3 个案例
查看原文 现象： mysql从库的延迟告警，并且延迟越来越大。处置过程：
查看延迟的从库，并没有发现有大事务正在执行，这里排除大事务导致的复制延迟；；没有发现metadata
lock排除对表DDL导致的复制延迟；；查看线程具体等待情况，有等待提交的
、有等待MTS顺序提交，等待提交锁要主要是由一条flush table with read
lock导致的；运维建议： 避免在从库执行 flush table with read
lock语句。；slave_preserve_commit_order=0 关闭从库 binlog
的顺序提交，避免这个死锁的出现。；从库监控flush table with read
lock语句。
第 3
期｜MYSQL主从同步异常处置
专辑文件：39.html，第 4 个案例
查看原文 现象： Mysql主从同步异常。处置过程：
主从同步异常，从库执行inster语句失败，使用mysqlbinlog命令查询报错时间点的sql语句，根据此sql删除从库重复数据。；查看从库bin-log日志发现故障前从库有做inster操作。；查看从库read_only配置，发现从库未开启read_only。运维建议：
应用用户不允许有super权限，加强权限管控。；增加从库read_only参数检查。
第 2
期｜mysql频繁崩溃重启，导致业务中断
专辑文件：40.html，第 3 个案例
查看原文 现象： mysql频繁崩溃重启，导致业务中断。处置过程： 排查mysql日志，出现了got 11
error的错误，这是由于bug or
机器硬件导致的。；检查操作系统日志，并未发现硬件的错误。；检查mysql日志，发现mysql使用了8.0.29的版本，此版本由于出现重大bug，开源社区已回收此版本，需升级到8.0.30.在升级过程中，由于mysql频繁重启，导致实例崩溃恢复无法完成，故升级无法进行。需将原备份导入到新实例中，问题解决。运维建议：
及时关注官网信息，定期对数据库进行升级；。检查所有生产环境是否存在8.0.29版本数据库，如果存在，需要及时升级到最新版本。
第 2
期｜MySQL数据库被业务误删除
专辑文件：40.html，第 4 个案例
查看原文 现象：
MySQL数据库被业务误删除导致部分业务停止。处置过程：
从库io异常导致复制停止。；从库导出误删数据库，进行恢复至主库。；解析binlog恢复增量数据。运维建议：
对业务账号权限进行规划管控，按照权限最小化原则进行赋权，防止赋权过大。；对业务操作变更操作进行管理，防范未经评审变更。；所有数据库都要进行备份，