故障分析 | 是谁偷走了我的 IO

故障分析 | MongoDB 5.0 报错 Illegal instruction 解决 作者:任仲禹 爱可生 DBA 团队成员,擅长故障分析和性能优化,文章相关技术问题,欢迎大家一起讨论。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 去年七月的一声炮响,MongoDB Inc 给我们送来了 MongoDB 5.0 ,该版不仅带来了核心特性—时序集合,但若使用不慎还会给我们埋些小小的“坑”;如果您的环境正准备安装、试用或升级到 MongoDB 5.0 ,那不妨留步讨论下。 现象 先注明下,我的 Linux 版本为 CentOS Lin. 阅读详情

作者:孙桥

爱可生DBA团队成员,主要负责MySQL和DMP平台日常的维持工作,对数据库自动化运维存有浓厚兴趣。

本文来源:原创投稿

*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。


前言

对于刚接触 MySQL 数据库不久的小伙伴来说,或多或少会遇到一些棘手的小问题;比如在数据库磁盘无损坏的情况下,我们经常会遇到数据库服务器的磁盘IO压力很大,但由于服务器上只有 MySQL 程序,我们第一想法肯定是某个连接用户在连到数据库后,背着我们在瞎搞着什么;然而直接通过 show processlist 命令,看到的结果不一定准确。下面模拟一个简单场景,让我们确切地定位问题所在。

场景模拟,制造 IO 压力

## 生成一张大表,用于测试[root@tidb-master ~]# /usr/share/sysbench/oltp_write_only.lua --mysql-host=10.186.61.36 --mysql-user=sun --mysql-password='xx' --mysql-port=3306 --mysql-db=testdb --tables=1 --table_size=15000000 --auto_inc=off --report-interval=2 --db-ps-mode=disable --time=100000 --threads=1 prepare
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Creating table 'sbtest1'...
Inserting 15000000 records into 'sbtest1'
Creating a secondary index on 'sbtest1'...## 对生成的表进行写操作
[root@tidb-master ~]# /usr/share/sysbench/oltp_write_only.lua --mysql-host=10.186.61.36 --mysql-user=sun --mysql-password='xx' --mysql-port=3306 --mysql-db=testdb --tables=1 --table_size=15000000 --auto_inc=off --report-interval=2 --db-ps-mode=disable --time=100000 --threads=1 run
sysbench 1.0.17 (using system LuaJIT 2.0.4)

Running the test with following options:
Number of threads: 1
Report intermediate results every 2 second(s)
Initializing random number generator from current time


Initializing worker threads...

Threads started!

[ 2s ] thds: 1 tps: 24.47 qps: 148.33 (r/w/o: 0.00/98.89/49.44) lat (ms,95%): 86.00 err/s: 0.00 reconn/s: 0.00
[ 4s ] thds: 1 tps: 53.02 qps: 318.62 (r/w/o: 0.00/212.58/106.04) lat (ms,95%): 48.34 err/s: 0.00 reconn/s: 0.00
[ 6s ] thds: 1 tps: 60.50 qps: 363.50 (r/w/o: 0.00/242.50/121.00) lat (ms,95%): 43.39 err/s: 0.00 reconn/s: 0.00
[ 8s ] thds: 1 tps: 65.50 qps: 391.02 (r/w/o: 0.00/260.01/131.01) lat (ms,95%): 39.65 err/s: 0.00 reconn/s: 0.00
[ 10s ] thds: 1 tps: 55.50 qps: 334.51 (r/w/o: 0.00/223.51/111.00) lat (ms,95%): 44.98 err/s: 0.00 reconn/s: 0.00
[ 12s ] thds: 1 tps: 57.00 qps: 340.99 (r/w/o: 0.00/227.00/114.00) lat (ms,95%): 38.25 err/s: 0.00 reconn/s: 0.00

问题分析

1、通过top命令发现io wait比较高,咦,What is going on?(假装不知道我在压测(●’◡’●))

