:00" 导致相关业务查询数据不一致。...具体开发怎么操作的呢？又触发了什么开关导致数据不一致的呢？...但是b字段的值从 2020-08-20 12:08:59 变成 0000-00-00 00:00:00，明显不符合预期。这也是导致后面查询某些时间段的数据，导致正常的数据缺失的。...MySQL 做逻辑判断或者运算的时候，判断符号，等号左右两边的值务必保持一致。datetime = datetime +1 本身也是不合理的用法。...最后做个小调查吧 你们的生产环境使用了严格模式的 sql_mode吗 -The End-
一、问题现象 某项目上出现 MySQL Crash，相关 errorlog 日志如下，从日志可以看出是 binlog error 导致的问题，但是无法确认具体原因，网上大部分资料都说是由于空间已满导致，...后来在系统日志( /var/log/message)中确实找到了 / 分区空间已满的信息，所以基本可以确认 binlog error 是由于磁盘空间已满导致，进而造成 MySQL Crash。...binlog_error 的异常，导致 MySQL crash！...my: fd: 51 Buffer: 0x7f24c49e9e30 Count: 27 由于/data/tmp磁盘已满，无法写入Count所需的字节数，导致writtenbytes!...时，每个连接都会分配 32MB 的 binlog_cache( 不管你用多少)，那么就是将近 10G，很容易导致内存溢出，被系统 OOM。
案例分析 由于客户使用的是我司爱可生的 DMP 数据库管理平台，当备份失败时，在备份目录中会写入一个 FAIL 的标志文件，然后回滚掉残留文件，此时 Xtrabackup 自身的日志已无法查看，不过可以通过...Retry the backup operation 经确认，客户的确是在凌晨执行了 DDL 业务变更，变更的内容为创建一张新表，并给现存的两张表添加字段，加字段的表大约有几百万行记录，这一信息与日志给出的内容吻合...，看来问题大概率是出在加字段的 DDL 操作上 那什么是不记录 redo 的 DDL 的操作呢？...Retry the backup operation dmp2 /data/urman-agent/bin# ## 以上步骤，直接复现了客户生产环境的故障场景 终止脚本 mysql: [Warning...interrupted 小结 默认情况下，即使是 Xtrabackup 高版本，如果备份时并发执行 DDL ，并且没有指定 DDL 锁参数（--lock-ddl，--lock-ddl-per-table），会导致备份失败
墨墨导读：底层超融合故障导致数据库产生较多坏块，最终导致数据库宕机。 背景概述 某客户数据由于底层超融合故障导致数据库产生有大量的坏块，最终导致数据库宕机，通过数据抢救，恢复了全部的数据。...下面是详细的故障分析诊断过程，以及详细的解决方案描述： 故障现象 数据库宕机之后，现场工程师开始用rman备份恢复数据库，当数据库alert日志提示控制文件有大量坏块。 ?...START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) ----- Successfully dispatched 发现访问14号回滚段后出现故障...新建undo，并且删掉老的undo表空间 SQL> alter system set undo_tablespace=undotbs02 sid='sid1'; SQL> drop tablespace
墨墨导读：本文详述硬件掉电后，Oracle集群无法启动的诡异故障处理过程。 一、 问题描述 现象：硬件掉电后，Oracle集群无法启动。...二、 故障处理 查看集群组件发现ora.asm状态为offline root@rac2 ~]# crsctl stat res -t -init ----------------------------...Oracle认为这是存储或者OS问题导致asm acd block的元数据不一致了，可能导致ASM元数据的主辅扩展区都发生损坏。...这个损坏会导致rebalance挂起或不断尝试失败，或者阻止磁盘组被挂载。...0 kfracdb.lge[1].chgCount: 1 ; 0x041: 0x01 check等信息属于hash值，每隔3s都会更新一次，可能是由于突然掉电，cache里的信息没有更新到磁盘中导致
墨墨导读：一套19C CDB数据库，存储更换HBA卡宕，本文详述这起begin backup导致的故障恢复全过程。...当时RECOVER DATABASE 提示找不到归档（需要6-18号的归档） 由于有存储相关操作，误以为其它原因导致的问题，没有关注该报错，查询vdatafile,vdatafile,vdatafile_header...切记，任何危险的变更操作都需要备份。做到可回退！！！ 咨询公司专家后，确定为某此表空间做了begin backup导致。begin backup后文件头上的checkpoint不再更新。...这时由于之前做了restore cdbroot的操作，控制文件，cdbroot的文件已从备份中还原，导致不能再end backup操作，1个月前的归档已清理，也没办法从6-18开始应用归档。...下面测试重现了该问题，及正确的处理方法。不过19C中并没有人为发起begin backup,需要继续排查什么原因导致。
起因 nginx服务器采用的keepalived+vip实现的双活，最近由于一台服务器有问题，更换了一台nginx： 操作： 停止有问题服务器keepalived和nginx 新服务器部署keepalived...再出故障，最终定位 一晚过去无异常，第二天又出现部分域名不能访问，检查服务一切正常，因此怀疑是VIP导致的问题，检查之前有问题服务器的ip： ip addr 果不其然： 2: eno1: <BROADCAST...，竟然还在这个有问题服务器的网卡上，这就导致一个机房内，有2台服务器绑定相同的vip。...，keepalived为网卡停止后，keepalived为网卡绑定的VIP并没有移除，导致多台机器出现同样的ip。...您的支持是对博主最大的鼓励，感谢您的认真阅读。
这篇博客是个占位符，后续会用完整的检验报告进行替换，来披露今天的发生的问题。 今天有大概 30 分钟，Cloudflare 网站的浏览者收到了 502 错误，起因是我们网络中的 CPU 使用率飙升。...UTC 2009 更新 在今天的 UTC 1342，我们经历了一次全网范围内的故障，所有访问被 Cloudflare 代理的域都显示 502 错误（“Bad Gateway”）。...不幸的是，这些规则中有一条包含了一个正则表达式，导致 CPU 使用率升到 100%。这个 CPU 高峰导致用户看到了 502 错误。最差的情况下有 82% 流量被丢弃。...我们持续的在网络上进行软件部署，用自动系统运行测试，并且有渐进的部署过程来预防事故。很不巧，WAF 规则是一次性的全球部署的，这是今天事故的主因。...我们测试过程的不足导致了这一故障，我们正在审查并更改我们的测试和部署流程，来避免此类问题的再次发生。
1、问题发现 检查客户数据库的时候发现存在大量死锁的情况 Thread 1 advanced to log sequence 257 (LGWR switch) Current log# 16 seq...，并和业务确定了属于业务SQL lock table pz2018 in exclusive mode 到这里问题已经清楚了，整个逻辑是这样的 241号会话将pz2018全表排他模式进行了锁定，导致4468...会话无法对pz2018表进行insert操作，原因是无法在表上获取共享排它锁即SX锁，导致4468号会话进入等待模式 而4468号会话在等待前进行了insert into pzd2018操作，而241号会话在插入时存在唯一约束...，导致241会话进行TX锁等待，等待4468号session数据提交或者回滚 这样一个环状等待就形成了即死锁 等待发生时会话的等待情况 SQL> select a.sample_time, 2 ...read ZDCW\WANGH88208561 XCV5（新5.24）.exe INSERT 8 rows selected 3、锁等待的模拟
故障概述 某天晚上，我方收到行方请求协助分析某数据库两节点RAC数据库问题，问题描述如下： 该 数据库版本为11.2.0.3，该版本中ASM内存管理机制有所变化，导致ASM实例对共享内存的需求加大，由于该数据库...故障分析 从节点2 alert_+ASM2.log日志中看到，12月7日 18:01:50在节点2修改ASM实例内存参数，并于18:04:33重启节点2 ASM实例。...因此进一步观察节点1 crsd进程日志，可以看到在节点2重启集群的过程中，节点1由于ORA-4031错误导致导致ASM实例与存储OCR文件的ASM DATADG交互产生问题。...crsd进程由于ASM实例的ORA-4031错误导致ASM实例与磁盘组之间的交互产生问题，那么我们进一步分析问题时段节点1grid集群alert_csrrac01.log同样可以看到ORA-4031错误导致...故障总结 由于本次ASM内存参数调整，首先更改并重启节点2集群，在此过程中节点1 ASM实例遭遇严重的ORA-4031错误，导致CRSD进程异常，从而引发节点1集群状态异常。
在两天前第一次遇到自己的程序出现死锁， 我一直非常的小心使用锁，了解死锁导致的各种可能性， 这次的经历让我未来会更加小心，下面来回顾一下死锁发生的过程与代码演进的过程吧。...5天就挂了，实际是当时业务订单需求很少，只是有很多流量请求，并没有频繁访问这个方法，否者会在极短的时间导致死锁， 通过这块简化的代码，也很难分析出会导致死锁，真实的业务代码很多，而且调用关系比较复杂，我们通过代码审核并没有发现任何问题...这些数据帮助我快速定位确实是有请求发送到服务器，服务器无法响应导致短时间内占用很多文件打开数，导致系统限制无法建立新的连接。...接下来就是查找代码问题了，期间又出现了一次故障，立即重启服务，恢复业务。...总结 以前特别强调过读锁重入导致死锁的问题，而且这个问题非常难在业务代码里面复现，触发几率很低， 编译和运行时都无法检测这种情况，所以千万不能陷入读锁重入的嵌套使用的情况，否者问题非常难以排查。
1背景 在执行跑批任务的过程中，应用程序遇到了一个问题：部分任务的数据库连接会突然丢失，导致任务无法完成。...客户端发送或接收的数据包大小超过了 max_allowed_packet 参数的值，导致连接中断。 客户端试图访问数据库，但没有权限，或者使用了错误的密码，或者连接包不包含正确的信息。...我们猜测可能是网络有异常，导致客户端接收不到服务器返回的 ACK 包，所以服务器会反复发送 ACK 包，直到超时或收到客户端的响应。但是，经过网络人员的排查，未发现有明显的问题。...60 秒内未把缓存中的数据处理掉，导致 MySQL 往客户端发送数据超时。...4优化建议 业务层面进行分批处理数据，避免单个 SQL 从服务器获取大量的数据，导致客户端的 TCP 缓存不足。
二、定位故障 根据这种故障的一般处理思路，先找出问题进程内CPU占用率高的线程，再通过线程栈信息找出该线程当时在运行的问题代码段，操作如下： 根据思路查看高占用的“进程中”占用高的“线程”，追踪发现7163...将16298的线程ID转换为16进制的线程ID。 printf "%x\n" 16298 3faa 通过jvm的jstack查看进程信息，发现是调用数据库的问题。...确认表中数据量，发现表中已经有将近300万条数据，判断问题是查询时间过长导致的，使用的命令如下： use databases_name； select count(1) from table_name...show create table table_name; 四、结果 处理后进程的CPU占用到了40%，本次排查主要用到了jvm进程查看及dump进程详细信息的操作，确认是由数据库问题导致的原因，并对数据库进行了清理并创建了索引...，还会导致buffer失效，通常的优化方法还是添加索引。
二、分析问题： 后来用df -i查看了一下/data分区的索引节点(inode)，发现已经用满(IUsed=100%)，导致系统无法创建新目录和文件。 ? ...而inode呢，就是用来存储这些数据的信息，这些信息包括文件大小、属主、归属的用户组、读写权限等。inode为每个文件进行信息索引，所以就有了inode的数值。...操作系统根据指令，能通过inode值最快的找到相对应的文件。 而这台服务器的Block虽然还有剩余，但inode已经用满，因此在创建新目录或文件时，系统提示磁盘空间不足。 ...三、查找原因： /data/cache目录中存在数量非常多的小字节缓存文件，占用的Block不多，但是占用了大量的inode。 ...四、解决方案： 1、删除/data/cache目录中的部分文件，释放出/data分区的一部分inode。
---- 1故障背景 在做 MySQL 同构的数据迁移过程中，我们通常只需要按流程搭建主从保持数据同步即可。一般构建复制只要网络没问题，基本都能顺利构建成功。而这次踩了一个小坑，记录一下。...同事反馈做完 change master 后，IO 线程始终显示连接不上主库，已经反复确认该复制账号的权限、账号密码都没问题，且也验证了通过 MySQL 客户端的命令行输入相同的账号密码能正常连接到主库...，已经做了以下场景的排除工作： 排除了账号密码错误的问题 排除了账号权限不足的问题 排除了网络不通的问题 2故障分析 通过源端主库的错误日志也能持续观测到该复制用户频繁的尝试连接但都失败,错误日志的报错仅告知用了密码但访问受限...，比较常规的报错信息。...retries: 1 message: Access denied for user 'repl'@'10.186.61.27' (using password: YES) 3问题复现 尝试复现验证是否为该属性导致
发起的地方，有日志为证，也就是 http 库的函数的调用是有实际发生的，但是为什么没有请求，甚至没有建连。...有几种可能，一种可能是连接池满了，这种情况下，http 调用 block 在连接池的获取处，但是经过 netstat 查看一个连接都没有，排除了连接池满导致的问题。...这样就可以避免出现 SlowIO 任务把所有的线程池占满，导致其它类型的任务没有机会执行。...那是不是这个域名的请求，一直没有正确结果的返回，导致占满了 SlowIO 的 2 个线程呢？...域名解析迟迟没有返回，把 Node 内部的 libuv 的两个 SlowIO 线程占满，导致后续所有的 DNS 请求都无法继续进行下去。
Pre 测试环境，搭建的伪集群 101 ： 7001 7002 7003 三个节点 102 ： 7004 7005 7006 三个节点 机房异常断电，主机宕机~ ---- 现象 Redis Cluster...这是对集群完整性的一种保护措施， 保证所有的槽都指派给在线的节点。 可以看到 slot 有未分配的情况， 那如何重新分配这些slots 便是解决问题的关键。...---- 查找未指派的slots 方式一 cluster slots 172.168.15.101:7001> CLUSTER SLOTS 1) 1) (integer) 5461 2) (integer...随后分析一下 ~~~ ---- 计算未指派的slots ,重新添加 看7003 这个master 后面的slot分布情况 5461-5591 5593-5783 5785-5913 5915-6157...Reason - cluster_state:fail 连上7002端口 （一定要上7002上看，不要再其他端口查看节点信息），重复刚才的操作 。 期间重启了几次节点 ，故障恢复 。
作者：徐耀荣 爱可生南区交付服务部 DBA 团队成员，主要负责MySQL故障处理以及相关技术支持。爱好电影，游戏，旅游以及桌球。...utf8mb4_0900_ai_ci ，而在 t1 表的排序规则为 utf8mb4_general_ci ，那么我们试着将排序规则相关的参数修改后再执行 SQL 看看，修改后的环境参数如下 mysql...从上述原文可知如果 convert 只指定了字符集，那么该结果的排序规则就是所指定字符集的默认规则，由之前的测试情况可知，convert 使用的是 INFORMATION_SCHEMA.COLLATIONS...SET 的查询结果，并不会改变字符集的默认排序规则，所以utf8mb4 的默认规则还是 utf8mb4_0900_ai_ci ，sql 执行依然会报错。...使用convert函数转换字符集时，当字段排序规则不是转换后字符集的默认排序规则，需要指定具体的排序规则。
作者：姜宇 爱可生 DBA 成员，主要负责 MySQL 故障处理及 DMP 平台相关技术支持。追求技术，乐此不疲。...---- 在一些数据补偿的场景中，使用备份导入表数据的时候，如果已知目标表存在冲突数据，会搭配 mysql 的 --force 参数来跳过冲突的行数据，防止批处理因为行冲突中断退出。...但是在某些情况下可能会导致部分备份数据未导入的情况。...SQL ，导致部分数据丢失。...使用 skip-extended-insert 单行批量插入的模式会增加备份文件的大小和备份文件导入的时间，此方法只适用于表数据量不大的情况。若有收获，就点个赞吧
今天就来跟大家分享下整个过程以及我的处理方法。避免大家在今后的学习或工作中遇到跟我同样的问题。 一、问题背景 有一天，研发小伙伴跟我反馈有一台服务器连不上，一直卡在如下页面。...还好服务器有配置远程管理地址，通过远程控制管理页面的方式启动 iKVM HTML5 和远程管理服务器，这样就能登到这台出故障的设备上查看服务器界面处于一种什么样的状态。...登到这台故障的服务器后，直接重启了服务器，然后 Xshell 再次尝试连接，是可以远程连接的。难道这就是传说中的重启治百病，如此简单粗暴？ 当进入系统后，执行简单的命令都提示输入/输出错误。...第一列：Filesystem文件系统的名称 第二列：Size文件系统的容量 第三列：Used已用多少的磁盘空间 第四列：Avail可用多少的磁盘空间 第五列：Use%磁盘使用率 第六列：Mounted...恰巧，这台故障的服务器有多块硬盘组成的 44T 的一个目录有存放 46% 的数据，在有数据的情况下，如何不格式化磁盘重新挂载呢？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
