community
cancel
Showing results for 
Search instead for 
Did you mean: 

alteryx server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.
#SANTALYTICS

The highly anticipated Alteryx Community tradition is back! We hope you'll join us!

Learn More
We will be upgrading the Gallery to our 2019.4 release this Saturday, December 7th beginning at 9:00am MT. We expect the outage to take last approx. 2.5 hours.

Disable scheduler during Server upgrade

Meteor

Hi, 

 

We are planning to upgrade the Alteryx Server to 11.7. 

The plan is to upgrade the server and then let users test their workflows. 

In case the users are good with the results, we get the go ahead to execute the production workflows.

 

The issue is, once I upgrade the server, the server will automatically start executing the scheduled production workflows.

 

Is there a way to just disable the scheduler until we get the go ahead from the users?

OR

The only way is to delete all the scheduled workflows and manually reschedule them once we get a go ahead?

 

Thanks,

Poorab

Alteryx
Alteryx

@ppoorab1 There isn't any settings or functionality to disable just scheduler entirely on the server as the underlying functionality is used for all workflows run by the server. However, you can take a couple approaches to preventing or limiting scheduled jobs depending on your specific needs, configuration, and what version you are running currently. If you are on 11.0 or higher and using exclusively Gallery for scheduling a Curator can go in and disable the ability to schedule workflows. Then edit each scheduled workflow setting them to disabled. Once they are tested the Curator can then re-enable each schedule as needed and the ability for users to schedule workflows. I think this is the best option if it is available to you.

 

If you aren't on 11.0+ or if you are still scheduling workflows directly from Designer you can achieve a similar result by editing each schedule from within Designer and setting the frequency to Once. This will update the schedule so that the workflows will no longer run on a recurring basis. However, anyone with access to schedule in this manner would be able to edit the schedule to set it back to a recurring state or create new schedules. 

 

A final option would be to disable the worker(s) entirely. This can be done via the Alteryx System Settings by selecting Custom under Setup Type and unchecking the Enable Worker option. Disabling the workers will prevent the server from running any workflow at all. This would include scheduled workflows, user run workflows, workflows run via Gallery API request, and workflow validations when saving workflows to Gallery. Any workflows sent to the queue while the worker(s) are disabled will sit in queue until the worker(s) are re-enabled. This can lead to a very large backlog of pending tasks, and could make adequately testing the workflows difficult.

Meteor

Thanks @KevinP for all the options.

 

I am afraid unfortunately none of them would work for me.

We are on 10.5 currently with no Gallery implementation all the workflows are scheduled via controller token.

And with the upgrade to 11.7, we are planning to implement Gallery a week later. 

 

Here is my crude plan, please let me know if that would do the trick.

 

1. Take a backup of the current schedule using "alteryxservice emongodump"

2. Wipe out the entire schedule

3. Do the version upgrade to 11.7

4. Let the users test their workflows on the server (by using the controller token)

5. Get a go ahead from users.

6. Restore the schedule using "alteryxservice emongorestore"

 

The other question I have in mind is, will I end up with a large backlog of pending tasks?

 

Thanks,

Poorab 

 

 

Alteryx
Alteryx

@ppoorab1 Backing up the database first is an excellent idea, and would give you the opportunity to roll back to your current version. For information on backup best practices and procedures please refer to the Alteryx Server Backup & Recovery knowledge articles. Since none of the options presented are viable for you I would proceed is as follows:

 

  1. Backup MongoDB and configuration files (see backup KB above)
  2. Stop the AlteryxService
  3. Remove or rename MongoDB persistence folder (default: C:\ProgramData\Alteryx\Service\Persistence\MongoDB)
  4. Upgrade to 11.7
  5. Run through Alteryx System Setting to ensure no settings were lost
  6. Start the AlteryxService (will start automatically if you click finish and done in System Settings)
  7. Perform testing and get approval or denial from users.
  8. On Approval:
    1. Repeat steps 2-3
    2. Restore original backup
    3. Restart AlteryxService
    4. Test
  9. On Denial:
    1. Repeat steps 2-3
    2. Uninstall 11.7
    3. Re-install 10.5
    4. Restore original backup
    5. Restart AlteryxService
    6. Test

 

Keep in mind though that this is only viable if you are using MongoDB as your persistence layer. Since you are currently using server without Gallery it is possible that you are using SQLite instead. If this is the case you will have to start with a blank database in order to deploy Gallery as MongoDB is required for Gallery, and there isn't a migration tool to convert from SQLite to MongoDB. This does have the advantage of letting you test on a blank database without have to do repeated backup/restore processes. Just stop the service and backup the entire persistence folder (default: C:\ProgramData\Alteryx\Service\Persistence). Then reconfigure the service to use MongoDB, upgrade to 11.7, and test. If everything goes well your users would just need to re-upload their production workflows and re-schedule them once testing is complete.

Meteor

 

Thanks a ton @KevinP for such detailed steps.

I will test the steps on our Test Server and let you know how it goes.