Résumé des problèmes courants liés à l'utilisation d'Apache DolphinScheduler (mise à jour continue)

La description

Les problèmes courants dans l'article sont détectés pendant l'utilisation. Si l'article ne présente pas le problème que vous avez rencontré, veuillez soumettre un problème sur github.

Adresse du site officiel

problème github 地址

Précautions d'emploi

Package d'installation et répertoire d'installation
	安装包:是下载的的源文件,只有在安装时候才会用到,相安装好调度可以删除该目录。
	安装目录:运行install.sh后调度安装的目录,对调度管理都在安装目录下操作,比如 启停服务,、配置、查看日志等等。
	官网文档中的描述如下(配置在install.sh中),**记住**任何操作都在安装目录下操作。
 #将DS安装到哪个目录,如: /opt/soft/dolphinscheduler,不同于现在的目录
  installPath="/opt/soft/dolphinscheduler"
Répertoire de la vue du journal

En supposant que la configuration d'installation est installPath = "/ opt / soft / dolphinscheduler" lors de la planification de l'installation, le répertoire des journaux se trouve sous
/ opt / soft / dolphinscheduler / logs

Afficher le journal du travailleur
tail -f /opt/soft/dolphinscheduler/logs/dolphinscheduler-worker.log

Vérifiez le journal principal
tail -f /opt/soft/dolphinscheduler/logs/dolphinscheduler-master.log

Afficher le journal de l'API

tail -f /opt/soft/dolphinscheduler/logs/dolphinscheduler-api-server.log

Afficher le journal des alertes

tail -f /opt/soft/dolphinscheduler/logs/dolphinscheduler-alert.log

Afficher le journal de journalisation du service de journalisation

tail -f /opt/soft/dolphinscheduler/logs/dolphinscheduler-logger-server-huaweiyun.out

huaweiyun est le nom d'hôte, modifiez-le en votre local

Problèmes courants de l'environnement de développement

Le port de démarrage de l'API est 8080 et non 12345

Dans l'environnement initial, la configuration par défaut de l'API est 12345, la
solution consiste à
modifier la configuration en cours et à ajouter la configuration suivante

-Dserver-api-server -Dspring.profiles.active=api

Insérez la description de l'image ici

Impossible de trouver le pilote mysql

Étant donné que DolphinScheduler utilise postgresql par défaut, la dépendance de pilote mysql n'est pas introduite par défaut. Besoin de modifier manuellement le pom.

Solution:
recherchez pom.xml dans le répertoire racine

<dependency>
	<groupId>mysql</groupId>
	<artifactId>mysql-connector-java</artifactId>
	<version>${mysql.connector.version}</version>
	<scope>test</scope>
</dependency>

Supprimez <scope> test </ scope> et c'est ok

Insérez la description de l'image ici

Réimportez les dépendances maven.

L'échec d'exécution du travailleur signale un pointeur nul NPE

Insérez la description de l'image ici

Solution:
ajoutez les paramètres suivants dans les options de WorkServer vm

-Dspring.profiles.active = worker -Dlogging.config = "dolphinscheduler-server / src / main / resources / logback-worker.xml"

Insérez la description de l'image ici
Si le fichier est introuvable, supprimez les guillemets

-Dspring.profiles.active = travailleur -Dlogging.config = dolphinscheduler-server / src / main / resources / logback-worker.xml

Questions fréquemment posées sur la planification du déploiement

source d'erreur de déploiement ubuntu: introuvable

Insérez la description de l'image ici

Solution

Vous pouvez Baidu google mots-clés ubuntu source: non trouvé Il existe une solution

Erreur 404 lors de l'accès au service API

Insérez la description de l'image ici

Solution

Le nom du projet est absent de la demande ci-dessus et l'adresse complète est http: // ip: 12345 / dolphinscheduler /

Port par défaut de l'API 12235

Foire aux questions sur la planification

La connexion initiale au système a échoué

Généralement, cette erreur est le mauvais mot de passe. Le mot de passe initial pour la planification est le suivant, faites attention à la copie sans espaces.
Compte: admin
Mot de passe: dolphinscheduler123

La page de surveillance Master Worker page a été chargée dur ou il n'y a pas de données dans la requête

Grâce à la commande jps, vous pouvez voir les processus WorkerServer et MasterServer. Il peut y avoir une raison pour laquelle zk est en panne .
Insérez la description de l'image ici

