dumper 0.2.2 → 0.3.0

Sign up to get free protection for your applications and to get access to all the features.
data/README.md CHANGED
@@ -9,9 +9,11 @@ Dumper is a backup management system that offers a whole new way to take daily b
9
9
  * Ruby 1.8.7 , Ruby 1.9.2 or later
10
10
  * Rails 3.0 or later
11
11
  * MySQL with ActiveRecord
12
- * MongoDB with mongo gem (including Mongoid 2.x)
12
+ * MongoDB with the mongo gem (including Mongoid 2.x)
13
+ * Redis with the redis gem **To take backups from Redis, you must run agent on the Redis host**
14
+ * Runs inside [thin](http://code.macournoyer.com/thin/), [unicorn](http://unicorn.bogomips.org/), [passenger](http://www.modrails.com/) or [resque](https://github.com/defunkt/resque) (mongrel and webrick are also supported for development)
13
15
 
14
- Support for PostgreSQL and Redis are coming soon.
16
+ Support for PostgreSQL is coming soon.
15
17
 
16
18
  ## Installation
17
19
 
@@ -27,14 +29,42 @@ then create `config/initializers/dumper.rb` and put the following line.
27
29
  Dumper::Agent.start(:app_key => 'YOUR_APP_KEY')
28
30
  ```
29
31
 
30
- or, if you want to conditionally start the agent, pass a block that evaluates to true/false to `#start_if` method.
32
+ That's it!
33
+
34
+ Now, start your server and go to the Dumper site.
35
+
36
+ You'll find your application is registered and ready to take backups.
37
+
38
+ ## How does it work?
39
+
40
+ In a Rails app server process, a new thread is created and periodically checks the Dumper API if a new backup job is scheduled.
41
+
42
+ When it finds a job, the agent won't run the job inside its own thread, but instead spawns a new process, then go back to sleep. That way, web requests won't be affected by the long-running backup task, and the task will continue to run even when the parent process is killed in the middle.
43
+
44
+ Dumper agent will try to run on every process by default. Which means, for instance, if you have 10 thin instances on production, the agent will run on those 10 instances. We designate the first agent that hits our API as primary, and the rest as secondary. In this case, 1 thin process becomes the primary and other 9 processes become secondaries. Only the primary is responsible for taking backup jobs, so it is guaranteed that there is no duplicate work on your servers. The primary polls our API with up to 1- to 10-minute interval, while the secondaries poll every hour. If you run fork-based servers like unicorn or passenger, however, the agent thread runs only on the master process, not on child processes.
45
+
46
+ We do this for fault tolerance. When something goes wrong and the primary dies, one of the secondaries will take over the primary status and continue to serve.
47
+
48
+ The bottom line is that the agent is designed to be extremely efficient in CPU, memory and bandwidth usage. It's almost impossible to detect any difference in performance with or without it.
49
+
50
+ ## Conditionally start the agent
51
+
52
+ As explained above, the Dumper agent will try to run on every process by default.
53
+
54
+ If you want to start the agent on a particular host, pass a block that evaluates to true or false to `start_if` method.
31
55
 
32
56
  ```ruby
33
- Dumper::Agent.start_if(:app_key => 'YOUR_APP_KEY') { Rails.env.production? && dumper_enabled_host? }
57
+ Dumper::Agent.start_if(:app_key => 'YOUR_APP_KEY') do
58
+ Rails.env.production? && dumper_enabled_host?
59
+ end
34
60
  ```
35
61
 
36
- That's it!
62
+ In particular, current Redis support is limited in that you must run the agent on the same host with Redis.
37
63
 
38
- Now, start your server and go to the Dumper site.
64
+ ```ruby
65
+ Dumper::Agent.start_if(:app_key => 'YOUR_APP_KEY') do
66
+ Socket.gethostname == 'redis.mydomain.com'
67
+ end
68
+ ```
39
69
 
40
- You'll find your application is registered and ready to take backups daily.
70
+ If you are using resque, it's a good idea to run it on the same host with Redis, and start the agent on the resque instance.
@@ -32,7 +32,7 @@ module Dumper
32
32
  end
33
33
 
34
34
  # Which dispatcher?
35
- [ :unicorn, :passenger, :thin, :mongrel, :webrick ].find do |name|
35
+ [ :unicorn, :passenger, :thin, :mongrel, :webrick, :resque ].find do |name|
36
36
  @dispatcher = send("#{name}?") ? name : nil
37
37
  end
38
38
  end
@@ -75,5 +75,9 @@ module Dumper
75
75
  # defined?(::WEBrick::VERSION)
76
76
  @rackup and @rackup.server.to_s.demodulize == 'WEBrick'
77
77
  end
78
+
79
+ def resque?
80
+ defined?(::Resque) && (ENV['QUEUES'] || ENV['QUEUE'])
81
+ end
78
82
  end
79
83
  end
@@ -1,3 +1,3 @@
1
1
  module Dumper
2
- VERSION = '0.2.2'
2
+ VERSION = '0.3.0'
3
3
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: dumper
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.2.2
4
+ version: 0.3.0
5
5
  prerelease:
6
6
  platform: ruby
7
7
  authors:
@@ -9,7 +9,7 @@ authors:
9
9
  autorequire:
10
10
  bindir: bin
11
11
  cert_chain: []
12
- date: 2012-06-02 00:00:00.000000000 Z
12
+ date: 2012-06-03 00:00:00.000000000 Z
13
13
  dependencies:
14
14
  - !ruby/object:Gem::Dependency
15
15
  name: multi_json