建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

研究生喜羊羊

发帖: 34粉丝: 8

级别 : 新手上路

发消息 + 关注

发表于2019年10月29日 21:11:04 8517 1
直达本楼层的链接
楼主
显示全部楼层
[数据库] 鲲鹏生态_数据库解决方案故障案例

1.编译安装


1.1 Mysql 5.7 cmake编译安装失败

现象描述

06C45CE8-F3D7-479B-9331-E3AC04B689E2.png

E0CD1822-EDB2-4CD5-B0A3-8E488EF9FA7C.png

问题原因

原来的cmake出现异常,修改后未删除cmakecache.txt文件

处理步骤


  1. 删除cmakecache.txt文件

    rm CMakeCache.txt

  2. 重新编译Mysql 5.7数据库

  3. A2197936-8813-41A5-AAB2-79FDFE1B2E81.png



 

 

 

 

2.Mysql数据库


 2.1 初始化错误

现象描述

 初始化数据库时报错:[ERROR] [MY-010457] [Server] --initialize specified but the data directory has files in it

FBB98F88-6F89-455B-AA54-1BAA94F84509.png问题原因:

数据文件目录存在数据文件。

处理步骤

  1. 删除目录文件,重新执行初始化操作。

mysqld --defaults-file=/etc/my.cnf --initialize --datadir=/data/mysql-8.0.16/mysql/data --user=mysql

F7B883E5-43CF-44F4-A140-8581D27D8<span style=

2.2 Benchmarksql 测试错误

现象描述

运行Benchmaksql测试mysql数据库压力,报Lock wait timeout错误。

[Thread-86] ERROR jTPCCTData : Lock wait timeout exceeded; try restarting transaction
 
com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
 
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:123)
 
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
 
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
 
at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:955)
 
at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1094)
 
at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdateInternal(ClientPreparedStatement.java:1042)
 
at com.mysql.cj.jdbc.ClientPreparedStatement.executeLargeUpdate(ClientPreparedStatement.java:1345)
 
at com.mysql.cj.jdbc.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:1027)
 
at jTPCCTData.executeDeliveryBG(jTPCCTData.java:1623)
 
at jTPCCTData.execute(jTPCCTData.java:115)
 
at jTPCCTerminal.executeTransactions(jTPCCTerminal.java:237)
 
at jTPCCTerminal.run(jTPCCTerminal.java:88)
 
at java.base/java.lang.Thread.run(Thread.java:834)

问题原因:

MySQL的默认事物隔离级别是REPEATABLE-READ,该级别事物持有每个记录的锁在整个事物期间一直持有,所以REPEATABLE-READ尽量优化索引,防止锁定太多行数据导致其他事物失败,而READ-COMMITED级别,事务里面特定语句结束之后,不匹配该sql语句扫描条件的锁,会被释放;REPEATABLE-READreadview持锁到事物结束,而READ-COMMITED持锁到语句执行结束,但REPEATABLE-READ级别下,read view的性能更好。

处理步骤:

1.打开mysql参数文件

vim /etc/my.cnf

2. 加入内容:

transaction_isolation=READ-COMMITTED

3. 重启mysql数据库


2.3 Opening tables

现象描述

执行Show processlist命令,大量SQL都在opening_table状态

C13C9390-CA20-436C-92D3-645A949C29CA.png问题原因:

Table_open_cache参数设置较低

处理步骤

1. 打开mysql参数文件

vim /etc/my.cnf

2. 加入内容:

table_open_cache=10000

3.动态修改参数

Set global table_open_cache=10000

2.4 SQL性能差CPU利用率高

问题现象:

所有链接都在执行同一个Sql,所有SQL的状态都是sending data。
Sql执行计划:

C2F34A96-4153-42AF-9457-B8694DB20864.png

Perf查看热点函数

FA7B6851-62E6-4842-BEE6-D28CAE90E227.png

问题原因:

ha_index_next_same函数主要用于顺序访问索引的下一行,最终确保非唯一性索引的所有数据均被读取,几乎所有的sql都在访问这个热点函数。

MySQL通过辅助索引访问数据的访问路径如下:

184DA578-E4B6-44F4-A29D-F714FB7E0625.png

处理步骤:

创建一个辅助索引,包含查询需要的所有字段,sql访问数据时,不在需要访问Primary Index.

1.创建辅助索引

create index i_id_TEST on O_ITEM(I_CATEGORY,I_ID,I_DESC,I_DISCOUNT,I_NAME,I_PRICE,I_VERSION)

