Multiple Autorun instances sharing single db

Oct 8, 2010 at 12:50 PM

Hi,

Thanks for the great product, it is really usefull.

I would like to ask if your are planing to add support for a scenario where multiple autorun servers on different computers (or maybe on the same computer) share a single configuration database.

It would be an important feature when deploying this product on enterprise systems where there is a single enterprise sql server installation instead of sqlexpress on every computer. 

Coordinator
Oct 11, 2010 at 6:32 AM

Good morning,

I've never been asked this before: this is a quite interresting consideration.

With the current version, you could already work with a standard SQL Server instead of a SQL Express.

  • Attach the autorun database (autorun.mdf) to your SQL Server
  • In the configuration file (autorun.exe.config), change the connection string and set the server, user id and password with correct values
  • (Re-)Start autorun

The current limitation (I did not think about earlier) is that the system is not designed to share the same database with many instances of Autorun yet: today, all instances sharing the same DB will do exactly the same tasks at the same time (at least they will try to...). The current workaround should consist in creating as many databases as instances of autorun.

I known how to adapt the database in order to serve many instances of Autorun: I will try to integrate it in the next release.

Best regards
Serge

Oct 13, 2011 at 5:55 PM

I am looking for a solution that can scale across multiple servers to avoid single point of failure. If there are 10 application servers, I want all servers to have an instance of the autorun service started but for the scheduled job to only be triggered once (by any of the started autorun services).

Is Autorun capable of this configuration?

Coordinator
Oct 21, 2011 at 1:23 PM

Hello. Not sure to understand.

1°) If each instance of Autorun runs its own set of tasks, then you'd better use one DB per instance

2°) if you mean a kind of cluster active/active where the quickest instance runs a tasks and informs the other instance not to run that task again: this is not possible --> The daily execution planned is not stored in the database but is built in memory. Storing the execution plan in the DB could make that possible, bu you will loose some performances (lot of queries to the DB) and there is a big risk of concurrency (risk nearly 100% if all your servers use an SNTP server, thus have the same time)

Best regards
Serge

Oct 21, 2011 at 1:45 PM
Thanks for the update. My question was regarding availability using AutoRun for a specific application with a cluster of application servers.

After some internal discussion, we are considering using AutoRun as our enterprise task scheduler. The plan would be to deploy AutoRun on a single ESX VM to realize the high availability I was getting at with my question.

Thanks, Sean


On Fri, Oct 21, 2011 at 9:23 AM, sbollaerts <notifications@codeplex.com> wrote:

From: sbollaerts

Hello. Not sure to understand.

1°) If each instance of Autorun runs its own set of tasks, then you'd better use one DB per instance

2°) if you mean a kind of cluster active/active where the quickest instance runs a tasks and informs the other instance not to run that task again: this is not possible --> The daily execution planned is not stored in the database but is built in memory. Storing the execution plan in the DB could make that possible, bu you will loose some performances (lot of queries to the DB) and there is a big risk of concurrency (risk nearly 100% if all your servers use an SNTP server, thus have the same time)

Best regards
Serge

Read the full discussion online.

To add a post to this discussion, reply to this email (autorun@discussions.codeplex.com)

To start a new discussion for this project, email autorun@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com