deploy-scheduler errand fails when upgrading Scheduler tile to v2.0.0

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

You upgraded Scheduler to version 2.0.0 with deploy-scheduler errand turned on and this fails with the scheduler-new app not able to start

+ cf push scheduler-new -f /var/vcap/jobs/deploy-scheduler/scheduler-manifest.yml -i 1 -n scheduler-new -d system.XXXXX -s cflinuxfs4 ...
Start unsuccessful

To get more details as to why the scheduler-new was not able to start.
 

cf target -o system -s scheduler
cf logs scheduler-new --recent 

From scheduler-new app logs we get more error:
 

 2023-11-13T11:03:21.55+1100 [APP/PROC/WEB/0] OUT Caused by: org.flywaydb.core.api.FlywayException: Found non-empty schema(s) `scheduler` but no schema history table. Use baseline() or set baselineOnMigrate to true to initialize the schema history table.

Environment

Product Version: 2.7

Resolution

You are likely to encounter this error if you installed/used Scheduler v1.2 or earlier before upgrading to v2.0.0. In v1.2 and earlier this would create the table name schema_version. Scheduler 2.0 requires this table to renamed to flyway_schema_history. If Scheduler 2.0 was not able to find flyway_schema_history this error is thrown

As of date of writing Nov 2023, The latest version of Scheduler is 2.0.0. Currently we will work on releasing a v2.0.1 in early December that patches this issue.

Here is a workaround if you cannot upgrade to v2.0.1:

If using MySQL tile:

1. Use cf cli to locate scheduler space

   cf target -o system -s scheduler

2. Getting the database guid

   cf services scheduler-mysql --guid

3. Using bosh cli identify service instance deployment plus guid from Step 2 and ssh into one of the MySQL nodes

   bosh -d service-instance-<guid> ssh mysql/0 

4. using mysql cli client connect

   sudo mysql --defaults-file=/var/vcap/jobs/mysql/config/mylogin.cnf 

5. Locate where schema_version table 

   select table_schema, table_name from information_schema.tables where table_name='schema_version';

6. Once located target the database for this example table_schema returns service_instance_db

   use service_instance_db;

7. Copy the contents of schema_version to new table flyway_schema_history

   create table flyway_schema_history select * from schema_version;

8. Check if the contents are copied 

   select * from flyway_schema_history ;

9. Apply Change again with deploy-scheduler errand turned on
10. Once apply change has been successful drop schema_version table. This step is necessary so that when you upgrade or redeploy Scheduler it will not attempt to create the flyway_schema_history table and since it is existing it will fail with "Table flyway_schema_history already exists" error

    drop table schema_version;

If using external database for this example AWS MySQL RDS:

1. Either using cf cli or Apps Manager 

   cf target -o system -s scheduler
   

2. locate the database endpoint that the scheduler app is using

   cf env scheduler

3. Login into mysql instance - please check documentation on your external database on how you can login. Usually you need mysql client 

    mysql -h mysql–endpoint.rds.amazonaws.com -P 3306 -u mymasteruser -p 

4. Locate where schema_version table 

   select table_schema, table_name from information_schema.tables where table_name='schema_version';

   
    
5. Once located target the database for this example table_schema returns scheduler

   use scheduler;

6. Copy the contents of schema_version to new table flyway_schema_history

   create table flyway_schema_history select * from schema_version;

7. Check if the contents are copied 

   select * from flyway_schema_history ;

8. Apply Change again with deploy-scheduler errand turned on
9. Once apply change has been successful drop schema_version table. This step is necessary so that when you upgrade or redeploy Scheduler it will not attempt to create the flyway_schema_history table and since it is existing it will fail with "Table flyway_schema_history already exists" error

   drop table schema_version;