Project

lifeboat

0.0
No commit activity in last 3 years
No release in over 3 years
sends messages to SQS
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 1.0.0
~> 1.5.2
>= 0
= 2.5.0

Runtime

>= 2.1.2
>= 0
>= 1.10.0
 Project Readme

Lifeboat

LifeBoat

Lifeboat is a drop in module for any Ruby Object that responds to 3 callbacks.

It monitors your models for create, update and delete events.

It sends a serialized copy of the model attributes to Amazon SQS when those events happen.

The serialized records are JSON.

WHY

If you're operating a web service and you're smart, then you make frequent backups. But if you're operating a popular web service then no backup will ever be fresh enough when you have a failure. A lot of people learned that lesson the hard way during the Great Amazon EBS Meltdown of 2011. How do you recover data that was created after your most-recent backup, but before your database crashed? One way to do that is with database replication. But not everybody has that option. Another way to do it is to send your data to the lifeboats as soon as it's created, so that you can recover it after a disaster.

Requirements

  • Amazon SQS
  • right_aws gem

Installation

Include the gem in your Gemfile:

gem "lifeboat"

Quick Start

Include Lifeboat in your model class:

class AnyObject < ActiveRecord::Base include LifeBoat end

This will serialize your active record object to json and send it to the queue automatically. Moreover, we do XML too.

test: access_key_id: YOURSECRETACCESSID secret_access_key: YOUR-secRE/TACCe\ssKEy

development: access_key_id: YOURSECRETACCESSID secret_access_key: YOUR-secRE/TACCe\ssKEy

production: access_key_id: YOURSECRETACCESSID secret_access_key: YOUR-secRE/TACCe\ssKEy

Lifeboat will then automatically create queue messages each time any instance of the model class is created, updated, or deleted.

Naming conventions for Lifeboat message queues

Lifeboat will generate three different message queues for each model that you configure it for: create_MODEL, update_MODEL, and delete_MODEL. For example, if your model is named Sale, then Lifeboat will generate message queues named create_sale, update_sale, and delete_sale.

Hot-Swap Slaves

The real purpose of data replication is to maintain hot-swappable backup servers. When your production server goes down you can failover to one of your backups. If you're worried about your entire cloud-based data center going down suddenly for days at a time (it happens!) then you can run a hot-swap slave in a different data center, and periodically monitor the message queues generated by Lifeboat in your production, using the Lifeboat rake task:

rake lifeboat:update

Lifeboat is configured exactly the same for the master and for the slaves, so you can use the exact same code base in both locations. Lifeboat's update Rake task is idempotent, so you can run it as frequently as you like. And Lifeboat slaves do not destroy records from the message queues, so you can run as many different slave nodes as you like.

Contributing

If you'd like to contribute a feature or bugfix: Thanks! To make sure your fix/feature has a high chance of being included, please read the following guidelines:

  1. Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet
  2. Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it
  3. Fork the project
  4. Start a feature/bugfix branch
  5. Commit and push until you are happy with your contribution
  6. Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
  7. Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

Credits

Buit by Ivan.

Designed by Ivan & Ryan.

Inspired by Amazon. (And not in a good way.)