先看一个生产案例数据库error.log出现下面报错，实例启动失败。20250215T23:05:53.25430908:004[ERROR][MY012592][InnoDB]Op

在mysql8.0中，下面参数控制过期binlog自动清理。检查日志文件，binlog超过5天的日志并未清理，数据库启动以来的所有日志都在。查看binlog截断时间，每天晚上的binlog切换时间几乎一致。下面是2025.1.8的备份完成时间，与上面binlog切换时间吻合。对比别人提交的bug，问题描述基本一致。可见，当maxbinlogsize设置较大，而每天生产的binlog日志量较小时，就无法进行自然切换。然而备份切换的时候由于加锁了，不让删除binlog，所以导致binlog日志一直没有清理。合理调小maxbinlogsize的值。

logoutput参数可以指定慢日志的存储方式，可以设置为TABLE、FILE或者NONE。logoutput'FILE'表示将日志存入文件slow.log，默认值是'FILE'log

今天分析的案例中，错误日志显示有索引损坏，然后mysql实例不定期重启。20241104T10:15:35.07669908:00116[ERROR]InnoDB:Databasepagecorruptionondiskorafailedfilereadofpage[pageid:space1921,pagenumber35458].Youmayhavetorecoverfromabackup.InnoDB:Pagemaybeanindexpagewhereindexidis2949.从日志找到这几个关键词，下文定位问题时会用到。

changereplicationfilter过滤配置无法持久化，重启实例失效；在mysql5.7版本中，changereplicationfilter过滤影响mgr集群内部同步。

应用服务连接数据库后，mysql的最大连接数自动变为214，mysql出现Toomanyconnections的错误。配置参数中，maxconnections3000，数据库启动后连接数也显示3000。开启generallog后发现错误，受限于maxopenfiles，数据库修改了maxconnections和tableopencache的值。执行ulimita查看，果不其然，openfiles显示为1024。升级openssh后，centos修改限制参数不生效了。这是因为limits.conf是由PAM模块pamlimits.so来加载，通过ssh访问会调用sshdPAM。如上分析，本次数据库故障是操作系统引发，建议回退openssh版本，或者修改UsePAMyes。

接到一起数据库故障，用户反馈主机cpu频繁告警，操作系统只安装了数据库，查看mysql后没有发现error日志，ptquerydigest分析最近1一个月的slowlog，没有找到慢SQL。查看cpu耗时长的函数，都属于常规的大接口，除了软中断引发关注外，没发现其他异常函数调用。但是从这里可以看出，cpu资源几乎都被mysql服务使用了，且数据库负载较大。这里再次印证了数据库高负载。如下图，数据库查询非常大，reads/s每秒查询达到了280万行，这已是普通虚拟机的极限了。inserts/s、updates/s、deletes/s表示数据库TPS。一般好点的机器，TPS可以跑到4000多。数据库除了负载较高，并无其他异常，所以排查重点应该放在sql查询。实例中正在运行的慢sql数超过cpu核数时，cpu负载就会很高。使用ptquerydigest解析慢sql，代码段中耗时最长的sql，占用慢sql总耗时的27%，远远高于其他sql。当耗时短的sql执行频率很高时，也可能造成数据库负载。另外建议开发归档了部分历史数据，进一步提升了查询效率。优化后，数据库并发线程数降低到10个左右，

最近遇到一起大量openingtables导致数据库hang起的生产事故，借此机会总结一下。故障发生后查看showprocesslist，发现大量线程处于openingtables状态，大多数语句无法正常执行，甚至kill语句也会卡住。此时，如果短时间无法找到原因，最有效的解决方法是立刻重启实例，如果条件容许，建议打几个pstack，然后事后分析。当Opentables值大于tableopencache值，且新的连接无法命中tablecache时，就需要再次打开并缓存表定义，此时就会有大量的线程处于openingtables状态。所以，当数据库负载较大时在大表执行了truncate操作，AHI维护耗时就会很长，导致其他用户线程无法获取字典锁而处于Openingtables状态。即在一个事务里修改字典数据，成功后再删除rename的临时表。查看数据库中AHI的命中率，如果命中率较低，可以考虑关闭AHI功能。

主库每隔1分钟，就出现严重的性能抖动，正常秒级执行完成的sql耗时陡增到15秒。发现mgr主备延迟严重，在其中一个secondary节点有大量事务堆积。出现这个问题是因为备份的中继日志重放发生了异常。首先想到的是mgr的流控功能，查看了mgr三个节点，都是关闭状态。其次，mgr备节点sql线程阻塞引发的延迟问题还会影响到数据库认证。官方mgr是木桶原理，取决于最慢的节点，认证数据库会保持认证数据库信息，由最慢节点的gtid来删除过期的认证数据库信息，那备库卡主时，内存使用率会不断升高，甚至引发OOM。

可能的原因是该文件的权限不正确或者所在的磁盘已满。Jobformysqld.servicefailedbecausethecontrolprocessexitedwitherrorcode.See"systemctlstatusmysqld.service"and"journalctlxe"fordetails.其中，mysql:mysql是指将文件的拥有者和所属组都设置为mysql用户。你可以使用如下命令查看磁盘使用情况：。找到磁盘使用率较高的目录，并清理一些不必要的文件。完成以上步骤后，你可以尝试再次修改密码。

在使用mgr的过程中，我们会经常看到以下报错，大概意思是：“由于网络故障，成员被逐出mgr集群，并将该成员状态更改为ERROR”。这因为mgr集群节点间心跳检测超时，少数派节点被驱逐导致的。20220731T13:07:37.45876100:000[ERROR][MY011505][Repl]Plugingroupreplicationreported:'Memberwasexpelledfromthegroupduetonetworkfailures,changingmemberstatustoERROR.'.下面结合一个具体的案例，分析GroupReplication的故障检测流程。恢复网络连接，看看各节点又是如何反应的。通过iptables命令断开node3与node1、node2之间的网络连接。显示node3处于UNREACHABLE状态。

运维既是个技术活儿也是个苦差事，而运维人员被期望有着无限的技能：主机、存储、网络、操作系统样样精通，而且还要会写SQL、shell、开发语言java、.net、python等等，对业务更是门清，对各个用户的脾气喜好也要了如指掌。

Needtocreateanewinnodbsystemdatafile‘ibdata2’.这个错误通常发生在InnoDB存储引擎的MySQL数据库中。它意味着在MySQL实例中，InnoDB存储引擎正在尝试使用一个大小与实际不同的ibdata1文件。根据报错信息计算出正确的数值。同时，由于ibdata1文件是MySQL中的核心文件，因此在进行备份和恢复时需要特别注意。

[ERROR][MY011825][Xtrabackup]FoundtableswithrowversionsduetoINSTANTADD/DROPcolumns.ALGORITHMINSTANT的支持：用户可以在表的任何位置即时添加列、即时删除列、添加列时评估行大小限制。ALGORITHMINSTANT的新特性，InnoDBredolog格式对于所有DML操作都发生了变化。新的redo日志格式引入了一个设计缺陷，会导致instantadd/dropcolumns的表数据损坏。由于XtraBackup无法处理社区版MySQL8.0.29生成的损坏的redolog，因此，如果XtraBackup8.0.29版本检测到具有INSTANTADD/DROP列的表，它将不会进行备份，并且会生成错误信息列出受影响表的列表并提供将它们转换为常规表的说明。如果有，可以先执行altertable操作，然后再去备份。经测试，8.0.29、8.0.30、8.0.31均存在这个问题。建议遇到这个问题后，直接升级版本到8.0.33。