Apache DolphinScheduler 1.3.4升級至3.1.2版本過程中的踩坑記錄

因為在工作中需要推動Apache DolphinScheduler的升級，經過預研，從1.3.4到3.1.2有的體驗了很大的提升，在效能和功能性有了很多的改善，推薦升級。

檢視官方的升級文件，可知有提供升級指令碼，如果只是跨小版本的更新那麼只用執行指令碼就好了，但跨多個大版本升級時依然容易出現各種問題，特此總結。

舊版本：1.3.4
新版本：3.1.2

問題合集

1.資源中心報錯

升級完成後使用資源中心報錯 IllegalArgumentException: Failed to specify server's Kerberos principal name

資源中心使用的HDFS，開啟了kerberos認證

解決方法：

編輯 dolphinscheduler/api-server/conf/hdfs-site.xml 新增以下內容

<property>
    <name>dfs.namenode.kerberos.principal.pattern</name>
    <value>*</value>
</property>

2.任務例項日誌丟失

升級完成後檢視任務例項的日誌，報錯未找到日誌,檢視報錯資訊，檢查新版本的目錄結構和表裡的日誌路徑，發現原因是新版本的日誌路徑有變更。

升級前的日誌路徑在 /logs/ 下。

升級後的日誌路徑在 /worker-server/logs/ 下。

因此需要修改這裡的目錄

解決方法：
執行SQL修改日誌路徑

update t_ds_task_instance set log_path=replace(log_path,'/logs/','/worker-server/logs/');

然後將原日誌檔案copy到新的日誌路徑

