之前别人安装的DolphginSceduler(以下简称DS),只有postgre数据源而没有其它，于是我有了添加另外两种数据源的想法。
最初的念头是只要将两种数据库的驱动jar拷贝到DS的lib目录，甚至不用其他操作就OK了，这就是问题肇始的地方。
于是我从本机拷贝了Oracle11g和MySQL8的driver，直接拷贝到了目标机的/home/dce/01_work/09_dev/dolpginscheduler/dolphinscheduler/lib里。
很自然，在DS UI里创建数据源依然宣告失败，明显DS的目录监控能力被我高估了，驱动jar不是一拷贝进去完事的，肯定还需要别的手段。
我上网搜索了一阵，感觉需要进入/home/dce/01_work/09_dev/dolpginscheduler/dolphinscheduler/bin目录里，执行./stopall.sh,再执行./startall.sh,然后我就这么做了。
之后我兴奋地登陆DS，想立即看数据源好用否，但意想不到的情况发生了，UI界面登录花了很长时间登录不进去，最后告我失败了。
我试了两把，一阵紧张感袭来，DS这个卵我才上手两天就被我搞坏了......，情急之下我微信联系了DS之前的安装者。
他正好在开会，没有设备查看，再问其他人，有人说log爆create connection SQLException,url:jdbc:mysql://127.0.0.1:3306/dolphinscheduler。。异常。
微信报知他们三人后，我也没有闲着，跑到/home/dce/01_work/09_dev/dolpginscheduler/dolphinscheduler/log里看出了什么事，几乎同时我在dolphinscheduler-worker.log也看到了MySQL的异常信息，但和别人告我的不一样。
这时我醒悟了，我拷到lib的MySQL驱动jar是8的，而DS用的本机MySQL是5.7的，重启服务后系统紊乱，不知道用哪个驱动，于是连不上本机DB，自然UI里也没法登录了。
于是我立刻删除之先拷入的MySQL8驱动jar，再次进入bin目录重启服务，之后登录和使用都正常了，而且Oracle的数据源也成功建立了。
但因为系统MySQL5.7的限制，它是不可能建立起连接到MySQL8的数据源的，只能连到小于等于5.7的其它MySQL数据源。
别的数据源可能只是拷贝jar和重启服务那么简单，但mySQL就这么特殊，或者说DS系统自带数据库就立即特殊起来，需要考虑驱动冲突的问题。
这件事也提醒自己，如果之前操作导致系统崩溃，回溯当时作为，逆着操作往往有效。
PS：上午一顿操作猛如虎，结果昨日在/home/dce/01_work/09_dev/dolpginscheduler/dolphinscheduler/conf/env/dolphinscheduler_env.sh里对PYTHON_HOME的修改失效了，它变回了原来的/usr/bin/python,我重新把它修改为/home/dce/ananconda3/bin/python,之再运行工作流定义节点，python脚本又恢复正常了。
END