java连接mysql出错了 message from server: "Can't get hostname for your address"

来源：蜘蛛抓取(WebSpider) 时间：2016-07-03 07:50 标签：

解决方法：master和slave配置成同一个IP导致嘚要配成不同IP

16、经验：不要随意格式化HDFS，这会带来数据版本不一致等诸多问题格式化前要清空数据文件夹

解决方法：sshd被关闭或没安装導致，which sshd检查是否安装若已经安装，则sshd restart并ssh 本机hostname，检查是否连接成功

解决方法：pom.xml文件中标签下加入

解决方法：清除ES中跟scala数据类型不兼容的髒数据

133、HDFS误删文件如何恢复解决方法：core-site文件中加入

     HDFS垃圾箱设置可以恢复误删除，配置的值为分钟数0为禁用

134、改了linux定时脚本里边部分任務顺序，导致有些任务未执行而有些重复执行

解决方法：Linux脚本修改后实时生效，务必在脚本全部执行完再修改以免产生副作用

135、经验：spark两个分区方法coalesce和repartition，前者窄依赖分区后数据不均匀，后者宽依赖引发shuffle操作，分区后数据均匀

解决方法：去掉以hdfs开头的IP端口号前缀直接写HDFS中的绝对路径，并用单引号括起来

142、crontab中启动的shell脚本不能正常运行但是使用手动执行没有问题

解决方法：集群资源不够，确保真实剩餘内存大于spark job申请的内存

145、启动presto服务器部分节点启动不成功

解决方法：JVM所分配的内存，必须小于真实剩余内存

149、大数据ETL可视化有哪些主流方案

150、经验：presto集群没必要采用on yarn模式因为hadoop依赖HDFS，如果部分机器磁盘很小HADOOP会很尴尬，而presto是纯内存计算不依赖磁盘，独立安装可以跨越多個集群可以说有内存的地方就可以有presto

我在刚开始学习数据库的时候沒少走弯路。经常会遇到各种稀奇古怪的 error 信息遇到报错会很慌张，急需一个解决问题的办法跟无头苍蝇一样，会不加思索地把错误粘箌百度上希望赶紧查找一下有没有好的处理问题的方法。我想这个应该是刚从事数据库的小白都会遇到窘境。

今天就给大家列举 MySQL 数据庫中最经典的十大错误案例，并附有处理问题的解决思路和方法希望能给刚入行，或数据库爱好者一些帮助今后再遇到任何报错，峩们都可以很淡定地去处理

学习任何一门技术的同时，其实就是自我修炼的过程沉下心，尝试去拥抱数据的世界！

Too many connections（连接数过多导致连接不上数据库，业务无法正常进行）

1、首先先要考虑在我们 MySQL 数据库参数文件里面对应的 max_connections 这个参数值是不是设置的太小了，导致客户端连接数超过了数据库所承受的最大值

● 该值默认大小是151，我们可以根据实际情况进行调整

但这样调整会有隐患，因为我们无法确认數据库是否可以承担这么大的连接压力就好比原来一个人只能吃一个馒头，但现在却非要让他吃 10 个他肯定接受不了。反应到服务器上媔就有可能会出现宕机的可能。

所以这又反应出了我们在新上线一个业务系统的时候，要做好压力测试保证后期对数据库进行优化調整。

2、其次可以限制 Innodb 的并发处理数量如果 innodb_thread_concurrency = 0（这种代表不受限制） 可以先改成 16或是64 看服务器压力。如果非常大可以先改的小一点让服務器的压力下来之后,然后再慢慢增大,根据自己的业务而定。个人建议可以先调整为 16 即可

MySQL 随着连接数的增加性能是会下降的，可以让开发配合设置 thread pool连接复用。在MySQL商业版中加入了thread pool这项功能

另外对于有的监控程序会读取 information_schema 下面的表可以考虑关闭下面的参数

Top 2：（主从复制报错类型）

我们有可能刚刚接手别人的 MySQL 数据库，而且没有完善的交接文档root 密码可以丢失或者忘记了。

目前是进入不了数据库的情况所以我们偠考虑是不是可以跳过权限。因为在数据库中mysql数据库中user表记录着我们用户的信息。

启动 MySQL 数据库的过程中可以这样执行：

Top 8：使用 binlog_format=statement 这种格式，跨库操作导致从库丢失数据，用户访问导致出现错误数据信息

在生产环境中建议使用binlog的格式为row，而且慎用binlog-do-db参数

大多数做 DBA 的同学，可能都会被开发人员告知你们的数据库报了这个错误了。赶紧看看是哪里的问题

这个问题是由两个参数影响的，wait_timeout 和 interactive_timeout数据默认的配置时间是28800（8小时）意味着，超过这个时间之后MySQL 数据库为了节省资源，就会在数据库端断开这个连接Mysql服务器端将其断开了，但是我们的程序再次使用这个连接时没有做任何判断所以就挂了。

先要了解这两个参数的特性；这两个参数必须同时设置而且必须要保证值一致財可以。

我们可以适当加大这个值8小时太长了，不适用于生产环境因为一个连接长时间不工作，还占用我们的连接数会消耗我们的系统资源。

可以适当在程序中做判断；强烈建议在操作结束时更改应用程序逻辑以正确关闭连接；然后设置一个比较合理的timeout的值（根据业務情况来判断）

有的时候数据库跑得好好的，突然报不能打开数据库文件的错误了

首先我们要先查看数据库的 error log。然后判断是表损坏還是权限问题。还有可能磁盘空间不足导致的不能正常访问表；操作系统的限制也要关注下；用 perror 工具查看具体错误！

超出最大打开文件数限制！ulimit -n查看系统的最大打开文件数是65535不可能超出！那必然是数据库的最大打开文件数超出限制！

发现该数值过小，改为2048重启 MySQL，应用正瑺

我要回帖

 

随机推荐