Howto: automate DB backups
I'm not too thrilled with the current backup options Heroku is offering, but I had to do something. So, I wrote up an article that shows how I'm enabling automatic nightly PostgreSQL database backups from Heroku to Amazon S3. http://almosteffortless.com/2010/04/14/automated-heroku-backups/ Feedback is more than welcome. Thanks! -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Database performance
One thing that may or may not matter in your case but might be worth mentioning, do you do any searches by anything other than id? Did you add indexes for those other columns? Carl On Wed, Apr 14, 2010 at 3:21 PM, Neil Middleton wrote: > I've an app that I've just deployed to Heroku (http://www.boxfileapp.com) > and I have some concerns about the performance of the database. > > The app is only running on one dyno at the moment as the load (if you can > call it that) is miniscule. However, one thing I have noticed from within > RPM is that the database is accounting for around 60% of the total time for > the app. > > Given that there is a tiny amount of data in the app, and the queries are > no more complicated than simple selects, this is a little concerning. > > Is this because the app is on one dyno perhaps and the DB gets > 'switched-off' when it's not in use as the dyno would be? Or is there > something else at play? > > Sample RPM chart here: > http://skitch.com/neilmiddleton/n67qw/database-performance > > Neil > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Database performance
I've an app that I've just deployed to Heroku (http://www.boxfileapp.com) and I have some concerns about the performance of the database. The app is only running on one dyno at the moment as the load (if you can call it that) is miniscule. However, one thing I have noticed from within RPM is that the database is accounting for around 60% of the total time for the app. Given that there is a tiny amount of data in the app, and the queries are no more complicated than simple selects, this is a little concerning. Is this because the app is on one dyno perhaps and the DB gets 'switched-off' when it's not in use as the dyno would be? Or is there something else at play? Sample RPM chart here: http://skitch.com/neilmiddleton/n67qw/database-performance Neil -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Simple staging process -- please check
Don't Forget: When you do the db:migrate through heroku you will need to use the --app flag. This one got me the first time as it is not well documented on Heroku. There really should be a Doc on Heroku.com that runs through this as this question is asked frequently. Jared On Apr 14, 11:50 am, Nicolás Sanguinetti wrote: > On Wed, Apr 14, 2010 at 9:06 AM, steven_noble wrote: > > Hi all, > > > I'm about to set up a staging server on Heroku and I'm hoping you can > > check my logic before I do anything stupid. > > > At present, I have a production app on Heroku: > > > drominay-production > >http://drominay-production.heroku.com > >http://www.drominay.com > > > I am the sole developer. The latest version of the code is on my Mac, > > which backs up continuously to TimeCapsule and to Dropbox. I also push > > the entire code-base to Heroku whenever I'm happy with the state of > > the code: > > > git add . > > git commit -a -m "here's what's new" > > git push heroku master > > > So far, I haven't had a reason to teach myself how to branch the code > > in git. I just build one feature at a time, commit regularly, and push > > the entire code base when it's ready. > > > My goals are: > > > 1. Continue to store the latest version of the code locally > > 2. Whenever I'm happy with the state of the code, push to a new app, > > drominay-staging, for a final check > > 3. Copy the database from drominay-production to drominay-staging to > > ensure the final check is robust > > 4. Prevent the public from accessing drominay-staging, while creating > > a separate code base > > 5. Minimize complications > > > Here's what I propose to do: > > > 1. Create drominay-staging > > > A. heroku create > > B. heroku rename drominay-staging --app 77-green-bears-or-whatever- > > heroku-names-it-originally > > > 2. Lock drominay-staging without creating two code bases > > > A. heroku config:add RACK_ENV=staging --app drominay-staging > > B. Surround most of declarative_authorization's rules for the > > guest role with conditions like 'unless RACK_ENV == "staging"' > > > 3. Test the current code and live database on drominay-staging > > > A. git push heroku master --app drominay-staging > > You would have a different remote for the staging app, so you'd > actually just do `git push heroku-staging` or something like that. > --app is not a valid git switch :) > > > B. heroku rake db:migrate -app drominay-staging > > C. heroku db:pull sqlite://backup.db -app drominay-production > > D. heroku db:push sqlite://backup.db -app drominay-staging > > You should first push production's database to staging, and then run > the migrations on staging (so step B should come after step D), or > else whatever changes you do to existing tables will be overwritten by > the db:push. > > Also, after doing a rake db:migrate you need to run `heroku restart`. > > Cheers > > > > > 4. Backup live database and then push code base to live app > > > A. heroku db:pull sqlite://backup.db -app drominay-production > > B. git push heroku master --app drominay-production > > C. heroku rake db:migrate -app drominay-production > > > If I do this, am I in for any nasty surprises? > > > There looks like lot's of opportunities for nasty surprises, so I > > guess the next step is for me to turn this into a few trusty rake > > tasks. > > > Many thanks in advance, > > > Steven. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Heroku" group. > > To post to this group, send email to her...@googlegroups.com. > > To unsubscribe from this group, send email to > > heroku+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Slug size and websolr-sunspot_rails
Is Tomaz referring to his repo size or slug size. It seemed confusing how he stated it "my git repo" is mentioned and then he says "slug limit" later. I would guess he is getting to two confused. Jared On Apr 14, 1:36 pm, Oren Teich wrote: > your slug limit is 100mb. If you see somewhere saying 20mb, that's a bug. > Can you let me know where you saw it so we can update it? > > Oren > > 2010/4/12 Tomaž Žlender > > > > > Hello, > > > slug size of my git repo jumped from 1.9 MB to 21 MB when I added -- > > version 1.0.3.2 --sourcehttp://gemcutter.org'to .gems. > > > Is this normal? My limit for slug is 20mb. > > > Is there anyway to reduce size? > > > Thank you so much for you help. > > > Cheers, > > Tomaz > > > -- > > You received this message because you are subscribed to the Google Groups > > "Heroku" group. > > To post to this group, send email to her...@googlegroups.com. > > To unsubscribe from this group, send email to > > heroku+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Slug size and websolr-sunspot_rails
your slug limit is 100mb. If you see somewhere saying 20mb, that's a bug. Can you let me know where you saw it so we can update it? Oren 2010/4/12 Tomaž Žlender > Hello, > > slug size of my git repo jumped from 1.9 MB to 21 MB when I added -- > version 1.0.3.2 --source http://gemcutter.org' to .gems. > > Is this normal? My limit for slug is 20mb. > > Is there anyway to reduce size? > > Thank you so much for you help. > > Cheers, > Tomaz > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Simple staging process -- please check
On Wed, Apr 14, 2010 at 9:06 AM, steven_noble wrote: > Hi all, > > I'm about to set up a staging server on Heroku and I'm hoping you can > check my logic before I do anything stupid. > > At present, I have a production app on Heroku: > > drominay-production > http://drominay-production.heroku.com > http://www.drominay.com > > I am the sole developer. The latest version of the code is on my Mac, > which backs up continuously to TimeCapsule and to Dropbox. I also push > the entire code-base to Heroku whenever I'm happy with the state of > the code: > > git add . > git commit -a -m "here's what's new" > git push heroku master > > So far, I haven't had a reason to teach myself how to branch the code > in git. I just build one feature at a time, commit regularly, and push > the entire code base when it's ready. > > My goals are: > > 1. Continue to store the latest version of the code locally > 2. Whenever I'm happy with the state of the code, push to a new app, > drominay-staging, for a final check > 3. Copy the database from drominay-production to drominay-staging to > ensure the final check is robust > 4. Prevent the public from accessing drominay-staging, while creating > a separate code base > 5. Minimize complications > > Here's what I propose to do: > > 1. Create drominay-staging > > A. heroku create > B. heroku rename drominay-staging --app 77-green-bears-or-whatever- > heroku-names-it-originally > > 2. Lock drominay-staging without creating two code bases > > A. heroku config:add RACK_ENV=staging --app drominay-staging > B. Surround most of declarative_authorization's rules for the > guest role with conditions like 'unless RACK_ENV == "staging"' > > 3. Test the current code and live database on drominay-staging > > A. git push heroku master --app drominay-staging You would have a different remote for the staging app, so you'd actually just do `git push heroku-staging` or something like that. --app is not a valid git switch :) > B. heroku rake db:migrate -app drominay-staging > C. heroku db:pull sqlite://backup.db -app drominay-production > D. heroku db:push sqlite://backup.db -app drominay-staging You should first push production's database to staging, and then run the migrations on staging (so step B should come after step D), or else whatever changes you do to existing tables will be overwritten by the db:push. Also, after doing a rake db:migrate you need to run `heroku restart`. Cheers > 4. Backup live database and then push code base to live app > > A. heroku db:pull sqlite://backup.db -app drominay-production > B. git push heroku master --app drominay-production > C. heroku rake db:migrate -app drominay-production > > If I do this, am I in for any nasty surprises? > > There looks like lot's of opportunities for nasty surprises, so I > guess the next step is for me to turn this into a few trusty rake > tasks. > > Many thanks in advance, > > Steven. > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to her...@googlegroups.com. > To unsubscribe from this group, send email to > heroku+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Simple staging process -- please check
Hi all, I'm about to set up a staging server on Heroku and I'm hoping you can check my logic before I do anything stupid. At present, I have a production app on Heroku: drominay-production http://drominay-production.heroku.com http://www.drominay.com I am the sole developer. The latest version of the code is on my Mac, which backs up continuously to TimeCapsule and to Dropbox. I also push the entire code-base to Heroku whenever I'm happy with the state of the code: git add . git commit -a -m "here's what's new" git push heroku master So far, I haven't had a reason to teach myself how to branch the code in git. I just build one feature at a time, commit regularly, and push the entire code base when it's ready. My goals are: 1. Continue to store the latest version of the code locally 2. Whenever I'm happy with the state of the code, push to a new app, drominay-staging, for a final check 3. Copy the database from drominay-production to drominay-staging to ensure the final check is robust 4. Prevent the public from accessing drominay-staging, while creating a separate code base 5. Minimize complications Here's what I propose to do: 1. Create drominay-staging A. heroku create B. heroku rename drominay-staging --app 77-green-bears-or-whatever- heroku-names-it-originally 2. Lock drominay-staging without creating two code bases A. heroku config:add RACK_ENV=staging --app drominay-staging B. Surround most of declarative_authorization's rules for the guest role with conditions like 'unless RACK_ENV == "staging"' 3. Test the current code and live database on drominay-staging A. git push heroku master --app drominay-staging B. heroku rake db:migrate -app drominay-staging C. heroku db:pull sqlite://backup.db -app drominay-production D. heroku db:push sqlite://backup.db -app drominay-staging 4. Backup live database and then push code base to live app A. heroku db:pull sqlite://backup.db -app drominay-production B. git push heroku master --app drominay-production C. heroku rake db:migrate -app drominay-production If I do this, am I in for any nasty surprises? There looks like lot's of opportunities for nasty surprises, so I guess the next step is for me to turn this into a few trusty rake tasks. Many thanks in advance, Steven. -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Hoptoad with Rails 3 beta
Had no luck with their notifier either, but works fine using Lilypad: http://github.com/winton/lilypad Configured with this in application.rb: module FooApp class Application < Rails::Application ... config.middleware.use Rack::Lilypad, <> do | notifier | environments %w(environments you want notifications from) filters %w(MEMCACHE_PASSWORD MEMCACHE_USERNAME) # or whatever is applicable end On Apr 11, 11:24 am, Chap wrote: > Anybody successfully using hoptoad with a rails 3 app? > > This didn't work for > me:http://help.hoptoadapp.com/discussions/questions/216-rails-3-support -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Slug size and websolr-sunspot_rails
Hello, slug size of my git repo jumped from 1.9 MB to 21 MB when I added -- version 1.0.3.2 --source http://gemcutter.org' to .gems. Is this normal? My limit for slug is 20mb. Is there anyway to reduce size? Thank you so much for you help. Cheers, Tomaz -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