cp -r {舊版本dolphinscheduler目錄}/logs/[1-9]* {新版本dolphinscheduler目錄}/worker-server/logs/*

3.升級完建立工作流報錯

檢視報錯資訊，原因是 t_ds_process_definition_log 和 t_ds_process_definition 主鍵的初始值不一致，那麼修改成一致的就好了！

解決方法：
執行SQL

# 查出主鍵自增值
select AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'dolphinscheduler' AND TABLE_NAME = 't_ds_process_definition' limit 1
# 將上面SQL的執行結果填寫到下方引數處執行
alter table dolphinscheduler_bak1.t_ds_process_definition_log auto_increment = {max_id};

4.升級後任務例項列表為空

檢查查詢的SQL

在 dolphinscheduler-dao/src/main/resources/org/apache/dolphinscheduler/dao/mapper/TaskInstanceMapper.xml 檔案裡，select id="queryTaskInstanceListPaging"的SQL

       	select
        <include refid="baseSqlV2">
            <property name="alias" value="instance"/>
        </include>
        ,
        process.name as process_instance_name
        from t_ds_task_instance instance
        left join t_ds_task_definition_log define on define.code=instance.task_code and define.version=instance.task_definition_version
        left join t_ds_process_instance process on process.id=instance.process_instance_id
        where define.project_code = #{projectCode}
        <if test="startTime != null">
            and instance.start_time <![CDATA[ >=]]> #{startTime}
        </if>
		......省略多餘部分

查詢任務例項列表的SQL會關聯 t_ds_task_definition_log 表，經檢查發現是 define.code=instance.task_code 這一句關聯不上。

結合下面的查詢條件 define.project_code = #{projectCode} 可知，關聯 t_ds_task_definition_log 主要是為了過濾 projectCode，那麼來修改下這個SQL:

解決方法：

    	select
        <include refid="baseSqlV2">
            <property name="alias" value="instance"/>
        </include>
        ,
        process.name as process_instance_name
        from t_ds_task_instance instance
--         left join t_ds_task_definition_log define 
--				on define.code=instance.task_code and 
--					define.version=instance.task_definition_version
        join t_ds_process_instance process
        	on process.id=instance.process_instance_id
        join t_ds_process_definition define
        	on define.code=process.process_definition_code
        where define.project_code = #{projectCode}
        <if test="startTime != null">
            and instance.start_time <![CDATA[ >=]]> #{startTime}
        </if>
		......省略多餘部分

直接用 t_ds_process_definition 關聯，也有 project_code 欄位可以用來關聯過濾，這裡修改後就能查出資料了。

5.執行升級指令碼的過程中報空指標

（1）分析日誌，定位到 UpgradeDao.java 517行

檢視程式碼

513 if (TASK_TYPE_SUB_PROCESS.equals(taskType)) {
514                       JsonNode jsonNodeDefinitionId = param.get("processDefinitionId");
515                       if (jsonNodeDefinitionId != null) {
516                           param.put("processDefinitionCode",
517                                  processDefinitionMap.get(jsonNodeDefinitionId.asInt()).getCode());
518                            param.remove("processDefinitionId");
519                        }
520                    }

很明顯是 processDefinitionMap.get(jsonNodeDefinitionId.asInt()) 返回了null,加個null判斷，如果返回null直接跳過，並將相關資訊列印出來，升級結束後可以根據日誌核對。

解決方法：

修改後:

if (jsonNodeDefinitionId != null) {
    if (processDefinitionMap.get(jsonNodeDefinitionId.asInt()) != null) {
        param.put("processDefinitionCode",processDefinitionMap.get(jsonNodeDefinitionId.asInt()).getCode());
        param.remove("processDefinitionId");
    } else {
        logger.error("*******************error");
        logger.error("*******************param:" + param);
        logger.error("*******************jsonNodeDefinitionId:" + jsonNodeDefinitionId);
    }
}

(2)分析日誌，定位到 UpgradeDao.java 675行

檢視程式碼

669 if (mapEntry.isPresent()) {
670                            Map.Entry<Long, Map<String, Long>> processCodeTaskNameCodeEntry = mapEntry.get();
671                            dependItem.put("definitionCode", processCodeTaskNameCodeEntry.getKey());
672                            String depTasks = dependItem.get("depTasks").asText();
673                            long taskCode =
674                                    "ALL".equals(depTasks) || processCodeTaskNameCodeEntry.getValue() == null ? 0L
675                                            : processCodeTaskNameCodeEntry.getValue().get(depTasks);
676                            dependItem.put("depTaskCode", taskCode);
677                        }

很明顯是 processCodeTaskNameCodeEntry.getValue().get(depTasks) 返回了null，修改下邏輯，不為null才賦值並列印相關日誌。

解決方法：

修改後:

long taskCode =0;
                            if (processCodeTaskNameCodeEntry.getValue() != null
                                    &&processCodeTaskNameCodeEntry.getValue().get(depTasks)!=null){
                                taskCode =processCodeTaskNameCodeEntry.getValue().get(depTasks);
                            }else{
                                logger.error("******************** depTasks:"+depTasks);
                                logger.error("******************** taskCode not in "+JSONUtils.toJsonString(processCodeTaskNameCodeEntry));
                            }
                            dependItem.put("depTaskCode", taskCode);

6.接入LDAP後登陸失敗，不知道Email欄位名

可在 api-server/conf/application.yaml 配置接入LDAP

security:
  authentication:
    # Authentication types (supported types: PASSWORD,LDAP)
    type: LDAP
    # IF you set type `LDAP`, below config will be effective
    ldap:
      # ldap server config
      urls: xxx
      base-dn: xxx
      username: xxx
      password: xxx
      user:
        # admin userId when you use LDAP login
        admin: xxx
        identity-attribute: xxx
        email-attribute: xxx
        # action when ldap user is not exist (supported types: CREATE,DENY)
        not-exist-action: CREATE

要成功接入LDAP至少需要urls,base-dn,username,password,identity和email正確填寫，不知道email欄位名可以按下面的方式處理，email先空著

啟動服務後用LDAP使用者登入

解決辦法：
LDAP 認證的程式碼在 dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/security/impl/ldap/LdapService.java 的 ldapLogin()

ctx = new InitialLdapContext(searchEnv, null);
SearchControls sc = new SearchControls();
sc.setReturningAttributes(new String[]{ldapEmailAttribute});
sc.setSearchScope(SearchControls.SUBTREE_SCOPE);
EqualsFilter filter = new EqualsFilter(ldapUserIdentifyingAttribute, userId);
NamingEnumeration<SearchResult> results = ctx.search(ldapBaseDn, filter.toString(), sc);
if (results.hasMore()) {
    // get the users DN (distinguishedName) from the result
    SearchResult result = results.next();
    NamingEnumeration<? extends Attribute> attrs = result.getAttributes().getAll();
    while (attrs.hasMore()) {
        // Open another connection to the LDAP server with the found DN and the password
        searchEnv.put(Context.SECURITY_PRINCIPAL, result.getNameInNamespace());
        searchEnv.put(Context.SECURITY_CREDENTIALS, userPwd);
        try {
            new InitialDirContext(searchEnv);
        } catch (Exception e) {
            logger.warn("invalid ldap credentials or ldap search error", e);
            return null;
        }
        Attribute attr = attrs.next();
        if (attr.getID().equals(ldapEmailAttribute)) {
            return (String) attr.get();
        }
    }
}

第三行會根據填的欄位過濾，先註釋第三行

// sc.setReturningAttributes(new String[]{ldapEmailAttribute});

重新執行後第10行會返回全部欄位

NamingEnumeration<? extends Attribute> attrs = result.getAttributes().getAll();

透過列印或除錯在裡面找到email欄位填到配置檔案裡，再還原上面註釋的程式碼，重啟服務後即可正常接入LDAP登入。

7.管理員給普通使用者授權資原始檔不生效

經多次測試,發現普通使用者只能看到所屬使用者為自己的資原始檔，管理員授權後依然無法檢視資原始檔

解決辦法:

檔案 dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/permission/ResourcePermissionCheckServiceImpl.java 的 listAuthorizedResource() 方法,將 return 的集合修改為 relationResources

@Override
        public Set<Integer> listAuthorizedResource(int userId, Logger logger) {
            List<Resource> relationResources;
            if (userId == 0) {
                relationResources = new ArrayList<>();
            } else {
                // query resource relation
                List<Integer> resIds = resourceUserMapper.queryResourcesIdListByUserIdAndPerm(userId, 0);
                relationResources = CollectionUtils.isEmpty(resIds) ? new ArrayList<>() : resourceMapper.queryResourceListById(resIds);
            }
            List<Resource> ownResourceList = resourceMapper.queryResourceListAuthored(userId, -1);
            relationResources.addAll(ownResourceList);
            return relationResources.stream().map(Resource::getId).collect(toSet()); // 解決資原始檔授權無效的問題
//            return ownResourceList.stream().map(Resource::getId).collect(toSet());
        }

檢查新版本的 Change log ，發現在3.1.3版本修復了這個bug

https://github.com/apache/dolphinscheduler/pull/13318

8.kerberos過期的問題

因為kerberos配置了票據過期時間，一段時間後資源中心的hdfs資源將無法訪問，最好的解決辦法是新增定時更新憑證的相關邏輯。

解決辦法:

在檔案 dolphinscheduler-service/src/main/java/org/apache/dolphinscheduler/service/utils/CommonUtils.java 新增方法

 /**
     * * 定時更新憑證
     */
    private static void startCheckKeytabTgtAndReloginJob() {
        // 每天迴圈，定時更新憑證
        Executors.newScheduledThreadPool(1).scheduleWithFixedDelay(() -> {
            try {
                UserGroupInformation.getLoginUser().checkTGTAndReloginFromKeytab();
                logger.warn("Check Kerberos Tgt And Relogin From Keytab Finish.");
            } catch (IOException e) {
                logger.error("Check Kerberos Tgt And Relogin From Keytab Error", e);
            }
        }, 0, 1, TimeUnit.DAYS);
        logger.info("Start Check Keytab TGT And Relogin Job Success.");
    }