Solution

Vérifiez si zk est démarré. S'il n'est pas démarré, démarrez le service zk. Ensuite, surveillez la page pour voir le statut de Master Worker

Le workflow s'exécute manuellement, mais il n'y a pas de données sur la page d'instance de tâche

Plusieurs facteurs expliquent ce problème. Supposons que zk et worker master soient démarrés avec succès.
En vérifiant les journaux des nœuds de calcul , nous constatons qu'il y a un chargement de journal ou que availablePhysicalMemorySize (G) est trop élevé. Le problème est le même que le La charge du problème suivant ou availablePhysicalMemorySize (G) est trop élevé . Reportez-vous au problème pour des solutions.

L'état de l'instance de tâche est soumis avec succès, mais il ne s'exécute jamais

Il existe de nombreux facteurs à ce problème. La première analyse de la situation actuelle est que le fichier journal de l'ouvrier dolphinscheduler-worker.log a imprimé les tâches de consommation de journal suivantes: [], il reste encore 1 tâches à exécuter, le nombre des tâches n'a pas diminué . Dans ce cas, l'adresse IP de la configuration de groupe de travailleurs associée à la tâche peut être incompatible avec l'adresse IP du service de travail. La tâche ne peut pas être exécutée.

Insérez la description de l'image ici

Solution:

Accédez à Security Center-> Worker branch management et modifiez l'adresse IP du groupe pour qu'elle corresponde à l'adresse IP du service Worker.
** Style audacieux **

Le téléchargement du fichier a échoué

En supposant que les services de stockage de fichiers prérequis ont été configurés, le téléchargement présente le problème suivant Nginx: 413 Request Entity Too Large. La raison est la limite de fichiers de téléchargement Nginx.
Insérez la description de l'image ici

Solution:

Modifiez /etc/nginx/nginx.conf. Augmentez la taille limite du fichier d'importation et augmentez la taille limite du fichier d'importation nginx dans la section http {}

client_max_body_size 200M

Redémarrez ngnix

ps: Si la description n'est pas détaillée, vous pouvez Baidu mot-clé Google 413 nginx

La requête SQL a réussi, mais l'instance de tâche a échoué

Le journal des échecs est le suivant, car le résultat de la requête SQL sera envoyé par courrier électronique et l'erreur de journal est qu'aucun service de messagerie n'est configuré
Insérez la description de l'image ici
.

Configurez le fichier de configuration du service de messagerie comme conf / alert.properties

L'exemple de configuration est le suivant, configuration de la boîte aux lettres 163. Pour
Insérez la description de l'image ici
plus de détails sur la configuration de la boîte aux lettres, veuillez consulter cet article

L'exécution de la tâche d'insertion de données SQL a échoué

[ERROR] 2020-06-05 10:20:07.756  - [taskAppId=TASK-9-493-494]:[336] - Can not issue data manipulation statements with executeQuery().
java.sql.SQLException: Can not issue data manipulation statements with executeQuery().
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1084)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:973)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:918)
	at com.mysql.jdbc.StatementImpl.checkForDml(StatementImpl.java:501)
	at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2150)
	at org.apache.dolphinscheduler.server.worker.task.sql.SqlTask.executeFuncAndSql(SqlTask.java:295)
	at org.apache.dolphinscheduler.server.worker.task.sql.SqlTask.handle(SqlTask.java:176)
	at org.apache.dolphinscheduler.server.worker.runner.TaskScheduleThread.run(TaskScheduleThread.java:142)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Solution:

Cette erreur s'explique par le fait que le type SQL est une exécution sans requête de la requête. La solution consiste à mettre à jour la tâche et à changer le type SQL en non-requête
Insérez la description de l'image ici

load ou availablePhysicalMemorySize (G) est trop élevé

Le journal d'arrière-plan du travailleur affiche toujours le journal suivant, car la mémoire du serveur ou le processeur ne sont pas suffisants (car la taille du tas par défaut est de 1G pour le démarrage planifié, si les 5 services sont démarrés, il consommera 5G de mémoire). Il s'agit du mécanisme d'autoprotection du travailleur. Il n'acceptera pas de nouvelles tâches. Il continuera d'accepter de nouvelles tâches lorsque la tâche en cours sera terminée ou que l'UC et la mémoire seront excédentaires.
Insérez la description de l'image ici