top - 17:05:59 up 179 days,  7:05,  2 users,  load average: 0.84, 0.70, 0.93
Tasks: 181 total,   1 running, 180 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1.3 us,  0.7 sy,  0.0 ni, 95.3 id,  2.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  6.9 us,  3.8 sy,  0.0 ni, 60.3 id, 29.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  2.4 us,  2.0 sy,  0.0 ni, 90.8 id,  4.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  1.7 us,  1.3 sy,  0.0 ni, 95.3 id,  1.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  1.4 us,  1.0 sy,  0.0 ni, 95.6 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  3.1 us,  1.4 sy,  0.0 ni, 81.4 id, 14.2 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.7 us,  1.0 sy,  0.0 ni, 96.6 id,  1.7 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  1.0 us,  0.3 sy,  0.0 ni, 96.6 id,  2.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  0.3 us,  1.0 sy,  0.0 ni, 94.6 id,  4.1 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  2.4 us,  1.0 sy,  0.0 ni, 91.2 id,  5.4 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 : 14.7 us,  2.7 sy,  0.0 ni, 82.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  2.0 us,  1.0 sy,  0.0 ni, 96.0 id,  1.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12137024 total,   185984 free,  3987936 used,  7963104 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  7150088 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                            
 8858 actiont+  20   0 7249940   1.1g  11892 S  30.0  9.3 210:38.75 mysqld                                                                                             
26447 tidb      20   0 4000364   1.0g   4740 S   5.3  9.0  10018:23 TiFlashMain                                                                                        
22761 actiont+  20   0 2526348  36188   9756 S   4.0  0.3   1197:43 ustats                                                                                             
29004 root      20   0 3784084 103676   2012 S   2.0  0.9   1802:29 beam.s

2、通过iostat命令进一步分析,我们看到磁盘在频繁的写操作,维持在26M/s左右(%uitl值比较大,一般来说,值大于75%是表明磁盘压力比较大了)