然後在該檔案的 loadKerberosConf 方法返回 true 前呼叫:

public static boolean loadKerberosConf(String javaSecurityKrb5Conf, String loginUserKeytabUsername,
                                           String loginUserKeytabPath, Configuration configuration) throws IOException {
        if (CommonUtils.getKerberosStartupState()) {
            System.setProperty(Constants.JAVA_SECURITY_KRB5_CONF, StringUtils.defaultIfBlank(javaSecurityKrb5Conf,
                    PropertyUtils.getString(Constants.JAVA_SECURITY_KRB5_CONF_PATH)));
            configuration.set(Constants.HADOOP_SECURITY_AUTHENTICATION, Constants.KERBEROS);
            UserGroupInformation.setConfiguration(configuration);
            UserGroupInformation.loginUserFromKeytab(
                    StringUtils.defaultIfBlank(loginUserKeytabUsername,
                            PropertyUtils.getString(Constants.LOGIN_USER_KEY_TAB_USERNAME)),
                    StringUtils.defaultIfBlank(loginUserKeytabPath,
                            PropertyUtils.getString(Constants.LOGIN_USER_KEY_TAB_PATH)));
            startCheckKeytabTgtAndReloginJob();  // 此處呼叫
            return true;
        }
        return false;
    }

這篇文章主要是記錄升級過程中遇到的問題，希望能夠對大家有所幫助！

本文由 白鯨開源 提供釋出支援！