Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: upgrade.md

You should check before you upgrade, because some incompatible change may break your current function. To prevent data loss by some miss-operation, it is recommended to back up data before upgrading. The backup way according to your environment. Download the latest binary distribute package from and then put it in the different directory where current service running. And all below command is running in this directory. Stop all services of dolphinscheduler according to your deployment method. If you deploy your dolphinscheduler according to , you can stop all services by command `sh ./script/stop-all.sh`. Set the following environment variables ({user} and {password} are changed to your database username and password), and then run the upgrade script. Using MySQL as an example, change the value if you use other databases. Please manually download the jar package and add it to the `./tools/libs` directory, then export the following environment variables ```shell export DATABASE=${DATABASE:-mysql} export SPRINGPROFILESACTIVE=${DATABASE} export SPRINGDATASOURCEURL="jdbc:mysql://127.0.0.1:3306/dolphinscheduler?useUnicode=true&characterEncoding=UTF-8&useSSL=false" export SPRINGDATASOURCEUSERNAME={user} export SPRINGDATASOURCEPASSWORD={password} ``` Execute database upgrade script: `sh ./tools/bin/upgrade-schema.sh` After refactoring resource center in version 3.2.0, original resources become unmanaged. You can assign a target tenant and execute one-time migration script. All resources will be migrated to directory `.migrate` of target tenant. Assign an existed target tenant `abc`, the base resource path is `/dolphinscheduler/abc/`. Execute script: `sh ./tools/bin/migrate-resource.sh abc`. Execution result: The original file resource `a/b.sh` migrates to `/dolphinscheduler/abc/resources/.migrate/a/b.sh`. The original UDF resource `x/y.jar` migrates to `/dolphinscheduler/abc/udf/.migrate/x/y.jar`. Update UDF function's bound resource info. If you deploy with Pseudo-Cluster deployment, change it according to section "Modify Configuration". If you deploy with Cluster deployment, change it according to section "Modify Configuration". And them run command `sh ./bin/start-all.sh` to start all services. The architecture of worker group is different between version before version 1.3.1 until version 2.0.0 Before version 1.3.1(include itself) worker group can be created through UI interface. Since version 1.3.1 and before version 2.0.0, worker group can be created by modifying the worker configuration. Check the backup database, search records in table `tdsworker_group` table and mainly focus on three columns: `id, name and IP`. | id | name | ip_list | |:|:--:|-:| | 1 | service1 | 192.168.xx.10 | | 2 | service2 | 192.168.xx.11,192.168.xx.12 | Modify worker related configuration in `bin/env/install_env.sh`. Assume below are the machine worker service to be deployed: | hostname | ip | |:|:-:| | ds1 | 192.168.xx.10 | | ds2 | 192.168.xx.11 | | ds3 | 192.168.xx.12 | To keep worker group config consistent with the previous version, we need to modify workers configuration as below: ```shell workers="ds1:service1,ds2:service2,ds3:service2" ``` Workers in 1.3.1 can only belong to one worker group, but after version 1.3.2 and before version 2.0.0 worker support more than one worker group. ```sh workers="ds1:service1,ds1:service2" ``` After version 2.0.0, include itself, we are recovery function create worker group from web UI.