jvm securerandom.source 导致的sqoop问题分析

在利用sqoop做抽取数据的同步过程中，经常发生以下错误。我们一直以为是oracle数据库没有打开或者某种连接异常，导致经常要重跑多次才能成功，甚至一度靠加入调度系统的智能重跑关键字中让任务多次重试，一直未定位到根本问题并找到解决办法（如下图），会影响调度成功率。

而这次，我们临时要在新环境跑sqoop任务，只起了一个sqoop客户端，失败的概率特别高，所以找到这个问题的解决办法就显得异常急迫。我回顾一下当时的解决思路：

 

1. 找dba沟通，明确问题确实不是出在oracle数据库那边，因为数据库的报错一定会返回ORA等异常，而这里明显没到数据库，只是jdbc报了java.sql.SQLRecoverableException。那问题只能出在sqoop或jdbc的上
2. 怀疑sqoop的问题，从以前客户端copy sqoop到新客户端，刚开始好了，再多次重试，又报错了。绝望
3. 突然回想起来，以前解决过一个sqoop问题好像和jdk相关
4. 回忆jdk，在调度机找到$JAVA_HOME/jre/lib/security/java.security，终于发现

   

当时把securerandom.source=file:/dev/urandom改为了securerandom.source=file:/dev./urandom

5. 把所有客户端的jdk都改一下，发现问题不再重现，解决了！

 

那究竟是什么原因导致jdk 的这个系统参数会引发问题呢？

1. Jdk 连接oracle的时，从某个版本开始

The JDBC 11gneeds about 40 bytes of secure random numbers, gathered from /dev/random, toencrypt its connect string.

2. linux有两种类型随机数发生器,一个是/dev/random，一个是/dev/urandom，urandom=unlocked random，即非阻塞随机。要产生真实的随机，linux是搜集真实的随机事件放到一个熵池里，当随机事件不足是，/dev/random会阻塞等到有随机事件产生才返回，而/dev/urandom则会重复利用以前的随机事件迅速返回。
3. 那这里默认就是使用的/dev/urandom，为什么还是有问题呢？

因为这个版本的jdk，实际上在jdk代码里当匹配到/dev/urandom时实际上还是指向了/dev/random，于是大家就想到了一个变通办法采用/dev/./urandom，在linux系统中，加个点表示当前路径这个和之前一样，但是jdk代码却不不配，就绕过去了

 

 

从这个事件中的反思：

1. 要重视bug的记录，便于长时间或者工作交接的问题追踪。磨刀不误砍柴工

2. 碰到问题不可怕，要培养深入解决问题的习惯，深入解决问题就是提升的机会