Solution

1 Si d'autres programmes sont en cours d'exécution (grande consommation de mémoire), vous pouvez attendre l'achèvement des autres tâches, puis observer si le travailleur dispose de journaux de capacité insuffisante.

2 Si vous êtes un tyran local, développez directement la mémoire

3 Si la mémoire de la machine physique n'est pas sans 5G, il existe deux façons de la gérer

  • Vous pouvez d'abord désactiver certains services, tels que l'alerte de mise à mort, l'enregistreur, etc. directement.
  • Vous pouvez ajuster les paramètres de démarrage, modifier le fichier de configuration bin / dolphinscheduler-daemon.sh, modifier la valeur -Xms pour qu'elle soit plus petite
export DOLPHINSCHEDULER_OPTS="-server -Xmx16g -Xms1g -Xss512k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70"

Référence source

L'état de surveillance du gardien de zoo est anormal

zk démarre normalement et Master Worker démarre normalement. Mais l'état d'auto-vérification du nœud zk est anormal, ce qui est dû à l'échec de l'obtention du FourLetterWord de zk

Insérez la description de l'image ici
Solution

Exécutez d'abord la commande, localhost est l'adresse du service

 echo ruok|nc localhost 2181

Si l'invite suivante apparaît, vous devez modifier la configuration de la configuration zoo.cfg

ruok is not executed because it is not in the whitelist.

Ajoutez la configuration suivante dans zoo.cfg

  4lw.commands.whitelist=*

Redémarrez zk

S'il n'y a pas de commande nc, vous devez d'abord installer yum install nc

Référence source

Échec de la création du client

Pour créer un client, vous devez utiliser HDF et des erreurs générales se produisent lors de l'utilisation de HDFS.
Les erreurs possibles incluent si hdfs est configuré, l'opération hdfs n'est pas autorisée, etc.

Par exemple, ce qui suit n'est pas une invite d'autorisation
Insérez la description de l'image ici

Solution

Lorsque vous rencontrez ce problème, commencez par consulter le journal de l'API et effectuez les modifications en fonction des invites d'erreur du journal.
Quoi qu'il en soit, assurez-vous d'abord que votre HDFS a été configuré . (Actuellement, le courant principal est de type hdfs, d'autres types n'ont pas été essayés)

ps: reportez-vous à ce problème pour la modification du fichier de configuration hdfs

Le maître et le travailleur s'arrêtent anormalement

la raison

Le maître et le travailleur doivent signaler le battement de cœur au gardien de zoo. Si le battement de cœur n'est pas signalé dans le délai spécifié, le maître et le travailleur s'arrêteront automatiquement et le
journal suivant apparaîtra

[INFO] 2020-04-30 06:48:28.032 org.apache.dolphinscheduler.server.master.MasterServer:[180] - master server is stopping ..., cause : i was judged to death, release resources and stop myself
[INFO] 2020-04-30 06:48:29.425 org.apache.dolphinscheduler.server.master.runner.MasterSchedulerThread:[143] - master server stopped...
[INFO] 2020-04-30 06:48:31.033 org.apache.dolphinscheduler.server.master.MasterServer:[197] - heartbeat service stopped

Donc, si le gardien de zoo perd la connexion (raccroche), le maître et le travailleur raccrochent également.

Solution

1 Assurez-vous que le service de gardien de zoo est accessible normalement.2
Vous pouvez modifier la configuration du délai d'expiration du gardien de zoo.
Dans la version 1.2, le délai est de 300 ms. Vous pouvez changer le
fichier de configuration en conf / zookeeper.properties et le modifier en fonction de la situation réelle.

Se référer au problème

Troncature des données: données trop longues pour la colonne "app_link" à la ligne 1

La raison en est que le champ app_link est trop long

Solution

1) Avant la version 1.3, la longueur de t_ds_task_instance.app_link est de 255. Vous pouvez modifier la longueur du champ, script officiel

ALTER TABLE t_ds_task_instance ALTER COLUMN app_link type text

2) Vous pouvez mettre à niveau vers la dernière version, le problème a été résolu,

Se référer au problème

Je suppose que tu aimes

Origine blog.csdn.net/samz5906/article/details/106434430
conseillé
Classement