[root@tidb-tikv01 ~]# iostat  -xm 1 
Linux 3.10.0-862.14.4.el7.x86_64 (tidb-tikv01)  04/22/2022      _x86_64_        (12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.21    0.00    0.44    0.18    0.10   98.07

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.01     0.18    3.53   22.99     0.08     0.25    25.84     0.19    7.16    5.64    7.40   0.71   1.88
scd0              0.00     0.00    0.00    0.00     0.00     0.00     6.00     0.00    0.50    0.50    0.00   0.50   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.22    0.00    1.19    8.28    0.09   88.23

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00  328.00 1800.00     5.12    26.24    30.17     3.18    1.49    4.68    0.91   0.41  88.30
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.63    0.00    1.03    6.68    0.09   90.57

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00  352.00 1918.00     5.50    27.82    30.06     2.96    1.31    3.21    0.96   0.37  83.60
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.54    0.00    1.96    8.77    0.09   83.65

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00  300.00 1682.00     4.69    25.68    31.38     3.09    1.55    3.68    1.17   0.45  88.60
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

3、通过iotop命令可以看到与MySQL相关线程ID 22233的IO消耗为52.59%,读为2.56M/s,同时线程ID 8879的写为27.31M/s(一般来说,IO列值越大,说明IO压力最有可能与其相关)

Total DISK READ :       5.29 M/s | Total DISK WRITE :      29.42 M/s
Actual DISK READ:       5.29 M/s | Actual DISK WRITE:      26.83 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                  
22233 be/4 actionte    2.56 M/s  473.07 K/s  0.00 % 52.59 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8879 be/4 actionte    0.00 B/s   27.31 M/s  0.00 % 17.76 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8887 be/4 actionte    0.00 B/s    0.00 B/s  0.00 % 10.10 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8907 be/4 actionte  116.33 K/s    0.00 B/s  0.00 %  6.27 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8930 be/4 actionte    7.76 K/s    0.00 B/s  0.00 %  3.45 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8910 be/4 actionte 1217.57 K/s    0.00 B/s  0.00 %  3.33 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 8911 be/4 actionte  372.25 K/s    0.00 B/s  0.00 %  1.53 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306
 2946 be/4 actionte    0.00 B/s 1985.34 B/s  0.00 %  1.52 % ustats
 8909 be/4 actionte  418.78 K/s    0.00 B/s  0.00 %  1.08 % mysqld --defaults-file=/opt/mysql/etc/3306/my.cnf --d~ --socket=/opt/mysql/data/3306/mysqld.sock --port=3306

4、将上面获取的系统线程ID带入到MySQL中,我们便可以查到连接用户sun一直在频繁写操作,现在我很怀疑你,但我先保持沉默

[root@tidb-tikv01 ~]# /opt/mysql/base/8.0.21/bin/mysql -S /opt/mysql/data/3306/mysqld.sock -pxx
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 15041
Server version: 8.0.21 MySQL Community Server - GPL

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select * from performance_schema.threads where THREAD_OS_ID=22233\G
*************************** 1. row ***************************
          THREAD_ID: 14880
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 14830           ### ID为148830连接在疯狂的进行写操作,show processlist可以看到正在进行的连接
   PROCESSLIST_USER: sun
   PROCESSLIST_HOST: 10.186.61.16
     PROCESSLIST_DB: testdb
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 0
  PROCESSLIST_STATE: updating
   PROCESSLIST_INFO: UPDATE sbtest1 SET k=k+1 WHERE id=7899611
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: TCP/IP
       THREAD_OS_ID: 22233          ### THREAD_OS_ID为linux系统中的线程ID
     RESOURCE_GROUP: USR_default
1 row in set (0.00 sec)

mysql> select * from performance_schema.threads where THREAD_OS_ID=8879\G
*************************** 1. row ***************************
          THREAD_ID: 21
               NAME: thread/innodb/page_flush_coordinator_thread ### MySQL自身刷脏数据线程,因为用户的频繁写操作,导致该线程一直进行落盘操作
               TYPE: BACKGROUND
     PROCESSLIST_ID: NULL
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
   PROCESSLIST_TIME: 264523
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 8879
     RESOURCE_GROUP: SYS_default
1 row in set (0.00 sec)

mysql> show processlist;
+-------+-----------------+--------------------+--------+------------------+--------+---------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
| Id    | User            | Host               | db     | Command          | Time   | State                                                         | Info                                                                                                 |
+-------+-----------------+--------------------+--------+------------------+--------+---------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
|     5 | event_scheduler | localhost          | NULL   | Daemon           | 264544 | Waiting on empty queue                                        | NULL                                                                                                 |
|     8 | universe_op     | 127.0.0.1:38362    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|     9 | universe_op     | 127.0.0.1:38374    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    10 | universe_op     | 127.0.0.1:38376    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    11 | universe_op     | 127.0.0.1:38380    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    12 | universe_op     | 127.0.0.1:38378    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    13 | universe_op     | 127.0.0.1:38384    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    14 | universe_op     | 127.0.0.1:38382    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
|    15 | universe_op     | 10.186.61.45:50322 | NULL   | Binlog Dump GTID | 264542 | Master has sent all binlog to slave; waiting for more updates | NULL                                                                                                 |
|    17 | universe_op     | 127.0.0.1:38454    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    18 | universe_op     | 127.0.0.1:38456    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    19 | universe_op     | 127.0.0.1:38458    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    20 | universe_op     | 127.0.0.1:38460    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    21 | universe_op     | 127.0.0.1:38462    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    22 | universe_op     | 127.0.0.1:38464    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    23 | universe_op     | 127.0.0.1:38452    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|    24 | universe_op     | 127.0.0.1:38466    | NULL   | Sleep            |     14 |                                                               | NULL                                                                                                 |
|   142 | universe_op     | 127.0.0.1:33390    | NULL   | Sleep            |      0 |                                                               | NULL                                                                                                 |
| 14830 | sun             | 10.186.61.16:60730 | testdb | Query            |      0 | update                                                        | INSERT INTO sbtest1 (id, k, c, pad) VALUES (7493994, 6518751, '15795471662-35813531247-93886706048-2 |
| 15041 | root            | localhost          | NULL   | Query            |      0 | starting                                                      | show processlist                                                                                     |
+-------+-----------------+--------------------+--------+------------------+--------+---------------------------------------------------------------+------------------------------------------------------------------------------------------------------+
20 rows in set (0.00 sec)

5、通过kill掉14830后,发现磁盘压力果然over了,你这“小阳人”( ̄ε(# ̄)☆╰╮o( ̄皿 ̄///)

mysql> kill 14830;
Query OK, 0 rows affected (0.00 sec)

mysql> exit
Bye
Segmentation fault
[root@tidb-tikv01 ~]# iostat -xm 1
Linux 3.10.0-862.14.4.el7.x86_64 (tidb-tikv01)  04/22/2022      _x86_64_        (12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.21    0.00    0.44    0.18    0.10   98.06

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.01     0.18    3.83   24.55     0.09     0.27    26.12     0.19    6.78    5.46    6.99   0.69   1.95
scd0              0.00     0.00    0.00    0.00     0.00     0.00     6.00     0.00    0.50    0.50    0.00   0.50   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.85    0.00    0.59    0.00    0.00   97.56

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00   61.00     0.00     0.46    15.52     0.01    0.20    0.00    0.20   0.18   1.10
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.36    0.00    0.84    0.08    0.00   95.71

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    10.00    1.00   53.00     0.02     0.48    18.81     2.87    0.22    1.00    0.21   1.31   7.10
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

备注说明:

生产环境可不要随随便便kill哦,出问题是要被鞭尸的呦~

总结

对于一些新入门的小可爱来说,以上方法可以循序渐进的帮助你定位到是哪些连接线程把你的服务器IO折腾高的,可以让你更加了解Linux系统与MySQL之间的联动关系。老鸟嘛,emmm…

故障分析 | bgsave 导致 redis 定期卡顿案例一则 作者:任坤 现居珠海,先后担任专职 Oracle 和 MySQL DBA,现在主要负责 MySQL、mongoDB 和 Redis 维护工作。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 1、背景 线上有套 redis 主从,版本4.0,开发抱怨说经常会出现周期性卡顿。 应用日志显示每隔10多分钟出现一次,一个普通调用就需要执行1s左右,然后自动恢复,get/set 均受影响 2、诊断 查看 redis qps 和 cpu 监控,均未发现有用线. 阅读详情

相关推荐

面向AI安全的异构SoC密码引擎

在讲安全之前,先用最通俗的话把两个核心概念讲清楚。第一个概念:SoC。SoC叫「系统级芯片」,你可以理解为把整台电脑缩进指甲盖大小的一块芯片里。我们的手机芯片、苹果M系列芯片、跑大模型的AI芯片,本质上都是SoC——CPU、GPU、内存控制器、接口、甚至AI专用计算单元,全部集成在一块芯片上。第二个概念:异构。「异构」就是「不同架构、不同能力的计算单元,在一块芯片里协同工作」。CPU是公司的管理层,擅长统筹调度、复杂决策、发号施令,但让它去干大规模重复计算,效率很低。GPU。

元直的博客 144

从原理到实战:Linux 系统性能诊断核心指标全解析及生产系统故障分析复盘

本文就对Linux操作系统诊断的相关知识进行系统梳理,CPU的原理(Interuption, IO Wait, User time, System time...), Memory的组成和工作原理(Free/Available, Slab, Page Cache/Buffer, Swap, mmap, Page Table),Disk(mmap), 同时,结合我们遇到的欣赏系统问题,进行极其详尽的分析复盘,以展现我们在系统问题分析诊断过程中的方法和思路。 读完本文,我们将获得系统层面诊断的扎实而全面的技能。

小昌昌的博客 425

工业互联网工控安全与工业质检AI大模型建设方案.pptx

工业互联网工控安全与工业质检AI大模型建设方案.pptx

Linux筑基-Linux 系统监控与性能调优

单位时间内,系统处于可运行状态和不可中断状态的平均进程数。输出包括 total、used、free、shared、buff/cache、available。报告进程、内存、交换、I/O、系统(中断、上下文切换)和 CPU 信息。显示系统运行时间、登录用户数和平均负载(1分钟、5分钟、15分钟)。按进程查看 I/O 使用情况(需要 root)。报告 CPU 和磁盘 I/O 统计。报告每个 CPU 核心的统计信息。实时查看网络带宽使用(需要安装)。查看网络连接、路由、接口统计等。按进程报告资源占用。

m0_73760532的博客 273

2024 《计算机网络》实验教学指导书.doc

2024 《计算机网络》实验教学指导书.doc

JetBrains Air:多Agent协同的IDE运行时架构解析

IDE智能编程正从单模型增强迈向多Agent协同范式。多Agent架构通过职责分离、上下文精简与运行时隔离,显著提升代码生成稳定性与合规性;其核心依赖轻量级嵌入式运行时(如ARL),支持AST级内存共享、eBPF安全拦截与毫秒级冷启动。该架构天然适配本地化部署、离线开发与高安全合规场景(如PCI-DSS、金融内网),并为Java/Python/TS等语言提供可扩展的规则驱动开发流水线。JetBrains Air正是这一技术路径的工程化落地代表。

weixin_30443075的博客 561

故障分析 | Bad handshake,升级 5.7.28 引起的“血案”

作者:陈俊聪 任职于中移信息基础平台部数据库组,负责 MySQL 数据库运维工作。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 引言 作为一名 DBA 碰到过升级出问题需要回退么?碰到过回退还解决不了问题么?我有幸遇到了一次凶险的升级“血案”。问题来自协助客户升级 MySQL,以修复一个安全漏洞。升级版本为 5.7.30,但这个问题源于 5.7.28,并且影响 5.7.28 以上的版本,所以文章主要对比 5.7.27 和 5.7.28 版本。 .

ActionTech的博客 5318

【ECCV 2024】动态范围直方图自注意力DHSA,即插即用!

直方图自注意力机制,将空间特征按强度分段并进行分组,然后在各个分组内或分组间应用自注意力,以选择性地关注具有动态范围的空间特征,并处理长距离内相似退化的像素。

qq_43303160的博客 1844

故障分析 | 一条 SELECT 语句跑崩了 MySQL ,怎么回事?

作者刘开洋爱可生交付服务团队北京DBA,对数据库及周边技术有浓厚的学习兴趣,喜欢看书,追求技术。本文来源原创投稿*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。在很多疑难问题的排查中,小编最近又遇到了一个select语句执行就会导致MySQL崩溃的问题,特来分享给大家。...

ActionTech的博客 2794

dpdk 源码分析 rte_ring

rte_ring源码分析

qq_40843445的博客 929

从零开始搭建水质监测系统:STM32+Lora+4G的物联网应用详解

本文详细介绍了如何从零开始搭建一个基于STM32、LoRa和4G技术的工业级水质监测物联网系统。文章深入剖析了系统架构设计、核心硬件选型(如STM32F103系列MCU)、关键电路接口、嵌入式软件驱动开发、多任务调度以及云端数据集成与可视化的完整实战流程,为智慧农业、环境监测等领域的物联网应用提供了宝贵的“避坑指南”和解决方案。

m0n1o2p的博客 583

故障分析 | ClickHouse 集群分布式 DDL 被阻塞案例一则

作者:任坤 现居珠海,先后担任专职 Oracle 和 MySQL DBA,现在主要负责 MySQL、mongoDB 和 Redis 维护工作。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 1、背景 线上有套10节点clickhouse集群,5分片 * 2副本,版本19.7.3。 开发执行一个创建分布式表的操作,9个节点都成功返回,有个节点报错,返回信息如下: Code: 159. DB::Exception: Received from 127..

ActionTech的博客 2675

【C++】小猫钓鱼纸牌游戏--C++实现

小猫钓鱼问题: 描述:初始,两个人各有n张牌(牌面0-10),顺序固定,只能按顺序出牌。然后,两个人轮流在桌面上以接龙的方式出牌,当某个人放置的牌在桌面上已经出现时,他收起相同牌面及其中间的牌作为自己的筹码,同时需要再放一张牌到桌面。某人手上的牌出完后,另一个人继续出,直到两人手上都没牌为止,输出结束时两个人手上的筹码数。 #include<iostream> using namespace std; struct queue { int head; //队列首 int tail; //

qq_41344430的博客 3202

故障分析 | 一次因为超过最大连接数的登陆限制

作者:王翔飞 爱可生研发团队测试成员,负责数据库管理平台的测试工作。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 本文关键字:最大连接数、TCP协议、MySQL协议、参数配置 现象 在测试某功能时,将 mysql 的最大连接数设置为 120,使用 sysbench 并发 200 插入数据, 上述错误是预期内的结果,因为 sysbench 的 200 个并发超过了 mysql 实例最大连接数; 随后,修改 sysbench 并发数为 100(.

ActionTech的博客 2565

2025-E题国一-简易自行瞄准装置:基于嘉立创地猛星/天猛星与K230的视觉巡线云台系统设计

本文详细介绍了2025年全国大学生电子设计竞赛E题一等奖作品——基于嘉立创地猛星/天猛星与K230的视觉巡线云台系统设计。该系统通过地猛星主控实现小车巡线,天猛星主控驱动云台,结合K230开发板的视觉识别能力,构建了一套完整的视觉巡线云台系统,实现了自动巡线与精准瞄准功能。文章深入剖析了硬件选型、双闭环PID控制算法、视觉识别与目标跟踪等核心技术,并分享了系统调试与避坑经验。

weixin_42596011的博客 673

NSIS教程(2): 传统用户界面(Classic UI)

NSIS教程: 《NSIS用户手册 中文版》 《NSIS图文教程集锦 - 轻狂志》 本文以一个完整的、传统界面的网易云音乐安装包的脚本为示例,来介绍NSIS传统用户界面的开发流程。 NSIS脚本 # 单行注释用井号"#"或分号";",跨行注释用可以用C/C++中注释语法。 # 使用!define定义一些常量(如安装包的版本号等) # 对常量或变量的引用可以使用如${PROD

while(1) { smile(); } 8万+

故障分析 | MySQL 临时表空间数据过多导致磁盘空间不足的问题排查

作者:宗杨 爱可生产品交付团队成员,主要负责公司运维平台和数据库运维故障诊断。喜爱数据库、容器等技术,爱好历史、追剧。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 一、事件背景 我们的合作客户,驻场人员报告说一个 RDS 实例出现磁盘不足的告警,需要排查。 告警信息: 告警内容: 数据库 data 磁盘不足,磁盘占用 80% 以上 数据库 binlog 磁盘不足,磁盘占用 80% 以上 二、排查过程 登陆告警的服务器,查看磁盘空间,并寻找大容量.

ActionTech的博客 2260

Python 爬虫教程:财经新闻实时抓取(最新资讯 + 关键词提取)

在当今信息爆炸的时代,财经新闻的实时获取对于投资者、研究人员以及普通大众来说都具有重要的价值。通过 Python 爬虫技术,我们可以高效地抓取财经新闻,并提取其中的关键信息,以便更好地进行数据分析和决策支持。本文将详细介绍如何使用 Python 编写一个财经新闻实时抓取系统,并结合关键词提取技术,帮助读者快速掌握 Python 爬虫的核心技能。

yansideyucsdn的博客 1049

故障分析 | 有效解决 MySQL 行锁等待超时问题【建议收藏】

作者:xuty 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 一、背景 #### 20191219 10:10:10,234 | com.alibaba.druid.filter.logging.Log4jFilter.statementLogError(Log4jFilter.java:152) | ERROR | {conn-105...

ActionTech的博客 2213

jre9下载 jdk9

(Java SE Runtime Environment 9.0) 9.0u175 官方最新版 【x86|x64】

OV9734 DATASHEET,完整规格书

OV9734完整规格书,包括电气参数,尺寸规格,寄存器配置表等

故障分析 | MySQL 启动遭遇 Permission denied 失败案例一则

作者:任坤现居珠海,先后担任专职 Oracle 和 MySQL DBA,现在主要负责 MySQL、mongoDB 和 Redis 维护工作。本文来源:原创投稿*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

ActionTech的博客 2100

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

故障分析 | MySQL 使用 load data 导入数据错误的一个场景

作者:刘晨网名 bisal ,具有十年以上的应用运维工作经验,目前主要从事数据库应用研发能力提升和技术管理相关的工作,Oracle ACE ,腾讯云TVP,拥有 Oracle OCM & OCP 、EXIN DevOps Master 、SCJP 等国际认证,国内首批 Oracle YEP 成员,OCMU 成员,《DevOps 最佳实践》中文译者之一,优快云 & ITPub 专家博主,公众号"bisal的个人杂货铺",长期坚持分享技术文章,多次在线上和线下分享技术主题。本文来源:原创投稿。

ActionTech的博客 1987

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

故障分析 | MySQL:唯一键约束失效

作者:胡呈清 爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:https://www.jianshu.com/u/a95ec11f67a8,欢迎讨论。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 最近遇到一个故障:单主模式5节点 MGR 集群,在使用 mysqlshell 导入数据时,所有secondary节点报错唯一键冲突退出集群。最终得到的结论是:mysqlshell importTable() 导入数据时会做 SET uniqu.

ActionTech的博客 1980

故障分析 | MySQL : slave_compressed_protocol 导致 crash

作者:胡呈清 爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:https://www.jianshu.com/u/a95ec11f67a8,欢迎讨论。 本文来源:原创投稿 *爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。 现象 MySQL版本:8.0.18 create.sql:zabbix 初始化脚本,包含建表、插入数据语句,10M+大小 一个新客户,部署了一套我司的数据库管理平台,接管进来一主两从实例,其中一主一从在无锡机房,为半同步复制,另一个从库在北京.

ActionTech的博客 1951

故障分析 | MySQL 相同 SQL 不同环境执行时间不一样案例分析

书写SQL时,心里要明白哪种执行计划是最优的,比如多张表关联时,是否可以适当利用标量子查询、排除干扰驱动表选择因素,使执行计划简单稳定。

ActionTech的博客 1941

故障分析 | MySQL convert 函数导致的字符集报错处理

运维中为避免字符集引起的报错问题,有如下建议可供参考:(具体参数值根据业务需求选择)创建数据库实例时需指定参数 character_set_database(默认值:utf8mb4),character_set_server(默认值:utf8mb4)。当需要创建非默认字符集 database / table 时,需要在 sql 中明确指定字符集和排序规则。使用convert函数转换字符集时,当字段排序规则不是转换后字符集的默认排序规则,需要指定具体的排序规则。

ActionTech的博客 1823

故障分析 | 密码使用特殊字符

1.新建用户及登录用户时如果密码存在特殊字符需要注意特殊字符会被解析成其它字符,需加上单引号或加上转义字符\。2.在 MySQL 5.7.33 与 MySQL 8.0.23 版本前使用 login-path 时密码存在"#"时,配置时输入密码需要加上双引号。

ActionTech的博客 1814
上一篇: 技术分享 | MySQL 的 MDL 锁解惑
下一篇: 故障分析 | ClickHouse 集群分布式 DDL 被阻塞案例一则
爱可生开源社区
博客等级 码龄8年 1936粉丝 1004原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值