## 部署用户设置
echo 'user_name ALL=(ALL) NOPASSWD: NOPASSWD: ALL' >> /etc/sudoers
sed -i 's/Defaults requirett/#Defaults requirett/g' /etc/sudoers
## 免密登录配置
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
ssh-copy-id user_name @132.151.7.4
ssh-copy-id user_name @132.151.7.5
ssh-copy-id user_name @132.151.7.6
ssh-copy-id user_name @132.151.7.7
## 数据库初始化
##修改配置文件 bin/env/install_env.sh 和 dolphinscheduler_env.sh
bash bin/install.sh
Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.DefaultParser at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
这是因为commons-cli-1.2.jar包中确实没有DefaultParser类，因为zookeeper.jar使用了3.8.0所以是版本匹配不上导致。实际zk集群是3.4.6版本
替换为zookeeper-3.4.6.jar
又报错KeeperErrorCode = Unimplemented for curator zookeeper 版本匹配问题
替换为 curator-client-4.2.0.jar curator-framework-4.2.0.jar curator-recipes-4.2.0.jar
jar替换为旧版本后，记得清空installPath下的文件，不然重新部署`bash bin/install.sh`还会重复报错，，，
rm -rf dolphinscheduler
dolphinscheduler报错"TenantCode: xxx doesn't exist"
实际上这个租户已创建，而且linux上这个用户也存在，且有sudo权限。开启了缓存，也不知道是否有用 dolphinscheduler/master-server/conf/application.yaml cache: type: caffeine
2023年4月11日21:35:28
dolphinscheduler提交了一个seatunnel任务，但是发下task 提交后半天不执行，等了差不多十分钟才开始执行，看日志也没报错。后来耐下心来一句句日志地读，终于在worker-server/logs/dolphinscheduler-worker.log 中发现一句"[INFO] 2023-04-11 20:23:17.202 +0800 org.apache.dolphinscheduler.server.worker.processor.TaskDispatchProcessor:[121] - [WorkflowInstance-12][TaskInstance-28] - Current taskInstance is choose delay execution, delay time: 614s" ，但是我也没设置延迟614秒执行啊，实在不行，还是得看源码。
package org.apache.dolphinscheduler.server.worker.processor;
TaskDispatchProcessor
// delay task process
long remainTime = DateUtils.getRemainTime(taskExecutionContext.getFirstSubmitTime(),
taskExecutionContext.getDelayTime() * 60L);
if (remainTime > 0) {
logger.info("Current taskInstance is choose delay execution, delay time: {}s", remainTime);
taskExecutionContext.setCurrentExecutionStatus(TaskExecutionStatus.DELAY_EXECUTION);
workerMessageSender.sendMessage(taskExecutionContext, workflowMasterAddress,
CommandType.TASK_EXECUTE_RESULT);
发现delay time是这么计算的，但是查看task提交的params，delay time = 0 ，为啥还是会有 延迟614秒呢？
继续深入查看 DateUtils.getRemainTime方法
public static long getRemainTime(Date baseTime, long intervalSeconds) {
if (baseTime == null) {
return 0;
long usedTime = (System.currentTimeMillis() - baseTime.getTime()) / 1000;
return intervalSeconds - usedTime;
原来是系统时间问题，系统时间落后了十分钟，但是baseTime取的是正常时间（是取的master servrer 还是浏览器所在电脑终端的时间?），锁按上述方法计算下来，反而延迟了十分钟。晕
那就同步下时间服务器吧
/usr/bin/sudo /usr/sbin/ntpdate ip
同时设置一个crontab任务，每个月同步一次
############### 每月底最后一个工作日同步一次 时间服务器
0 0 28-31 * * [ `date -d tomorrow +\%e` -eq 1 ] && /usr/bin/sudo /usr/sbin/ntpdate 132.151.46.142 > /data/logs/ntpdate/ntpdate.log 2>&1
