mysql lower_case_table_names 参数引起的一起事故_最终原因–initialize --lower-case-table-names=1 惹的祸-优快云博客

本文链接：https://blog.youkuaiyun.com/touch_future/article/details/70850471

异常情况描述：

hive 集群本来运行状况良好，突然之间不能用了，重启也没用，看日志显示hive metastore 启动异常，一个表找不到了，导致 hive metastore 启动不起来。此时当然是到mysql（hive metastore 的存储数据库）看里面是不是有这个表，用show table 发线表是存在的， SELECT count 发现mysql报表不存在。。。真是诡异，同属说重启看看，于是重启 mysql 数据库。重启之后依然不起作用，hive还是启动不起来，情况和原来一样。后来发现大数据管理平台也出问题，重启报错，某张表找不到。一下子感到事态严重，hive挂了还是小事，大数据平台要是重新弄的话，比价浪费时间，于是打算先把大数据平台修复。最后花了一个晚上加一个上午，最终解决了这个问题，就是lower_case_table_names 这个参数引起的。下面是我寻找问题的一些记录，希望对其他人有点帮助。

1 第一步，管理平台和hive都挂了，而且都是表找不到，我决定先修复管理平台，这个比较重要。通过看log发现，管理平台因为一张表找不到，启动失败。于是便到mysql中找这张表是否存在。

发现该表存在，但是SELECT count 出错：

很奇怪，于是到mysql数据存储的文件夹里看，发现这张表的frm文件是存在的，

由于对mysql不是很熟，于是到网上搜了一些资料。表的存储引擎为 Innodb，frm文件只是存储表的结构，而数据则是存储在 ibdata1中：

竟然只是一个文件，所以通过这个文件也不能够判断ORTZ_TERIGGERS是否存在。开始陷入了胡乱猜测中。猜测是不是由于操作太频繁造成mysql数据库表被锁住，发现不是：

陷入了绝境，不是因为表被锁住。带着疑问度过了一个夜晚，第二天早晨上班，一个晚上也没能想清楚到底是为啥，一个好端端的表就这样没了。领导下了命令，今天到晚上还搞不定，整个平台就重装！！！作为一个IT技术人员，遇到这种事情，我感觉到深深的耻辱，真是平时不学习，用时干着急。但这个"bug"也许超出我的范围。

2 网上大神多，你的大事都不是事。

平时比较喜欢参加一些线下活动，加的群比较多，虽然不是专业搞数据库，但是加了一个db geek 的群，很庆幸，仿佛抓住了一根救命稻草。于是在群上问管理员。后来竟发现这个管理员不是做技术的，是运营推广人员，汗。。。。。但是他给我推荐了一个大神，加了大神的qq，大神上来说让我看看这个参数：lower_case_table_names：

大神说不应该啊，这样没错，我也坚持应该不是大小写的问题或者表名字写错了，我都是复制粘贴的。然后我把情况向大神描述了一遍，经过大神初步判断是表损坏，于是问我要mysql的错误日志。我发给大神，大神经过一段时间看log，也开始陷入了深深的疑惑，错误日志里面并没有报错！！！我也惊呼，我之前的确也没看到什么错误，奇了怪了。大神于是开始坚定是哪个参数的原因，让我问问同事有没有改过这个参数。我坚信着数据库是我装的，都是默认参数，没动过啥参数，所以也没问，但是大神说让我试试把这个参数改成 0。我说可以，反正明天就重装了，试试就试试。我先到数据库里面select count 了表名是大写的，发现全都提示不存在，但是小写的表全都能查到，，，，我欣喜万分，终于找到原因了：

于是我开始问周围的同事，有没有谁改过这个参数，果然就被我问到了，昨天下午有一个同事在用工具往mysql里导数据，出现乱码，改了这个参数。。。原因终于找到了。。。hive在他改了哪个参数开始就挂了，真是生产事故，昨天下午我在用hive的时候，就感到一些很奇怪的事，我当时也郁闷了好久，这下全都清楚了！！！因为表名不区分大小写，所以查询时将表名全部转为小写，而当初建表的是用大写，操作系统对于文件名是区分大小写的，所以才会出现这个表明明存在却查不到。在上图也可以看清楚，from 后面的是大写，而报错的是小写。。。。frm文件是大写，操作系统的文件是区分大小写的。

下面就是把这个参数改过来，一切正常了，集群能工作，hive也正常运行了（猜想：把操作系统改成不区分大小写是不是也是可以的？？？理论上貌似是可以的，有待测试）。