2.5 自适应哈希导致数据库性能差

现象描述:



 

MySQL版本5.7,使用TPCCRunner进行对mysql压力测试时,在数据库200并发的时候,tpmC值比较低。

问题原因:

通过show processlist查看数据库运行的SQL语句,几乎所有的连接都在执行同一条Select语句,查看执行计划,执行计划正常。

DFF5082D-58EC-4653-B6B1-74DA9CAA370C.png

02C4BBBF-E190-4B0C-80F3-311185CE694F.png

btr0sea.cc:195这一行源码产生的大量rw_lock等待。这段代码主要由于自适应Hash访问Hash bucket的时候,首先要分配一个latch,当压力比较大的时候会出现性能瓶颈。

Mysql会自动对完全置于内存中的表建立hash索引,提升访问速度。

处理步骤

关闭自适应哈希功能

1. 打开mysql参数文件

vim /etc/my.cnf

2. 加入内容:

innodb_adaptive_hash_index =OFF

3. 动态修改参数

Set global t innodb_adaptive_hash_index =OFF

2.6 MySQLARM弱内存序致死锁问题

现象描述:

近期使用sysbench对MySQL5.7社区版进行读写测试,在测试一段时间后,MySQL5.7出现死锁现象,测试停止。

通过gdb查看MySQL的线程栈信息,绝大部分线程均在等待锁

FD4D1D47-C53D-445E-BB93-2C3A8BC3CEE5.png

问题原因:

通过对代码进行分析,ARM属于Relaxed Memory Models,而X86是基于Total Store Ordering(TSO) model的更强保序的模型

对于以下伪代码,

3B48F634-1693-4B97-AA2E-D03F3A8B7A36.png

 

经过抽象后为如下伪代码:

 

9D0034C6-CCDE-4526-A95B-D8917A7C3864.png

在x86上不可能出现r1=1,r2=0的情况,但是在ARM上可能出现r1=1并且r2=0的情况,Mysql的Mutex和RWLock都是基于原子操作+无锁算法自行实现的,这个模块的乱序情况就特别突出。对于其他模块/程序,如果临界区是由正确实现的锁保护的就会正常运行,为了保证逻辑正确,需要在ARM版本额外增加内存屏障,额外关注关键字的读写顺序。

处理步骤:

Mariadb在2017年测试高通ARM服务器后,使用了__atomic系列函数修改了RWLock和Mutex的实现,__atomic系列函数可以保证SC(需指明内存序)并可以跨平台使用,可以保护lock_word、lock->waiters等关键字的读写顺序,解决MySQL死锁问题

3.  MongoDB

3.1 mangled name will change in C++17

现象描述:

10FBC7FD-71C6-400F-BE99-F45DDCB5987C.png

问题原因:

GCC 7 --Wall标志包含对C ++ 17兼容性的警告,这些错误不会影响MongoDB编译安装。

处理步骤

通过—disabel-warnings-as_errors,再次构建,将其从错误降级为警告

  1. 重新构建

python2 buildscripts/scons.py MONGO_VEpRSION=4.0.6 all CFLAGS="-march=armv8-a+crc -mtune=generic" -j64 --disable-warnings-as-errors

3.2  空间不足,编译安装失败

现象描述:

5A48E3C7-C9F3-4404-B7AF-36916D749413.png

问题原因:

Mongodb编译产生大量文件,编译时需要足够大的空间。

处理步骤

1.至少预留50G磁盘空间进行编译。


3.3 processor does not support `crc32cb w2,w2,w3'

现象描述:

E5469C43-F8B2-4DE6-8DCF-B9C39CFC4F5C.png

编译时,不支持crc32指令集。

处理步骤:


  1. ARMv8 CRC32指令集是可选的,编译时需要进行制定,使汇编器可以识别crc32指令集

python buildscripts/scons.py MONGO_VERSION=4.0.6 --prefix=/opt/mongo --disable-warnings-as-errors CFLAGS="-march=armv8-a+crc" install -j64


 

 

举报
分享

分享文章到朋友圈

分享文章到微博

北冥有鱼.

发帖: 71粉丝: 7

级别 : 中级会员

发消息 + 关注

发表于2019年11月15日 23:25:01
直达本楼层的链接
沙发
显示全部楼层

前来学习,感谢楼主

评论
研究生喜羊羊 2020-1-17 11:25 评论

不客气,哈

... 查看全部
点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册