Perth Hackfest October 2012/Asynchronous Backup System spec: Difference between revisions
From MoodleDocs
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Purpose == | == Purpose == | ||
The Moodle backup and restore system is a powerful and resource-intensive system. On large, busy sites, the active use of backup and restore can significantly impact successful operation by negatively impacting performance. Often times the necessary workflows of an organization using Moodle requires backup and restore being peformed at the same time as a peak user period (e.g. educational institution setting up a new session while previous session carrying out an exam period). | The Moodle backup and restore system is a powerful and resource-intensive system. On large, busy sites, the active use of backup and restore can significantly impact successful operation by negatively impacting performance. Often times the necessary workflows of an organization using Moodle requires backup and restore being peformed at the same time as a peak user period (e.g. educational institution setting up a new session while previous session carrying out an exam period). | ||
| Line 12: | Line 11: | ||
* Ability to monitor progress and notify completion and other status of operations. | * Ability to monitor progress and notify completion and other status of operations. | ||
* Ability to disable synchronous backup/restore (live) functions from specified users. | * Ability to disable synchronous backup/restore (live) functions from specified users. | ||
== Use Cases == | |||
== Design Ideas == | == Design Ideas == | ||
* Need a new cron system, if cron is to be used, so that more control over when and how long tasks can run. | * Need a new cron system, if cron is to be used, so that more control over when and how long tasks can run. | ||
** (Note: ELIS has an improved cron system that could be looked at that can break up long running tasks and allow scheduling) | ** (Note: ELIS has an improved cron system that could be looked at that can break up long running tasks and allow scheduling) | ||
* Queueing system with dispatch intelligence (multiple runs, single runs) | |||
** Ability to see a schedule list of what is due to run and progress bar, start/end times, email completion success/failure. | |||
* Could use event API | |||
* Use capabilities to control who can access backup types (synchronous, ansynchronous, etc.) | |||
* Create a backup/restore plug-in system to build the different types of backup processing | |||
** Build the first asynchronous backup processor as a plug-in | |||
Revision as of 14:25, 13 November 2012
Purpose
The Moodle backup and restore system is a powerful and resource-intensive system. On large, busy sites, the active use of backup and restore can significantly impact successful operation by negatively impacting performance. Often times the necessary workflows of an organization using Moodle requires backup and restore being peformed at the same time as a peak user period (e.g. educational institution setting up a new session while previous session carrying out an exam period).
Also, very large backup operations can time-out in the web environment, preventing operations from successfully completing.
As a solution, backup and restore could be redesigned in a way that would allow for these operations to be scheduled and handled asynchronously rather than synchronously on-demand. This system would also allow for the prevention of synchronous backups as specified by the site administrators.
Requirements
- Ability to run the backup/restore operations in a "managed" (scheduled and queued) way to reduce impact on Moodle performance.
- Ability to separate the backup/restore operations from synchronous operation on the Moodle server.
- Ability to monitor progress and notify completion and other status of operations.
- Ability to disable synchronous backup/restore (live) functions from specified users.
Use Cases
Design Ideas
- Need a new cron system, if cron is to be used, so that more control over when and how long tasks can run.
- (Note: ELIS has an improved cron system that could be looked at that can break up long running tasks and allow scheduling)
- Queueing system with dispatch intelligence (multiple runs, single runs)
- Ability to see a schedule list of what is due to run and progress bar, start/end times, email completion success/failure.
- Could use event API
- Use capabilities to control who can access backup types (synchronous, ansynchronous, etc.)
- Create a backup/restore plug-in system to build the different types of backup processing
- Build the first asynchronous backup processor as a plug-in
